Perl 6 is vaporware because the design keeps changing and will never be finished. Will Perl 6 be bootstrapped so that mere mortals can contribute to the source or won't it? Will Parrot be the official implementation or will it be Pugs? Can these guys just make a decision and stick with it?

Perl 6 is going to suck because the folks in the ivory tower are not listening. I had this great idea for feature X but it is not being included (timely destruction for instance).

Everytime someone complains about Perl 6 not being fast enough the cargo culted mantra of "volunteers welcome" is one of two retorts (the other being is "it takes time to get it right"). Well that is utter BS. How can I contribute. I don't know C so I can't help out with Parrot. I don't know Haskell so I can't help out with Pugs. I have never seen a list of tasks and goals that must be reached to reach the finish line. It seems awfully convenient to not provide a list of milestones and activities that must be accomplished to be finished but then tell people if it isn't getting done fast enough to contribute.

Perl 6 is a waste of time because it is unnecessary. If it were necessary, were are the specific design goals enumerated? If there are no defined goals, what are we hoping to accomplish by wandering aimlessly?

Perl 6 is never going to have "real developers" because it is still just a scripting language. Sure it will be more like Java in that it uses a VM but will I be able to hide my source code? I heard that a design goal of Parrot would be able to turn a .pbc into HLL source and is NOT intending to produce native executables.

Perl 6 doesn't matter to the perl community because they are being effectively ignored. Have you ever tried to follow the lists. Some will ask a specific and direct question - will Perl 6 do feature X built-in? Someone else has a follow on idea, the thread spirals out of control, no definitive answer is reached (on anything) and it finally loses momentum with the original request unanswered.

Perl 6 is going to fail because its design is a big ball of mud. The spec has changed from a community project to, RFCs being considered for As, Es, Ss, to just Ss, to a test suite. In many places it says if not defined then refer to perl 5 which defeats the purpose since perl 5 uses the implementation as a basis for the spec. Larry always reserves the right to change his mind so how can anyone keep track of what is and is not Perl 6?

Perl 6 is going to fail because perl 5 is still viable. No one is going to use Perl 6 unless it "just works" when provided existing perl 5. Have you considered the amount of code on CPAN? Even if, by some miracle, my perl 5 does work - what about my XS, Inline::Java, etc? Ponie is a bust. Parrot can't run perl 5. Heck, it can't even run perl 1. What makes anyone think Parrot will be able to run Perl 6? If Parrot had any hope of running Perl 6 it should have been using perl 5 as a HLL targeting it from the beginning and then the argument would be moot because people could just use Parrot and forget if they were feeding it Perl 6 or Perl 5.

I heard an original design goal was to be able to allow the user to extend Perl 6 removing any need for Perl 7. Then I heard that the "only perl can parse perl" mantra is going to be true for Perl 6 too. If I can't extend the grammar and macro's amount to source filters than how is this any different than perl 5?

Perl 6 won't succeed because it is being ran by a bunch of cronies in the inner circle just like perl 5. Everyone knows p5p has driven away many good hackers.

Perl 6 won't succeed because it is stuck in the past. The future is in parallelism and distributed processing across multiple machines.

For anyone who thinks I myself am not pro Perl 6 should search a bit.

"Perl 6 is vaporware because the design keeps changing and will never be finished. Will Perl 6 be bootstrapped so that mere mortals can contribute to the source or won't it?"

fglock and audrey have worked on a mini-perl6 specification, mp6, which has already been bootstrapped: mp6 is written in mp6.

"How can I contribute. I don't know C so I can't help out with Parrot. I don't know Haskell so I can't help out with Pugs."

fglock has also written v6.pm, which is a perl6 implementation written in perl5. You can help to improve it with your perl5 knowledge.

And you can start now:

cpan> install v6

nferraz,
I think you misunderstand the intent of duff's post. He was soliciting a list of objections to Perl 6 so that they can be addressed by TimToady and crew. I have been following Perl 6, Parrot, and Pugs for years. Those objections are not my own but rather objections I have heard others make over the years.

I will be looking forward to a follow-up by duff with the "official" rebuttals.

Cheers - L~R

Then I heard that the "only perl can parse perl" mantra is going to be true for Perl 6 too.

