The Perl 6 project 10 years old today
use.perl.org
use.perl.org
You must not have learned too much, or else you'd have no reason to go back! :)
This right here is what I've always hated about the perl community. It's so rare to find a perl user who can mention the language without spouting these kind of exaggerations and untruths.
Of course you could always prove me wrong by demonstrated how perl is "flexible" and "capable" in a manner that is unprecedented [1].
[1] un·prec·e·dent·ed
adjective
without previous instance; never before known or
experienced; unexampled or unparalleled: an
unprecedented event.On the second part, I did misread the OP as meaning he would return to perl 5 (probably a false mental cache hit, since this is usually the context of such comments). Perl 6 does indeed have a few interesting bits.
Somehow Perl 5 made CPAN possible (and by deliberate language design), so that guy in a kilt seems truly a Scotsman to me.
This is why when people like chromatic invariably comment in a "still waiting for perl 6 thread" that "you can write perl 6 now!!11!" I roll my eyes. (Quietly. So they'll go away.)
Obviously there are people working on Rakudo and other Perl 6 implementations that spend their time writing Perl 6. But there's also people writing wikis, NES emulators, testing tools, build systems, and many other things in Perl 6. When people like chromatic say that you can write Perl 6 now, they aren't speaking based on hypotheticals or beliefs; they're speaking from experience. And, in my personal opinion, despite the NYI status of some things, bugs in the implementations of other things, and slow performance, writing code for Perl 6 is an amazing and wonderful experience. No, I wouldn't rewrite mission-critical systems on which people's lives depend in Perl 6 yet. Yes, I might write systems on which my life and future depend in Perl 6 right now. I definitely would and do write my side projects and one-off scripts in Perl 6 right now.
There are risks involved in every technology choice made for every program. If I didn't actively prefer perl5's semantics and community philosophy in a number of places, I'd be seriously evaluating perl6 for use in code where I could guarantee deployment to be pinned against a particular runtime version, just like I -do- use API-unstable perl5 libraries where I can guarantee deployment against a particular library version and the benefits in terms of delivery time outweigh the risks.
Almost five years ago now I ported a piece of Perl 5 code used millions of times a day to Perl 6. Where is the hyperbole in my statements?
Perl 6's approach to syntax, operators, grammars, language extension, etc. is like Common Lisp's reader macros; except that Perl 6 makes them easy and composable. Common Lisp libraries tend to use reader macros very sparingly because it's hard to make them play together nicely. Perl 6 makes it easy to alter the syntax in ways that play together nicely. Many of Rakudo's core operators are defined in normal Perl 6 code. It's trivial to make new ones of your own. The more extensive grammar modifications aren't quite there yet, I think, but it'll happen, and it will be revolutionary.
Fortunately, it hasn't stalled. It's moving along quite well.
Are Camlp4 extensions lexical? Can you load some syntactic extension within a single function and have it apply within only that function's lexical scope?
If I understand Camlp4 correctly, it's essentially a pre-processor. It's a very powerful pre-processor, perhaps, but you'd probably have to work very deep magic to be able to replace the Ocaml parser for a lexical scope. This is not yet implemented, but eventually you'll be able to do 'supersede slang MAIN { ... }' and rewrite the grammar the current lexical scope.
How easy is it to use Camlp4 extensions from OCaml programs? In Perl 6, it's a simple matter of "use SomeModule;".
Here's the code of a module to provide a factorial operator.
module Factorial;
multi sub postfix:<!>(Mu $n) is export {
[*] 1..$n;
}
use Factorial;
say 5!; # outputs 120
I'm afraid I don't have any examples of more extensive grammar modifications, as Rakudo doesn't have much support for them yet. More accurately, it doesn't have support for adding them in mid-parse yet; it's fairly simple to create a new grammar class deriving from Rakudo's Perl6::Grammar with a few modifications and parse files with it.
Perl 6 has brought parsers (I guess we should call them "grammars" in analogy to "regular expressions") to certain parts of the (shrinking) Perl community, but the everyday programming in general hasn't been lit aflame. Perl was influential enough to get regexes (in one form or another) into nearly every language in popular use today.
That isn't quite true. A lot of the things that are happening in P6 have been backported to P5 and in general has made everyone excited. It is has also "revitalized" the people working on the core of P5 to think new thoughts as well.
I don't know if I will move to P6 but I am thankful for what it has done to P5.
I'm one of the Perl 6 developers, and IMHO the regexes and grammars are one of the "killer" features. And I've also seen them evolve gradually, and have used them for various purposes.
What gave you the impression that it has stalled? Is that the general impression on the outside of the Perl 6 community? What kind of marketing could we do to reach you?
If you wanted to keep continuity with the Perl line, then from the outset, it might have been a better idea to plan out a roadmap for Perls 6, 7, 8, and 9 rather than just Perl 6. "Perl with grammars" can be released and then you can move on to the next iteration. "Perl with grammars, objects, lazy evaluation, macros, junctions, optional static typing, and not just one but two kitchen sinks" will take upwards of 10 years to reach final release status. This has the benefit of increasing usability as idioms and common practices for new language features can evolve as each set of features is released. In practice a lot of this has been done for you ("Perl with objects" became Perl 5 + Moose).
Since that didn't happen, I think casual observers are suspicious that second-system effect has taken place with Perl 6 and that it may never really be done.
The respective communities for the two languages now very much regard ourselves as two fascinating languages in the same family - one very much production ready, the other still polishing that side but a stunning work of language design research already.
Now it's just a case of our marketing catching up with reality.
Did you mean to write "Perl 6 is not Perl 5"?
Without disagreeing with you, I wonder how you can judge the marketing success or failure of a project intended to last at least 20 years at this point in its adoption cycle.
Are there any valid criticisms to be made of Perl 6 or its process?
Certainly. The failure to have a Perl 6 running on Parrot within a few months of Parrot's inception hurt development immensely. The RFC process demonstrated that the initial idea of a Python 3000 style rearranging of a few external features and some internal structures was not nearly ambitious enough. Rethinking regular expressions into grammars was a huge example of hubris.
My point stands, though: the intent of Perl 6 was never to create a language or runtime or compiler which would gradually succumb to a Perl 7 which would gradually succumb to a Perl 8 and so on. Since the RFC process the intent of Perl 6 has to been to create a Perl which solves the limitations and flaws of Perl 5 and can thrive for the next twenty or more years.
Put another way, the most important feature of Perl 6 is that is provides what Larry always intended of Perl 5: a language which allows you to create your own lexically-scoped dialects as necessary.
The intent was to completely set aside iterative development in favor of a big design up front which is supposed to last decades without change, like some Egyptian pyramid or the Great Wall of China? And this intent came about because of a desire to fix all of Perl 5's flaws and limitations all at once?
That is one of the classical blunders! The most famous of which is "never get involved in a land war in Asia", but only slightly less well-known is the Second System Effect!
Goodness, no--quite the opposite. The intent was and still is to allow iterative development and in-place upgrades, rather than requiring repeated flag-day breaks of backwards compatibility (the "it's obviously time to increment the major version number").
And the other implementations have it even worse... How am I going to tell sorear that, despite probably averaging over a dozen commits to Niecza[0] each day since the beginning of the month, and the incredible progress he's been making with it, he's doomed because he isn't trying to implementing everything all at one?
Joking aside, no one's trying to implement every feature of Perl 6 at once. The developers of the various Perl 6 implementations are trying to implement feature after feature. Sure, some of them are so productive that the Perl 6 implementation on which their brains run must have implemented auto-threading, but even they aren't trying to implement everything before they make a release. Rakudo's 31st compiler release is this Thursday; and Rakudo [1] is coming out the 29th. Pugs[2] has had quite a few releases. Pawel Murias just released Mildew[3] and STD.pm[4] on CPAN.
Rakudo , for example, isn't going to have all of Perl 6 implemented; but it has quite a bit, and that quite a bit includes some great things, some of which no one else is even trying to do.
[0] http://github.com/sorear/niecza/commits/master [1] http://rakudo.org/node/73 [2] http://hackage.haskell.org/package/Pugs [3] http://search.cpan.org/~pmurias/Mildew-0.03/ [4] http://search.cpan.org/~pmurias/STD-0.02/
If you meant to ask "Why not release a cut-down version of Perl 6.0 several years ago and iterate on that so you could be up to Perl 6.5 or something by now?" the answer is more complex. First, the most necessary feature of Perl 6 to allow for in place upgrades without falling into the morass of backwards compatibility that slows down the development of Perl 5 was not yet ready. That's a difficult problem and one you don't get many chances to do over.
Second, none of the implementations were mature enough to recommend for general purpose use. (That's as much due to internal strife in Parrot as anything else.)
I highly recommend perusing his well written blogs that wonderfully explain difficult programming topics.
This meaningless statement really bugs me. People who write Python and Ruby aren't rockstar engineers. They're just programmers/developers/[whatever you like to call them].
People who speak English are simply English speakers. Nothing more can, nor should, be inferred from that fact.
Assembly programming is different enough to Ruby programming that it does imply something about a person that prefers working in either the former or latter environment.
However, the reason I agree with you and upvoted you is that Ruby, Python and Perl are so similar in mindset that anything you might learn from those choices is basically lost in the noise. It's like trying to figure out what a person's choice of colour of parachute means... which is silly, but the fact that he or she skydives does mean something.
Python and Ruby communities are radically different. Ruby people tend to be in their 20s and primarily employed to do Ruby, mainly for websites. Python people tend to be older and write Python as a part of their main job, they are not employed as programmers (and as such language choice is not mandated).
http://www.joelonsoftware.com/articles/fog0000000017.html
However, Joel explicitly states this means you release early, and iterate.