Re: Perl 6 fears
Joshua Gatcomb wrote: On 10/24/05, Juerd [EMAIL PROTECTED] wrote: Feel free to add your own, or fears you heard about! FEAR: The Perl6 process is driving away too many good developers FEAR: Perl6 will not be as portable as p5 FEAR: Perl6 is un-necessary and the time, money, and resources is impacting p5. These are at the top of my list. Sooner or later big Perl advocates (like myself) are going to look for other languages because the future is too uncertain and unstable. Also, in terms of module rewriting: This is a massive effort. I don't know if anybody's looked at the internals of stuff like Class::DBI and its derivatives, but it's huge. The fact that there's not alot of active p5p'ers on this list should alarm people more. -Nate
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote: Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. Perl 6's patterns are _not_ regexes anymore. But I doubt that we won't be imitated, because the new regexes are way better than the old ones. Breaking cruft for a reason and all that. Ok, I'll wait on this one. I've said my piece. Maybe they'll go back and update awk and sed after Perl 6 comes out. (Ok now I'm just being sarcastic, sorry. :-) The fact that we use . instead of - (like every other language on the planet)? You're using my argument for me - thanks. See above. Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. No, no, you misread that completely. Basically, you're saying to use the . for objects because everyone else does. I'm using the same supporting argument (everyone else does) for why to start with $1. BTW, C and PHP both use - still. It sounds like you want a backwards-compatible change. From the outset we knew that this wasn't our goal. Perl 5 is full to the brim with syntax, and there's pretty much nowhere we can add anything, and there's tons of cruft that we had to get rid of. Consider Perl 6 to be a derivative, not an extension, of Perl 5. I really do understand that - really. But I think things are getting a bit overboard. The Latin-1 sigil is another discussion that nobody wants to admit is a legit problem, despite numerous legitimate issues. Even being able to type in the syntax itself is going to be problematic! Anyways, you can listen or not listen to those of us from real, large, corporate environments. I'm just trying to temper the enthusiasm for many of the real improvements in Perl 6 with some of the real costs - which are largely being ignored as no big deal. I'm a big Perl advocate, but I guess I'm just not sure if I'm gonna be a big Perl 6 advocate yet. There's alot of downsides and real business risk. -Nate
Re: syntax for accessing multiple versions of a module
Larry Wall wrote: I think there can be some kind of community metainformation that sets defaults appropriately. And if not, the site/project can certainly establish defaults. On the other hand, a lot of projects do simply want to specify the version and author explicitly eveyr time, and they'd rather tweak it by hand (or by script) if they want to change it, since then at least they know when they need to rerun the regression tests. I think it's a laudable idea in theory, but not necessarily application. I've done quite alot of Perl programming, and I've never run into this personally. Who has? (Really, I'm being serious.) Are there really multiple modules sharing interchangeable interfaces? Or instances where we want to allow the same name to mean different concepts depending on the author? There's no logical difference between: use DBI:TIMB use DBI:JEFFSTER And: use TIMB::DBI use JEFFSTER::DBI Anyways, I don't like the idea of people being able to upload identically named modules to CPAN. I think that's a very bad idea. See Rob Kinyon's message. You mean the pattern matching characters on the dispatcher? Or the method declaration syntax? Which part is making your head spin? Yes. :-) But now you're changing your complaint. If we apply your previous complaint to this, in many cases we're doing that redesign *precisely* to fix the thing you're complaining about--too many special cases for one instance...only it's Perl 5 that's the culprit here, not Perl 6. In Perl 6 we've greatly regularized the special cases and reserved most of the special syntax for common cases. Or more precisely, for what we *suspect* will be common cases in the future, not necessarily the common cases in the past. And I think that's actually my problem right now. Back when Perl 6 design started in 1999/2000 (and we wrote all the original RFC's), we were careful not to throw the entire enchilada out. Perl 5 is enormously successful because is solves *actual* problems, not *suspected* problems. And, it shares alot with other languages people know and use. Right now the design is going towards something that's very very un-Perlish from a syntax standpoint. Sure, the philosophy's there, but there are fewer and fewer things Perl 6 shares with Perl 5 (or other widely-used languages). And there are many superflous changes, such as using $0 as the first match, where every other accepted regex engine/program on the planet uses 1. Anyways, I'm not trying to rant or be obstructive (really); I am simply trying to provide a slightly different perspective on a few things. -Nate
Re: syntax for accessing multiple versions of a module
Nicholas Clark wrote: $1 is a prime example. $0 means the program name (all scopes). $1 is the first match. It's been that way for a very, very, very long time, and it works just great. There is no *compelling* reason to change this, other than to satisfy a few people that think it should be different. I cannot agree. The reason you give is not compelling. On the contrary, doing things the established way is perhaps THE most compelling reason. After all, we're changing to . for objects to be like Java and other languages, right? EVERY other language (including Perl 5) starts with $1 (or \1). Neither is the more important reason, that it regularises the numbers when using an array lookup to find matches, $1 being $/[1], IIRC. If you could provide a real-world example where this helps, I'd appreciate it. Again, I'm being sincere. I have never run into this issue personally, so I'm trying to understand the benefit. -Nate
$1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote: Okay, I may still be missing your point, so let me try to summarize just to be sure we're on the same page: You say that the thing that is going to hinder migration to Perl 6 is the fact that it's different from Perl 5. Intentionally trite oversimplification. My problem is that it's different in some ways which are not truly useful, and that cause unnecessary relearning/rewriting/incompatibilities. Our target audience is only somewhat from a Perl 5 background. People from Java, from Python, from C, and even just starting to program will be learning Perl 6, and they would rather have all the language be zero-based, rather than most of it being zero-based except for $1, $2, etc. (you were complaining about special exceptions if I recall). Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. And you don't have to answer, but have you actually programmed in Java or Python? You seem to be speaking for alot of programmers. The reason I'm dismissing you as a complainer is because of your broad field of attack. You say that the method syntax is starting to make [your] head spin. Well, what about it is making your head spin? The method: infix:+ stuff makes no sense to me, but I don't want to dwell on it. The fact that we use . instead of - (like every other language on the planet)? You're using my argument for me - thanks. See above. If you want something to change, you should suggest a change. If you think that Perl 6 is changing too much in general, and that we should go back and make it more like Perl 5, you probably won't get your wish. That's not my wish; just that it's time to take another look at the list of changes to see where the real-world benefit is. [1] Which will be, what, eight hours for a Perl 5 programmer? Have you ever spent a month trying to learn, oh, say, Haskell? Because people do that, too. There are more components to this that just the learning time for one person. There are project teams, sustaining engineering for existing projects, etc. And that's not even counting management tape. Real-world, profitable computing is a big, ugly, nasty beast. If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. This may mean some things that aren't quite perfect still don't get changed. (It also means lots of new stuff can still be added - I'm just talking change.) For example, NIS+ was released as a follow-up to NIS. It was supposed to solve all the issues (mostly security) from NIS. But it was made too complicated, and incompatible with NIS. People were supposed to re-learn NIS and convert all their maps to NIS+. They didn't. Just food for thought... maybe I'm wrong... -Nate
Re: syntax for accessing multiple versions of a module
Stevan Little wrote:
Nicholas,
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRANDOM $spot .= new(woof);
I'd really like to see a more extensible syntax for this. So:
use Dog 1.2.1; # ala Perl5
And then to extend:
use Dog { version = 1.2.1, cpanid = 'JRANDOM' };
This would allow arbitrary specifications, ie:
use Dog { interface = 0.2,
version = ['=', 1.2.1],
company = 'Sun Microsystems'
};
I addresses the class creation syntax partially in the initial version
of the Metamodel prototype, which was built in p5. I basically just
aliased the package with the long name (%{Dog-1.3.4- cpan:JRANDOM::} =
%{Dog::}). However this does no good for loading of modules.
Building off the above:
%{Dog}{1.2.1}{JRANDOM}
Or some such, with the longest-matching object winning.
-Nate
Re: syntax for accessing multiple versions of a module
Larry Wall wrote: Well, we thought about opening it up like that, but we really kinda need to establish what is an official part of the long name for uniqueness purposes, and try to avoid too much visual clutter in standard usage. Going with that... I would think that the official part is really just the module name. Are there lots of problems with CPAN collisions between different authors? No. People just choose a slightly different name if their preferred one is taken. It seems the biggest problem is requiring *only* a specific version, or range of versions, or = a version. I know this is addressed already. Not trying to rant (really), but one thing that is starting to bother me about Perl 6 is that there's lots of changes that require special syntax for one specific instance. It's making it really really difficult to remember or generalize, two things that I thought we were trying to improve. -Nate
Re: syntax for accessing multiple versions of a module
Larry Wall wrote:
This is one of those accomodations to the real world, like everyone
agreeing on a standard URI format. We're really trying to keep
these module names close to what you'd see as the name of, say,
the corresponding .rpm file. These modules have to have names that
work outside of Perl as well as inside, and {...} isn't going to fly
in general.
My concern is that we're solving problems that don't really exist in
real-world Perl usage. Are there really two competing authors of DBI?
Or, for any product, do two people really try to market SuperWidget?
No, one person just changes to SuperGadget. And with URI's, one person
gets amazon.com. Sorry, name taken.
I think we're actually *encouraging* problems by allowing long, clashing
names. Pretty soon all DBI modules will have to start with
use DBI:TIMB;
Because JEFFSTER decided to upload his DBI (Derivative Binary Index)
module.
I think it will have the opposite effect of what we're trying to avoid.
: Not trying to rant (really), but one thing that is starting to bother me
: about Perl 6 is that there's lots of changes that require special syntax
: for one specific instance. It's making it really really difficult to
: remember or generalize, two things that I thought we were trying to improve.
Well, you're painting with kind of a broad brush here. If you can
point to other areas where we could usefully generalize without
getting too abstract for newbies, I'd be delighted to hear them.
The method syntax is starting to make my head spin, for one.
Many things, as a longtime Perl 4/5 programmer and CPAN goon, are
problematic because we're reusing established operators for completely
different ideas. From a design standpoint, I feel it's going to hamper
adoption of the language. People don't have the time (or interest) to
re-learn that much language, when Perl 5 works fantastic for 95% of
the cases.
-Nate