One minor nitpick to your excellent post (and yes, I know you're not expressing your own personal opinions but just reporting other people's, according to duff's request): the current mantra is that "nothing but perl can parse Perl." AIUI For Perl 6 plans are that it get upgraded to "nothing but Perl can parse Perl."

The main thing wrong with Perl 6 is the name. It poses as a version upgrade like from Perl 4 to Perl 5, but it's a completely different language with largely incompatible syntax.

Gee, if the name is the main thing that's wrong with it, maybe I can just ignore all the other problems. :-)

Seriously, what makes Perl Perl? If someone decides I'm ugly and beats my face to a pulp, and later I get a face transplant, am I still me? If my bones rot and are replaced with synthetics, at what point am I a different person? Syntax is just skin. Semantics are just bones. Neither is the soul of Perl, which rests in the realm of pragmatics.

Maybe it would help if you thought of Perl 6 as something more like Perl 16 or so. We're just trying to skip over the 20 years of deprecation cycles and dead ends it would take to evolve Perl 5 into Perl 16 piecemeal, even assuming that were culturally possible, which it really isn't. Plus I'm too Impatient to wait that long.

I've also seen what happens to other languages that change their name. They basically lose their branding, and have to start all over. I'm too Lazy to do all that work again. Plus there's a longstanding cultural assumption that major version numbers indicate incompatible changes, despite the recent trend for marketeers to pretend that great strides have been made when they haven't.

Another factor is that four letter words are in short supply, and we shouldn't use them up so quick, especially for things we really want to use four-letter words on. :-)

But overriding anything else is the fact that I think I have a moral claim on the name, and I want Perl 6 to be considered a better Perl than Perl 5. Call it Hubris if you like...

what makes Perl Perl?

In no particular order:
1. Perl is context-based, or context-sensitive, or it decides what to do on code depending on in what context I expect my code to be treated (well, in the set of contexts Perl understands)
2. Perl allows me to code in the *first way* that comes to mind to solve a problem, yet allows me later to improve the solution in *another way*.
3. Perl makes it easy for me to visually distinguish variable types and interpolate them in string. This is one of things that made me fell in love in my early Perl days.
4. Perl allows me to have as many namespaces as I like (or need) and arrange them in a nested fashion. I can have them in one file, or in their own files. (I just can't stand to say CGI_Application_Plugin_Authentication_Driver_DBI).
5. Memory management. Well, this one was actually less relevant for me until I know (by literature) the pain in manually allocating and deallocating memory. So my praise to those who implement Perl in C but can stand the pain :-) (They can, can't they?)
6. Garbage collection, see also note about MM. I don't care whether it's implemented with reference counting or mark & sweep, or other techniques, as long as Perl provides GC.
7. CPAN, enough said :-)
8. Unimitable Regular expression
9. Optional parentheses, semicolons, and commas as long as they're not required
10. I love one-liners
11. Optional return in subs (TheDamian advices againsts it (PBP 9.11), though.)
12. POD!
13. Free-form syntax structure
14. Short-circuit in logical operators
15. (I don't know how to name this) EXPR if STATEMENT and other statement modifiers friends (Updated per blazar below)
16. Closure, anyone?
17. Arbitrary (bare or named) block usage
18. Nested scoping

(Well, I can go on but that's what I can think of now. I could add TimToady's onion speaks but I'm afraid it's too much personal)

If Perl 6 preserves those characteristics, there's no reason to say Perl 6 is not Perl despite the change on the syntax. For example, I don't mind to write @array[1] instead of $array[1]. It's still Perl. And of course I can't mind to write:

given ($some) {
 when 'body'  { 'has to fight' }
 when 'thing' { 'has to give' }
 when 'day'   { 'they will know the truth }
 when 'where' { 'in a very near place to their mind' }
 when 'time'  { 'can only tell' }
 default      { 'yes, there is always a space for default' }
}
[download]

In the mean time, the only thing I can do now is stay with Perl (5) until the day when we do have that better Perl than Perl 5. In the future, we won't call it Perl 6 anymore, just Perl.

---

Update: now that I remember more, I added number 13 onward.

---

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

We're just trying to skip over the 20 years of deprecation cycles and dead ends it would take to evolve Perl 5 into Perl 16 piecemeal ...

Pardon me if you've answered this before, but what exactly about Perl 6 would give it such longevity?

Syntax is just skin

Linguistic determinism is the idea that language shapes thought. As a hobbyist in the J programming language I disagree that syntax is just skin... sure they could all compile down into the same parse tree, but, but... ummm.. well, I still disagree :)

---

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Corion ++ you hit the nail on the head IMHO !!
Perl6's name implies that it is the next version after Perl5. Now such claim could safely be made if Perl6 largely builds on the syntax and architecture of its predecessor Perl5. However from what I have seen it appears that Perl6 is highly incompatible with Perl5, some very core constructs have changed semantics, all in all it simply is a different language.

Now I will not comment on the quality of Perl6. No doubt it has its merits given the development efforts and the experienced team of developers. It may well be a superior language to Perl5.

The real issue here is that by naming the new release Perl6 it degradates its predecessor Perl5 to an 'older now obsolete' release and it cuts off the natural path to an upwards-compatible 6.0 release. Now this may or may not be the intention of the Perl6 development community but it simply does not do justice to the Perl5 achievements, the installed base and happy Perl5 developers. It makes non-Perl programmers weary to start with Perl(5).

My plea would be to rename Perl6 to something else. Call it Perl++ or Perl# if you have it, just don't imply that it the next release that builds upon Perl5. If Perl6 is the best thing since sliced bread then over time developers will jump on that bandwagon anyway.
Meanwhile let's not kill Perl5.

Howdy!

That objection seems to be grounded in some ignorance (in the technical sense of simply not knowing).

It is not unheard of for a major version change to favor new/better features over backward compatibility. If I recall correctly, help with smoothing the path from Perl 5 to Perl 6 is part of the effort. Further, while there are significant changes and (one hopes) improvements in the upgrade, the language appears to look Perlish, much in the manner that a Mustang looks like a Mustang, even through multiple iterations of style. There are key elements that say "I'm a Mustang" or "I'm Perl".

Further, it is not clear that Perl 5 will die anytime soon. One can expect an extended period where both versions are being developed. People with considerable investments in Perl 5 code will tend to be reluctant to jump on the Perl 6 bandwagon right away. Others will simply be leery of change. There will probably remain a considerable mass of interest in Perl 5 for some time.

I'm grateful that Perl 6 is simply the next major version of Perl. Perl++ or Perl# would be Just Wrong. 6 is the next number after 5. Skipping to 16 would be another piece of "my version number is now bigger than yours" tomfoolery (Sybase, anyone?)

yours,
Michael

I don't know what "Perl6" and "Perl5" are, but I sincerely hope that Perl 6 at least will kill Perl 4.

Update: Elided objectionable part of the post.

I don't find anything too terrible about perl6, but I know very little about it. I had some trouble getting it to run at all on my system and gave up really fast. I'm a big perl5 fan and I don't intend to learn perl6 until it's done.

I do have two relevant comments though.

First, I think I saw somewhere something like, "%perl6hash{$key}{$key}" and the lack of context prefixing made me feel very sad. I resist change, and I really like the way perl uses $ in scalar contexts and @ in array ones. If "%perl6hash{$key}{$key}" is a scalar, why the % prefix? Kinda reminds me of the changes to nwn2 — too much response to critics and not enough actual innovation. But I know almost nothing about it, so I'm probably totally wrong.

Anyway, it's very clear there's tons of real innovation going on.

Second, I don't think perl6 will be done until its good so I don't spend any time worrying about whether it'll be good. It'll be good before I learn it since I'm waiting for it to be done.

First, I think I saw somewhere something like, "%perl6hash{$key}{$key}" and the lack of context prefixing made me feel very sad. I resist change, and I really like the way perl uses $ in scalar contexts and @ in array ones. If "%perl6hash{$key}{$key}" is a scalar, why the % prefix? Kinda reminds me of the changes to nwn2 — too much response to critics and not enough actual innovation. But I know almost nothing about it, so I'm probably totally wrong.

I did share the same exact feeling because the old current behaviour does make sense. But the more I think about it, the more I realize the new one does as well, and probably more too: in fact the former has some corner cases in which it doesn't square well. I can remember in particular a discussion with Uri Guttman in clpmisc... if $href contains a hashref, then what is $href->{'item1','item2'} to mean? To be unambiguous you have to use the other kind of dereferencing:

my $multi=${$href}{'item1','item2'};  # "multi"...
my @slice=@{$href}{'item1','item2'};
[download]

But to resolve the ambiguity with the first attempt the core developers made a choice that IMVHO is in retrospective not the most intuitive one. However in Perl 6 all possible ambiguities will be resolved with a consistent design and as a plus explicit referencing and dereferencing will be required on a much more sparse basis than currently is.

Said, this, I'm sure quite about everyone has some "favourite" piece of Perl 6 syntax or semantics that he doesn't particularly like. I, for one, I'm in the camp of those who dislike the choice of unicode operators at all. I suppose I could easily be called "old-minded". I guess I am. But given that they will have ASCII only equivalents and that both will be more or less equally easy to type and read, I don't care much after all.

Having done some tests, and it also seems to make perfect sense to me... the 2nd version, my @slice=@{$href}{'item1','item2'}; Is the only one which seems valid for the purpose at hand. The target is to get a hash slice, which is array (ahem, list) context, so @{$href} is what places it in that context, dereferencing as an array, to mimic @hash{'item1','item2'}

${$href} on the other hand attempts to dereference as a scalar, which, in my test, didn't yeild anything but undef:

#!/usr/local/bin/perl

use strict;

my %hash = map { chr(ord('@')+$_) => $_ } (1..26);
my $hashref = \%hash;

my @list = qw/A B L S Z/;

my @slice = @{$hashref}{@list}; 
my $multi = ${$hashref}{@list};

print '@slice == ['. join(', ', @slice). "]\n";
print "\$multi == '$multi'\n" if defined $multi;
print "\$multi == undef\n" if !defined $multi;
[download]

Output:

@slice == [1, 2, 12, 19, 26]
$multi == undef
[download]

So it seems only one of these gets the desired result, and thus no ambiguity.

I'm inclined to say that only the name is wrong. However, that would be interpreted incorrectly. Perl 6 is Perl, and I agree with the argumentation that Larry gives.

I do think the long name (including version number) should not have been Perl 6. Mind you, that includes the 6. Because the "6" part is the problem, not the "Perl" part. In my opinion, it's okay to reserve a version number only if you can deliver it within a year. Maybe two years. But it has been 7 years so far, and the end is still not in sight.

Calling it Perl 6 so long before the first release creates expectations that cannot be met, causes confusion, and demotivates people to work with and on Perl 5.

On the other hand, changing the name after 7 years may be an even worse idea. I don't know. I still like the idea of calling it "Onion" during development, and rebranding it as "Perl" when a release candidate is nigh.

Perl 6 is taking too long

I think so, but no single person is to "blame" for that. The Perl 6 we have now is not what anyone had in mind after OSCON 2000 -- if there had been releases in between, it would have taken 7 more years to come to this point, and the version would have been 8.4, or indeed 16.

Perl 6 is too much like Java

It's also too much like Ruby, too much like Python, too much like PHP, too much like Tcl, too much like Perl, and too much like C. Perl 6 is so incredibly vast, that anyone can find things they don't like about it. And we like to compare those things to other languages, because the other langugae sucks by definition. But actually, Perl 6 isn't like those languages, and it doesn't suck in the same ways. I myself try to focus on the (many!) things that I *do* think were improved, and will learn to live with the few remaining annoyances.

Perl 6 isn't Perl 5

...

Perl 6 is being designed by committee

Some complain that Perl 6 is being designed by a committee, some complain that Perl 6 is being designed by only one guy. Both are true, and some people will just never be happy. :)

Perl 6 is suffering from the second-system effect

We'll see if the second system effect is a blessing or a curse.

Perl 6 is hurting Perl 5 by consuming resources

This may have been true at one point, but it currently is not. Different people work on the different projects. In fact, very few people still work on Perl 6.

In my opinion, it's okay to reserve a version number only if you can deliver it within a year. Maybe two years. But it has been 7 years so far, and the end is still not in sight.

What's your new name for Perl 5.10?

Bleadperl. And note that it's 5.9, not 5.10. It will be 5.10, but nobody says it is.

I do think the long name (including version number) should not have been Perl 6. Mind you, that includes the 6. Because the "6" part is the problem, not the "Perl" part. In my opinion, it's okay to reserve a version number only if you can deliver it within a year.

This is my primary complain about the current situation as well. By taking the version number 6 long before anything was ready it signalled that Perl 5 was dead and soon to be replaced by something new. When that new thing didnt come out it left the meme in the market that both Perl 5 and Perl 6 were dead, (one of old age and the other still-born). This meme is doubly incorrect, Perl 6 isnt still-born, and Perl 5 is most definitely not dead of old age.

I really hope that Larry takes the opportunity over this summers conferences to push the point that neither are dead. Especially Perl 5 as I believe that Perl 6 will prove its point when its released but that Perl 5 is currently suffering from the confusion in the marketplace.

---
$world=~s/war/peace/g

I really hope that Larry takes the opportunity over this summers conferences to push the point that neither are dead.

I don't know why you think that would help. I've said the same thing every summer and more or less been ignored. I think the main problem here is simply a basic human tendency: far too many people would much rather listen to themselves spout ignorant opinions than try to figure out which of the other spouters aren't. They don't necessarily mean any harm by it, but then we all intentionally blind ourselves to the harm in what we do, to some extent or another. That's the psychological danger inherent in living your life based on minimizing harm rather than maximizing love.

A few questions that I would ask myself before commiting to go through the learning curve associated with Perl 6 for a new project:

1. Where can I download a binary install for my system?
2. Where can I find an indexed language definition?
3. When will PerlMonks have a dedicated Perl 6 section?
4. Does it run Ackerman faster that Perl 5 (Java, Ruby, Python)?
5. Can I spawn threads faster than I can spawn processes?
6. Can I share a single copy of my complex data structure between those threads?
7. When will Perl 6 v1.01 become available?
8. How much of a penalty is my pure Perl 6 code going to pay, for whatever Perl 5 backwards compatibility that is being added?

When will PerlMonks have a dedicated Perl 6 section?

Never. But that's not a Perl 6 problem anyway.

(As theorbtwo said, posts are not directed into sections by what they are about, but by what type of discourse they are.")

A word spoken in Mind will reach its own level, in the objective world, by its own weight

duff, I'm on shaky grounds here but give your recent article I can outline some of what I don't like about perl6:

• for =$fh - that just looks string. I think while(<$fh>) is too strong of idiom to break
• ~ ~ for string concats
• ??!! replacing ? :

Maybe it's just syntactic sugar I'm complaining about. I can kinda see why some of it had to change (new brackets, . for method invocation, etc) and I really salivate about some of the new features *but* those perl5 idioms have a strong sway over me.

Yes, it's easy to have a great deal of affection for the current syntax. It seemed like a good idea at the time, and still works pretty well in the context of the rest of Perl 5. But to some extent you have to take it on faith that we didn't change anything without at least the semblance of a good reason, and many of these reasons make more sense in the context of Perl 6 as a whole. I can attempt to explain some of those decisions here, but I can't rejustify every decision, or I'd end up copying all the Apocalypses, Exegeses, Synopses into Perl Monks, not to mention replicating a great number of design meetings, phone logs, irc chats, etc. And as chromatic points out, we'd never get any work done if we tried to answer every question multiple times.

However, I have some hope that this thread will have sufficient cultural leverage to make a difference, so I'm responding here. On your particular points:

for =$fh - that just looks string. I think while(<$fh>) is too strong of idiom to break

Brackets are in extremely short supply in ASCII, and the angle brackets were rather wasted on a single operator. Plus we really needed to do something about the strange autoquoting rules in subscripts that result in far too many FAQs. Stealing angles for both qw// and literal subscripts solved those problems, but it meant that we needed something else to iterate iterators. And unary = is the best we've come up with so far, given all the other demands on the character set. It has some visual mnemonic value in that it looks kinda like two lines from a file. But yes, it's a little strange.

~ ~ for string concats

We needed something for that operator, and dot was no longer going to be available. We can't use juxtaposition like awk because that screws up expectations of terms vs operators, a fundamental contextual idea that carries through all the way from Perl 1 to Perl 6. We originally specced _ for it, but it didn't work well next to identifiers, and we wanted to reserve the underscore identifier for other potential uses, so we settled on ~ because it looks like a bit of string, and because the bitwise uses of tilde were going away in favor of a de-Huffmanized but more regular set of bit operators, so tilde was available.

??!! replacing ? :

This is another case where some very important keys on the keyboard are locked up in not-so-very important operator, so we decided to de-Huffmanize and rationalize them. (The use of a bare colon was particularly difficult because there were so many other proposed uses for colon that we were trying to accomodate.)

The character doubling fits in culturally with the other short-circuiting forms such as && and ||. At one point the else was indicated by a double colon, but that turned out to be visually ambiguous with package name delimiters, plus we have a fairly consistent usage of ? to mean true and ! to mean false through the rest of the language.

Anyway, you undoubtedly like the current Perl 5 idioms for the same reasons that I liked them originally. :-) I would like to believe that you'll end up liking the Perl 6 idioms too, once you get used to them.

Stealing angles for both qw// and literal subscripts solved those problems, but it meant that we needed something else to iterate iterators. And unary = is the best we've come up with so far, given all the other demands on the character set. It has some visual mnemonic value in that it looks kinda like two lines from a file. But yes, it's a little strange.

Reusing angle brackets was a great idea. I really like being able to write stuff like:

    my @array = < foo bar baz >; # instead of qw/ foo bar baz /

    %hash<foo>; # instead of %hash{'foo'}
[download]

But I also agree that the unary = is a bit strange.

(On the other hand, qw// was a *very* strange idiom -- so I believe that, overall, Perl6 is a bit less strange beast.)

??!! replacing ? :

I know this is completely OT in the context of this thread, but I've not been in p6l for a long time and I'm trying my hand here. Now, I've sometimes felt the need to distinguish in a single statement between "TRUE", "FALSE" and "UNDEFINED". To this effect in Perl 5 I've had to use nested ?:'s or other short circuiting operators, with an overall "too much effort" back taste. I was wondering if by any chance Perl 6 could incorporate unambiguously in ??!! an optional additional !! so that the fourth argument is returned in case the condition turns out to be undefined.

Indeed a particular syntax can have a strong influence on us.

Why, just the other day I almost typed 'sub' into a PHP source. (It's 'function' there.) Two reasons I really wanted to learn C when I was starting out in programming was because '{' and '}' were much quicker to type than 'begin' and 'end' and they also were more visually distinct from functions. I often want to use curly brackets for associative arrays in PHP (square brackets there). I often try to use foreach in JavaScript (It never seems to work). In JavaScript, I sometimes try concatenating strings with '.' and using '+ 0' (as opposed to '- 0' which doesn't have precedence issues from overloading) to coerce numeric context.

Oddly enough, after a couple of minutes with the code at hand I remember what language I'm using. After that point, the right spelling for the language I'm using tends to come back to me pretty easily and I'm on my way.

I have faith my transition to Perl 6 will be no easier but probably not much harder. I'll try Perl 5 in Perl 6. I'll go back to a Perl 5 project and try Perl 6 syntax. Of this I have no doubts. After a few minutes with one or the other, though, I'm sure I'll get in the groove of that particular dialect.


Christopher E. Stith

I have followed the perl6 development effort since it basically started. I have never really been able to contribute -- most of the conversation was far beyond my understandings of language theory. I still do not get why closures are such a big deal :)

I was outraged when @larry stole ->. I thought for a long time that perl6 would never see the light of day (there was a long, dark period when the lists were very quiet). I was angry for a long time because this wasn't just perl5++ and I was going to have to learn a whole new language.

I have just recently, based on the activity of the lists, downloaded pugs again and started to play. It isn't often that playing around in a debugger makes me laugh. I keep saying stupid things and the language did the right thing anyway. I cannot wait until perl6 is done. This is a fun language that doesn't just DWIM, but DWIMC (does what I mean, correctly). And I am just playing with a prototype. I want a perl6 camel so I can figure out all the other fun stuff it does.

To all of the pessimists, just wait. Keep an open mind and give it a few honest tries. I doubted, I despaired, I claimed this was a great waste of time. I was wrong. perl6 is not perl5, but it will most definitely be Perl. It will be worth the wait.

Mik

PS -- This advert brought to you under my own free will. Just wait. perl6 is going to be all that. And a bag of chips.

Perl 6 looks to me to be inferior to Ruby 1.8 in many aspects, especially in overall cleanness and natural OOP.

For example, while I read the article titled Perl 6 Now (from Perl.com), I couldn't help thinking to myself how every bit of code would be done in Ruby and reaching the conclusion that it would be much cleaner.

Perl 5 has 3 strong pros against Ruby: CPAN, the community and performance. The performance of Perl 6 would be arguably comparable to Ruby. If it runs on Pugs, it will probably be even slower. On Parrot, Ruby can run too (besides the fact that Ruby has a new VM that makes it much faster, almost ready). CPAN will have to be translated to Perl 6 anyway, sooner or later. And Ruby is quickly catching on in this area. The community is a huge plus that is hard to change. It is sad to have a much better community for an inferior language, but I hope this will change too, sometime.

Are you serious?

Maybe Ruby 3.0 will address the allomorphic problem with duck typing. Maybe.

Maybe Ruby 3.0 will add continuations and coroutines back into the language.

Maybe Ruby 2.5 will add a native calling interface.

Maybe Ruby 3.0 will interoperate with several other languages (but by that point we'll call it Cardinal).

Maybe Ruby 3.0 will add multiple dispatch, and multiple blocks to a function, and automatic currying, and optional typing, and built-in laziness, and asynchronous IO, and parellelizable hyperoperators, and constrained types, and finally fix the require mess.

Maybe Ruby 4.0 will add junctions.

The only problem is that no one has announced Ruby 3.0 yet, so I'm just guessing at when the Ruby developers will start to think about some of the nice features of Perl 6. Meanwhile, maybe Ruby 2.0 will come out before Perl 6. Maybe.

And while we are in the maybes

• Maybe Ruby will get a little bit more clever in letting me spread a statement over several lines without jumping through hooooooops that much.
  

  x = 1 + 2
   + 3
  puts x
  [download]

  prints 3. That's kinda what I'd expect from a language that more or less uses the newline character as the statement terminator. But even

  x = (1 + 2
   + 3)
  [download]

  prints 3. (Sorry? How???)

  x = foo(1 + 2
   + 3)
  [download]

  on the other hand errors out with "syntax error, unexpected tUPLUS, expecting ')'". Lovely. Choose between the two ugly options

  x = foo(1 + 2 +
   3)
  [download]

  and

  x = foo(1 + 2 \
   + 3)
  [download]

• Maybe sometime in the future it will get sensible error messages. "unexpected tUPLUS"? What the f..k? And that's one of the least cryptic I've seen.
• Maybe in a few years the Ruby folk gets through the discussion that was hot in the Perl community some eight years ago and add variable declaration and use strict. (There is currently no way to know whether an "x" used in a block is a new local one or shared with a bigger scope. And no way to specify that. And to make things more interesting the locality of the block parameters is currently context dependent, in the upcomming version they will always be local. Sweet.) Currently all you get is a runtime check that the first thing you do to a variable is some kind of assignment.

Jenda


Support Denmark! Defend the free world!

For example, while I read the article titled Perl 6 Now (from Perl.com), I couldn't help thinking to myself how every bit of code would be done in Ruby and reaching the conclusion that it would be much cleaner.

Can you show what those examples would look like in Ruby?

I started typing the whole thing but it's too long, so I'll just post the code relevant to my comment. I feel that sigils are unnecessary at all (and they are harmful to my wrists !)

##
## Sigil invariance
##

array = [1, 3, 5, 12, 37, 42]

# I use symbols here, but one can use strings: {'alpha' => 4, 'beta' =
+> 6}
# 
hash = {:alpha => 4, :beta => 6}

third = array[2]

# This would be hash['beta'] when using strings
#
beta = hash[:beta]

# Ruby doesn't slice as a part of syntax - there are special member 
# methods for that. I personally see it as a good thing.
odds = array.values_at(1, 3, 5)
bets = hash.values_at(:alpha, :beta)
[download]

To take a simple example, why after 6-7 years are there no Perl 6 modules on CPAN? Even though the current compilers are limited it would help a lot to be able to upload a tarball with some P6 code + POD and have it smoke tested on Pugs/v6.pm/perl6.pir/mp6 etc.

I tried to do something to that end in the Pugs repository and found that the only Makefile.PL build systems depended on Pugs itself being present (correct me if I'm wrong) so I ended up writing my own Makefile to build blib/run make test.

How do I write little toy modules and put them on CPAN now? Has anyone been working on something to that end other than the 6PAN project which seemed to aim to rewrite the CPAN mirroring system.

I watched Audrey's presentation (the one in Japan, I think). The recent one.

Perl 6 is scary. It's got Perl 5's more-than-one-way-to-do-it, but squared. I was taking notes, but at one point just gave up. Aside from the new (seemingly hairier) syntax, there's all sorts of new ways to not only change the language, but change how the compiler/interpreter works. It's just got multi-dimensional axes of TMTOWTDI all at right angles to each other.

Back to Audrey, what I immediately noticed was how smart she is. I mean, she's wicked smart. Then I realized, most of the Perl higher-ups (Larry, Damian, Allison, etc.) are also big brains like that.

And then it hit me: Perl 6 is mental masturbation. The Damians and Audrey's of the world will revel in the freedom, the power, and the flexibility. The rest of us will be scratching our heads looking for something easier to wrap our brains around.

The Damians and Audrey's of the world will revel in the freedom, the power, and the flexibility. The rest of us will be scratching our heads looking for something easier to wrap our brains around.

I hope not! Part of the reason why I wrote Everyday Perl 6 was that I wanted more introductory material on Perl 6 for "the rest of us". Stuff that "ordinary" people would use. Since I didn't find too much, I thought I'd just start writing it.

Damian and Audrey and others are doing their part to inspire the masses; to bring us dreams made real. Once Perl 6 hits the streets, I'm sure there will be articles and books and tutorials and such that will bring "the rest of us" closer to being a Damian or an Audrey (even if I have to write some of them :-)

duff

Sing it brother! Quibbles over syntax miss the point IMHO. Perl 6's downfall will be its mind-boggling semantics.

I'll always have a soft spot for Perl 5 -- I thought it was the greatest thing since sliced bread for quite a while. Then I realized that TIMTOWTDI had a dark side. It didn't matter that I wanted to speak Perl "baby talk". Everyone else's source was speaking a different dialect.

In trying to be all things to all people, Perl 6 is TIMTOWTDI gone wild. I like to think of it as the quantum mechanics of programmming languages.

laughingboy

I don't mean to be overly rude but it seems it did matter that you wanted to speak Perl "baby talk" because you also wanted to readily understand everyone else's source (i.e., dialect). Your mentality perturbs me.

Perl 5 enabled you to baby talk blissfully. Perl 6 seems thoroughly poised to enable the same. How is that simple elegance diminished by the availability of optional advanced capabilities? I mean, were you lulled into some misguided silver-bullet idea because Perl has been so successful at making easy things easy that you presumed "baby talk" would also be sufficient to make hard things not only possible but easy too?!

If linguistic expressiveness && many solutions were the dark side of Perl that you were dismayed to discover, can the same be said about other programming or verbal languages you have endeavored to learn at least the rudiments of? I understand that time && effort to learn non-native languages are limited but does this justify taking a diminished outlook on a foreign language because you discover mind-boggling semantics in the poetry of the native speakers?

I don't think Perl 6 is trying to be all things to all people. Neither does it seem to be TIMTOWTDI gone wild (in any devastating, irrational, insurmountable, etc. way). Maybe you're just a joker && I should just laugh along instead of being potentially ridiculous by taking a serious posture against you but everything I've yet learned of both Perl 5 && 6 suggests that they'll both be awesome languages for quickly writing useful software (even if you only scratch the surface). It seems unjustifiable && unproductive to expect to readily comprehend average or expert composition without a commensurate expectation to proportionately expand your own relevantly featureless vocabulary && inadequate understanding of diction (&& then it's disingenuous to describe the distinction between baby && mind-boggling as merely dialectic).

Perl 6 may have a much higher complexity ceiling than any programming language that has come before but it's also progressing powerfully towards making easy things even easier && hard things easy now too! If you don't need to know more than one way to do something, you should be just as able to ignore the subtleties && the new semantics you are daunted by. If you ever find the time && inclination to learn more, hopefully it can be seen as benefit rather than burden to you... and hopefully you can also learn to harbor less resentment towards the fluency of adolescents, adults, && elders just as they concertedly foster your self-directed socialization process to be viably terminated during infancy. I don't know. I love Perl but I still know how very much I have yet to learn about 5. I'm just thinking it would be more helpful for everyone if you could think about your attitude a bit more carefully && maybe demonstrate more gratitude for ambitious progress rather than indignance, disappointment, && an immature sense of entitlement towards universal simplicity. Lowest-common-denominators don't lend well to improvement.

I'm convinced that Perl is greater than sliced bread... && sushi! ;)

Again, sorry if I'm being too harsh or flaming counter-productively or without warrant here. I just wanted to contest your quibbles with mine intelligently. I've still got lots to learn about being intelligent too! ;)



-Pip

Do you, or anyone, know if the video of Audrey's presentation is available for direct download anywhere? Preferably somewhere that supports resumable file transfers.

I found it on google video, but trying to watch streaming video via dialup is pointless and trying to reliably unpick the google video urls to get the file with wget seems to be pretty much impossible.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Do you, or anyone, know if the video of Audrey's presentation is available for direct download anywhere? ... I found it on google video,

The Google video page has a button on the right hand side of the window to download the video.

She's not only smart, but funny too. Even with the tough crowd. :)

I won't bother with Perl6 until the Haskell stuff is out of the picture. I don't hate Haskell, but Perl5 compiles directly from C, and I'll never trust precompiled compilers. (And yes I know I can compile Haskell, but dosn't it take like 20 hours to compile? )

But I clearly remember the first stabbing pain that told me it was going to be something different than first advertised.

I confess I don't quite understand this. Than first advertised by whom? As far as I'm concerned, the first advertisement for Perl 6 was simply that we were going to look at Perl as a community and fix everything that needed fixing, and that it would certainly include making Perl powerful enough that we could write its parser in Perl itself. If things have changed from that, it's perhaps a sense of reality about how many things there were to fix. I expected maybe 20 RFCs, and we got 361. Our eyes were opened to the fact that pretty much everyone had tunnel vision about how to change Perl for the better, and that the sum of the community's pain was much greater than any individual piece of it. To me, we are still precisely on the originally announced target of having a community rewrite of Perl. We just didn't understand the scale of what that meant.

We also didn't understand the full ramifications of what it means to have a Perl 6 compiler written in Perl 6. Among other things, it means you don't really have to care whether the backend is using Haskell or Parrot or the latest and greatest VMs from MS and Sun. The current Haskell implementation of pugs is a nice prototype, but in the long run, Haskell is just another engine to run on.

As mentioned elsewhere, fglock has already bootstrapped a mini-Perl 6 in itself. And we're a goodly part of the way to having a full Perl 6 parser written in full-up Perl 6. See the standard grammar, which we can currently parse, but not quite run yet. But it's getting there. (Would you trust a precompiled compiler written in Perl 6?) Once we get to the point of being able to run it (on any of the engines), things will converge rather rapidly from there on.

I confess I don't quite understand this. Than first advertised by whom?

Somehow this reminds me of TV advertising. :-) What I remember (subjectively and from a perspective of a wannabe on the sidelines) was that Perl6 was going to be this great revolution in interpreted languages, where everything was going to be built on the Parrot ( a universal assembly language), and this would allow for Python, Perl5, Ruby (and whoever else wanted in) code to be seamlessly inlined into Perl6 code.

