There's nothing wrong with taking 10 years to create something new. Since they began, I've taken serious ganders into java and ruby. Now that I'm back in the perl camp I find that I know a lot more about programming in other cultures. And now that the community is just about done, I can apply what I've learned using a "language" unprecedented in flexibility and capability.
> I can apply what I've learned using a "language" unprecedented in flexibility and capability.
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.
Do you know of another language community with a library or extension system which rivals the CPAN, for one example? How about the existence of PCRE for another? Along those lines, have you seen Perl 6 grammars?
The post I responded to said "language" so your comment about CPAN doesn't apply.
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.
Confusing response. If you want to get down to it, CPAN doesn't really provide much more functionality than what you can get in most other languages and provides less than what Java has. CPAN has a tremendous amount of duplication, has a fair amount of toy code, etc., etc.
"I count 33 synoptic documents at perlcabal.org. Synopses 2 through 6 tend to be fairly stable, although changes still occur. The remainder of the synopses are still drafts for the most part, awaiting more feedback from implementations and language use."
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.)
I'm not sure how much Perl 6 chromatic writes on a daily basis (I'm mostly only familiar with his work on his book and the Perl 6 book and his magical ability to constantly find another 2-6% performance improvement for Parrot), but there are quite a few people writing Perl 6 already.
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.
People can, and are doing. Much though I'm a happy perl5 programmer, I often use bleeding edge libraries in my implementations when I'm sure that's the best approach (and if it's code for a client after careful consultation with them). People I know doing rails work often use stuff they know may change under them because it lets them ship faster now and they consider it an acceptable trade-off of risks - and the gems they're using generally don't have a spec document at all.
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.
One promising thing about Perl 6 was the way it tried to bring parsers to everyday programming the way Perl popularized regular expressions. I'm sad the language seems to have stalled for that reason.
You're almost exactly right there. One promising thing about Perl 6 is the way it brings parsers to everyday programming the way previous Perls popularized regexes. :)
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.
"Everyday programming" doesn't necessarily use Perl, and it rarely uses prerelease programming languages.
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.
> everyday programming in general hasn't been lit aflame
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 not very familiar with Camlp4. I tried skimming the tutorial to see if some of the big benefits of Perl 6's syntactic extension are there, but couldn't tell.
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;
}
And an example of using it:
use Factorial;
say 5!; # outputs 120
This is actually essentially how many of the built-in operators are provided in Rakudo. The ones that aren't provided in this way are the ones like || and && with short-circuiting semantics which need to be evaluated specially and the ones that are better implemented in PIR.
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.
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?
From a marketing standpoint, calling it "Perl 6" is a terrible way to market it. Perl 6 implies that it's Perl, which has both good and bad connotations, and it also implies it's just an iteration on Perl 5, when in fact it's one of the most ambitious languages ever conceived. An ambitious new programming language can take ten years to develop and people are only halfway suspicious that it took so long. An iteration on Perl 5 should take nowhere close to ten years to finish. So don't call it Perl 6 :)
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.
In my mind they made the same marketing mistake Microsoft did. You had VB6 and then .NET came along and they tried to say that VB.NET was just another VB. VB.NET is totally different. Perl6 is not Perl.
As I said in my Iron Man forfeit talk, I'd quite like to see the perl6 spec renamed to Camelia Perl - and perl5 renamed to something else as well.
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.
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.
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.
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!
The intent was to completely set aside iterative development...
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").
Of course not. What gives you the impression that this is the case? There will be a Perl 6.1 with features not present in Perl 6.0 in the same way that Perl 5.12 has features not present in Perl 5.10.
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.)
If so, I guess we're not going to get Perl 6 after all. After all, all the existing implementations have adopted strategies of getting some features working then getting more. It certainly looked to be working pretty well. I mean, in the last month, I've used grammars, feeds, hyper-ops, lazy lists, and many of the other cool features Rakudo has already implemented. I mean, feeds seriously got added last night. Any project still adding wonderful features like feeds after 30 public releases can't have much hope, if developing Perl 6 requires implementing every feature addition at once.
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.
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.
I think that people blow it out of proportion, but the primary language choice (and I do mean the language they use when they can chose) of a developer does imply something, however small.
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.
I like Ruby and assembly (and C, Python, Lisp, JavaScript, ...). So I agree that one's primary language may say something about them, but that something might only be that they happened to land a good job doing X.
No, choosing a (Turing-complete) language is really choosing a community, of people who work on the same things you do in a similar way. Community implies shared values. Python's belief in there being only one correct way to do it, for example, is anathema to Ruby and Perl types. Ruby people like being called "rock stars" or "ninjas" (or it wouldn't be widespread in their community, job ads, blogs, etc etc). Just like Perl types like being called "wizards" (see how many times the word "magic" appears in the documentation).
We absolutely do not all like being called rockstars or ninjas. I do agree that the communities are different but the differences are usually not that important when comparing languages that are very similar, such as Python and Ruby.
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).
Gross generalisation though any such attempt at a single word summary is, I'd say that's nonetheless pretty true at least from the Perl side of things - the 21st century landscape of both the perl5 and perl6 communities is very much about people who consider themselves "Just Another Perl Hacker" - in that while we might be proud of our achievements, there's very little arrogance about our code itself. Of course the lack of "wow hey this is awesome look at me" is one of the key things leading us to need to learn more marketing as a community, but I'll take quiet pragmatism over loud arrogance any day as the primary mindset of the authors of the things I'm depending on in production.
I kind of toyed around with adding a little addition to langpop.com looking at the 'rockstar ratio': overall popularity compared to "rock star" sitings in the job ads. Never got around to it though...
Pugs first came out in 2005, and by my count it was the third implementation of Perl 6. Rakudo's a couple of days away from its 31st release. Yes, Perl 6 should have had regular releases much earlier than 2005, but we've used iterative development for years.
I think you're referring to the belief that it takes 10,000 hours of practice in order to "become a world class expert in anything." This "10,000 hour rule" was made famous by the book Outliers and is primarily based on the research of K. Anders Ericsson. 10,000 hours of practice is often equated to 10 years, though I'm not sure if the book explicitly makes this parallel.