Now if my impressions were wrong, you can point that out, but I think many others were given the same impression. Maybe it was just part of the Parrot hype.... and Perl6 shouldn't be blamed for it....but it all has become confusing to me.

Can you estimate how long it will be before Perl6 can be compiled from C, like Perl5?

---

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Among other things, it means you don't really have to care whether the backend is using Haskell or Parrot or the latest and greatest VMs from MS and Sun. The current Haskell implementation of pugs is a nice prototype, but in the long run, Haskell is just another engine to run on.

Well, sometimes if fever gets me, I'm dreaming of a Perl 6 implementation in FORTH, but that's perhaps just my delirating style... ah, a perl chip! That would be IT! :-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I don't hate Haskell, but Perl5 compiles directly from C, and I'll never trust precompiled compilers.

So wait . . . your C compiler sprang forth fully formed from the brow of whom exactly, Kernighan or Ritche? :)

Sure you can make that comparison, but there is a vast army of programmers watching that gcc compiler, and I can trust that in those numbers, someone will start complaining if anything looks "fishy" in the code. The same isn't true with Haskell. The gcc I use can be bootstrapped from itself, although most people do trust the prebuilt Glib and compiler that comes with their distros. When I get time and energy, I usually try to recompile them for myself, just to see the differences.

So this all brings up the ultimate question of whether people will trust Perl6 ...... if there is this abstract Haskell layer in there.

I confess, I think I've just been given a negative feeling toward the word Haskell after watching Leave It To Beaver reruns all these years.

---

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Wow, you're just a bundle of optimism and hope tonight, aren't you? :-)

Andy, I agree that the people working on Perl 6 are aware of the complaints. My queries aren't so much for them as for the rest of the perl community. There are many people that have misapprehensions about Perl 6 only because no one has told them otherwise. The conventional wisdom (in broad brush strokes) has it that Perl 6 will never get here and they haven't seen any reason to believe otherwise.

My goal is to air out the wrong-headedness and FUD a little bit to hopefully better educate people on what Perl 6 is and what Perl 6 isn't. And that Perl 6 is not the end of Perl.

duff

I have plenty of hope and optimism. That's why I hope that you'll abandon this.

There's been plenty of dispelling of FUD. At this point, the only thing that really matters is results, getting the product out. There's no point in talking about what Perl 6 is going to be. That ship has sailed. We need to get the damn thing out, and anything that distracts from that is wrong-headed.

If you really want to help Perl 6, work on code, rather than talking about it.

Or, to quote Jesse Vincent's shirts: "Shut the fuck up and write some code". Failing that, don't distract those that are doing that.

xoxo,
Andy

What I like about Perl is that it's designed for fairly experienced/capable programmers instead of being optimized for complete beginners (P4E). Even in Ruby you have to keep typing "end" all the time. Yuck. I've sort of held out hope that Perl6 might take back the scripting-language market for programmers who don't need so much hand holding, but I wouldn't mind getting rid of any unnecessary historical cruft.

--Dan

Sigils are good because:
• The allow easier interpolation in strings
• They tell you the type of the variable (hash, scalar, array), a little bit like hungarian notation, but enforced by the compiler
• They keep your variables from clashing with reserved words, making it possible to safely add reserved words later without breaking existing code (or at least without interfering with variables in existing code).
Phil
The Gantry Web Framework Book is now available.

Well, those are all true to some extent in Perl 5 as well. In addition to those reasons, Perl 6 pushes sigils in a direction that makes more sense in the context of human linguistics:
• Sigils distinguish nouns from verbs, which is especially important when you wish to talk about a verb as a noun. Many human languages require noun markers of some sort or other. (English is interesting in generally requiring plurals to be marked rather than singulars, but there is much linguistic precedent for requiring both.)
• Sigils distinguish nouns from types and other adverbial notions, which helps the parameters in declarations stand out, and tells the compiler which parts of the declaration are intended as referential and which are intended to declare something new.
• Your typical noun phrase will contain a single sigil somewhere, and that marks the "head" of a noun phrase. This makes it really easy to figure out where to start reading a noun phrase.
• The sigils provide a "safe haven" namespace for twigils that mark extraordinary scoping in an immediately recognizable fashion. Unlike sigils, twigils can therefore have an unmarked form for ordinary $foo variables. Otherwise all the twigils would be confusable with prefix operators.
I'm sure I could think of more reasons if I tried, but those are good enough. :-)

What do I think? I don't even understand what you think!

Perl 6 is too much like Java

How so?

Perl 6 isn't Perl 5

Duh... If Perl 6 was Perl 5 we wouldn't be designing it, would we?

Perl 6 is being designed by committee

Your point being...?

Perl 6 is suffering from the second-system effect

I must admit I have no idea what that expression means... Could you explain?

Perl 6 is hurting Perl 5 by consuming resources

Not necessarily. What makes you think that the resources being consumed with Perl 6 would be diverted to Perl 5 if it weren't for Perl 6? Maybe those people would be spending their time and money with others languages instead!

So what I'd like to do ... present to the people working on Perl 6 in a "respond to these objections" sort of way.

And by that you'd be trying to achieve exactly what?

Wikipedia's abstract is a good summary of the second system effect, but really anyone doing any non-trivial programming should have read The Mythical Man-Month (ISBN 0201835959).

Perl 6 is too much like Java

How so?

(Etc.)

You misunderstand. duff is not presenting a list of his own objections, he's collecting objections he's seen other people make.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

Well, what you say makes sense, but...

I've seen various people bash perl 6 for a variety of reasons. Some of the ones I can think of right off are

From this, I really can't say if duff is presenting what he believes are reasons for people to bash Perl 6 or if those are the reasons those people invoke... Maybe it's my English...

duff, could you please shed some light? :-)

If what jdporter says is correct, I apologize :-)

Perl 6 is too much like Java
How so?
(Etc.)

You misunderstand. duff is not presenting a list of his own objections, he's collecting objections he's seen other people make.

Anyway, it's worth asking so. So: how so? Because the dereferencer is now a single dot? Because of Object Orientation pervasiveness? If the latter, then I can think of some other languages that would constitute a better target for a comparison. Anyway which one, apart Perl 6, will have it both just as pervasive and as transpartent, i.e. not invasive, at the same time? For the average user it would probably boil down most of the times to a bare .say in place of an argumentless print. All in all, great job I would say. Yes, even if it's yet unfinished as of now.

And by that you'd be trying to achieve exactly what?

Publicly airing the arguments I see/hear all the time in various forums. I'm interested in what the perl 6 team has to say about it. I hear lots of "Perl 6 sucks", but rarely do I hear the people working on Perl 6 respond. I've been kicking around an idea about doing a "virtual mass interview" and this topic seems relevant given the imminent release of Perl 6 (yes, I believe it is imminent).

duff

I hear lots of "Perl 6 sucks", but rarely do I hear the people working on Perl 6 respond.

Given the choice between "work on useful things" and "put up with someone complaining long enough to have the hope of a chance of responding with facts for the possibility of changing that person's mind", I've decided to work on useful things and occasionally respond with "contributions welcome, complaints not."

Publicly airing the arguments I see/hear all the time in various forums. I'm interested in what the perl 6 team has to say about it. I hear lots of "Perl 6 sucks", but rarely do I hear the people working on Perl 6 respond. I've been kicking around an idea about doing a "virtual mass interview" and this topic seems relevant given the imminent release of Perl 6 (yes, I believe it is imminent).

Good intent, but FWIW I hear all the time lots of "Perl sucks" comments altogether. I don't mind. They're mostly crackpots and trolls. They do suck. Well, their "arguments" do. Now, perhaps an important point is that "professional" freaks apart, there's one such rascal in any of us. At least some of these people may be nice persons and all, in other respects. You'll notice that there's not a common plot; they range from one extreme to the other: there are those guys who fear Perl is not open source enough, and then there's the one who fears its lack of corporate support. (Incidentally I had begun writing this post yesterday, I'm only finishing it now, and in the meantime he popped up with another gem.)

Now, the question is: does the Perl 6 subject matter really tend to feed the troll residing in otherwise respectable and even enthusiast perl coders of any level up to the point of making it emerge? (Well, I know of at least one world famous Perl hacker who last I heard of still was a strong opponent of Perl 6, but I would consider that a case apart and a story of its own.) Your point seems to suggest it does. This thread is an attempt at verifying whether this is actually the case...

My main objection to Perl 6 is that it will be mind-boggingly complex, both in semantics and possibly in implementation. It's not about new syntax, new object-oriented goodness, new regular expressions, new what-not; it's about all those together. I have read half a dozen Apocalypses, several Exegeses, and I cannot comprehend how anyone could understand the whole, much less how it's possible to implement it without errors.

Of course, the counterargument goes that you, as a programmer, need not learn everything, that you can use only a subset of the language. But that's not the point. Someone (or rather several someones) has to implement the whole wickedly large language, and even so that 1) the implementation and the specification match, and 2) there are no (engineering) errors (bugs) in the implementation. Will it be humanly possible? I'm doubtful.

On the other hand, I'll be probably among the early adopters once the first usable version of Perl 6 will be released. It contains a myriad of improvements over Perl 5, and a plethora of improvements over other existing languages, including Haskell and Lisp. I fully expect it to become a hugely popular language.