Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: A wholly inadequate reply to an Anonymous Monk

by meraxes (Friar)
on Apr 23, 2010 at 01:17 UTC ( #836381=note: print w/ replies, xml ) Need Help??


in reply to A wholly inadequate reply to an Anonymous Monk

I've never understood the hysteria around Perl 6. Which is to say, I don't get why sooooo many people like poking at it as if it's a "weakness" of the Perl community, that it's vapourware or it's being done wrong and so forth. I've skimmed the Perl 6 design notes meetings since chromatic started publishing them. I've repeated peeked at how many spec tests Rakudo is passing. I've perused moritz's excellent Perl 5 to 6 posts which were awesome. I haven't gotten deep into Perl 6 though because I just don't have the time at this point in my life.

But I will.

Hopefully on Rakudo * as that's about when my life should slow down a notch. Because I know it's coming. Because I know there are great people like Patrick working on it. Because it's interesting. Because I can.

At the same time I know Perl 5 isn't going anywhere for a while either... and I like the new stuff perl5porters have been doing there. I'll happily hack at Perl 5 for years to come.

So, thank you Patrick, particularly in this difficult time for you. Thank you for your work. Thank you for your time. Thank you for caring about doing something right.

People need to stop worrying about Perl 6 and let these folk do what they need to. NOT having Perl 6 right now hurts no one. If you really have an issue with how it's being done, get involved. I think "Anonymous Monk" does serve a purpose but I'm always sad when it's used as a shield so someone can pass judgment or be unreasonable or just plain rude. Be constructive and be helpful.

meraxes


Comment on Re: A wholly inadequate reply to an Anonymous Monk
Re^2: A wholly inadequate reply to an Anonymous Monk
by pmichaud (Scribe) on Apr 23, 2010 at 01:24 UTC

    This is a good point to also add my personal thanks to you for the well-reasoned responses to the FUD both here and in other forums like Ars Technica. I do really enjoy it when you and others are also shining lights through the smoke screens that some authors keep throwing up (although not as much as I would enjoy not having any smoke in the first place).

    Thanks.

    Pm

Re^2: A wholly inadequate reply to an Anonymous Monk
by Anonymous Monk on Apr 23, 2010 at 06:56 UTC
    Here's another anonymous monk, aren't those guys annoying? Anyway no disrespect to anyone, and I wish Patrick and his family all the best.

    I'd like to say that I think the Perl 6 team is doing a great job, it's a difficult task with few people people working on it.

    But "the hysteria around Perl 6" is basically the following:

    We got Perl 5 in 1994, around 2000 we got the Perl 6 announcement and initially had a submission process for new ideas. If you read some of these you'll see that people mostly didn't want to turn Perl 6 into the total rewrite it has become. Most of the suggestions were along the lines of fixing the return value of chomp, giving us a better object system, or fixing path handling. How about having a built-in way to slurp a file?

    In short, Perl 6 might have been basically a re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4. Only this time we could break backwards compatibility to fix some of the hairier bits.

    Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN) and cleaned up the worst warts. Had we cleaned up the worst parser edge cases you might be running jPerl on your JVM now instead of jRuby.

    Instead Perl 6 took the form of creating Carl Sagan's apple pie. Before it could be created they were going to invent the universe. Parrot was to be created from scratch not only to run Perl 6, but to run everything. Perl 6 was going to change everything. We weren't going to use CPAN, but a all new CPAN6 (still no sign of it) etc. The rationale for Parrot in particular seems a bit suspect in retrospect.

    It was claimed that there was no existing VM that could run a lot of dynamic languages, now it turns out that the JVM/.Net can do that just fine (the VM isn't static, it was just Java that was), and of course there were already Lisp / Scheme VMs (Guile is now running multiple languages).

    10 years later we still don't have our apple pie. I'm not contributing (much) so I'm not complaining. But it's interesting to speculate on what could have happened differently. Maybe we'd have a Perl 6 for 6 years already by now, Ruby would have never taken off as it did, and some of the Pythonists would have come back. Maybe I'd get something else than "Oh Perl, that ugly old crap" and "Perl 6? Aren't they writing DNF in that?" from people at (non-Perl) conferences, but alas.

    Perl 6 is really neat. But even if Rakudo steams on ahead we're probably 2-3 years away from anything approaching a feature complete and usable compiler for Perl 6 with a basic module library. We're probably going to need another 5 or so to get decent Perl 5 <-> Perl 6 integration and uptake.

      In short, Perl 6 might have been basically a re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4. Only this time we could break backwards compatibility to fix some of the hairier bits.

      The problem is that--with that process--it still takes eight years to build Python 3, and then you don't get an object system like Moose, you probably don't get pervasive laziness, you don't get pervasive closures, you might get hypotheticals, you don't get grammars, you might get continuations, you probably don't get custom operators, you might get multi dispatch, and you probably don't get a rethinking of context and the type system.

      You might get multiple implementations cooperating around a canonical specification. You almost definitely don't get a self-hosted grammar as part of that specification.

      You don't get roles.

      You get Perl 5 with some of the worst bits of Perl 1 - 4 removed. Yippee.

      Also you're very, very wrong about the JVM. Invokedynamic is only the start, unless you want to throw away partial binding, multiple dispatch, continuations, coroutines, lightweight concurrency... or spend the rest of your life writing trampolines.

        PerlMonks keeps hanging forever when I try to submit a reply, but here it is: http://pastebin.com/MchyhtVg
        You get Perl 5 with some of the worst bits of Perl 1 - 4 removed. Yippee.

        At least we would have got that. That is still better than getting nothing at all.
        unless you want to throw away ... lightweight concurrency...

        Do we have lightweight concurrency?

        Eight years for Python 3 is a selective example. Much of that time was spent dragging their feet because they were in no hurry.

        A much better example is PHP 4 to PHP 5. Now, we can all agree that PHP is a pile of dung but PHP 5 is much *much* better than version 5. And it took just 4 years (first 4 release: 2000, first 5 release: 2004).

        The Perl core was already good in 2000. I'd like to have seen what a similar effort without the constrains of backwards compatibility would have been like *without going too wild*.

        We have an object system like Moose on Perl 5 now with Roles and all; So I don't see why we couldn't have one on a cleaned up Perl 5 (the hypothetical Perl 6). Same goes for grammars, they're halfway there in Perl 5.10. Custom operators are there in 5.12 with ugly parser hooks, etc.

        We've had 10 years of very productive Perl 5 development. It would have been very interesting to see what those 10 years would have been like had some of the uglier parts of the core been deprecated in favor of some of the features in Perl 6.

        As for the JVM I don't think I'm that wrong. I'll give you continuations and coroutines but lightweight concurrency? Have you looked at Clojure? Its hello world demo is a ~100 thread application and it's been known to run up to a thousand threads or so pushing a few gigabytes of data per second around on a few hundred cores. It also does multimethods (Lisp-style). And in any case the JVM seems to be able to emulate these things just fine even if you don't use its native calling conventions.

        Anyway discussing VMs for some of the more fancy Perl 6 features is getting a bit sidetracked (although I'd still be interested in why some of the Lisp VMs weren't adapted).

        I just wanted to reply to the OP (without any hostilities) who was curious as to what the "hysteria" might be about. My posting sought to aggregate some of the most common concerns that I've heard. That's all.

        For a lot of people (including me) Perl 5 is what pays the bills. There isn't a single company (correct me if I'm wrong) that's doing Perl 6 development (despite claims that "you can use it today!").

        I think it's understandable given all that that 10 years later we only have a pre-alpha implementation and little uptake, and bad some bad PR for Perl externally.

      Only this time we could break backwards compatibility to fix some of the hairier bits.

      (...)

      Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN)

      Who else spots the logic error in here?

      Perl 6 - links to (nearly) everything that is Perl 6.
        Will Perl 6 be compatible with existing CPAN modules, I mean CPAN modules for Perl 5?
        Who else spots the logic error in here?
        With an approach like use 5.10.0; and use feature, there's no logic error. You can both have Perl 5 compatibility and cleaner behaviour for new scripts.
      Thank you this was the best anonymous post in a while expressing much of my thoughts much better than I could.

      I wholeheartedly support the "Rakudo/Parrot/Pugs/Ponie/whatever..." team but IMHO most of the problems and tensions are the result of a communication tragedy.

      Honestly, Perl6 should be renamed into something like Perl++.

      It's much more than the next evolutionary step of Perl5, it's incorporating revolutionary concepts which can't be achieved in normal release steps..

      But at the same time we are living in a marketing world, where the crowd measures the quality of a product at the release numbers.

      Releasing a Perl5 compatible successor, maybe just bundling Moose for OOP and Coro for multithreading and maybe some syntax cosmetics and restriction│ to contradict the "write only language" complaint would easily cannibalize the Ruby spectra like they are actually cannibalizing the Python spectra.╣

      But sadly such a successor can't be named Perl6, because this name slot is already taken.

      And at the same time the "Perl++ team" has to cope with the burden and pressure of the whole community impatiently waiting for a answer to the contemporary needs.

      They are constantly forced to justify why they are making gold, where the market just needs iron to be turned into steel. ▓

      Thats a marketing desaster!

      Perl5 is somehow in the situation of Neanderthals who are told by the gods that further evolution is useless because Sapiens Sapiens will arrive in Europe and wipe them out.

      Actually it took thousands of years to replace them ...

      Cheers Rolf

      UPDATE: added links and to title and improved language

      Footnotes:

      ╣) It's so paradox to see how a beautified syntax on Perl semantics plus Smalltalk object model named Ruby easily takes steadily growing market shares ....

      ▓) and let me be clear Perl++ IS gold, but meanwhile our customers live in the stone age and are going to other jewelers to buy gems made of iron...

      │) perl critic but anal!

        It's so paradox to see how a beautified syntax on Perl semantics plus Smalltalk object model named Ruby easily takes steadily growing market shares ....

        That wouldn't have been the case if a better alternative was available.

        The only restriction that could stop any language from being considered write only, is the restriction of the people that use it. With enough idiots, you get enough horrible code. And the number of hoops they have to jump through to shoot themselves into their feet doesn't matter.

        Besides quite a few people would consider anything that contains regular expressions write-only. And I ain't gonna loose regexps due to some clueless script kiddies.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

      Here we go again, a post that is almost entirely filled with speculation divorced from reality... (see how many "might haves" and "maybes" there are in the post).

      If you read some of [Perl 6 RFCs] you'll see that people mostly didn't want to turn Perl 6 into the total rewrite it has become. Most of the suggestions were along the lines of fixing the return value of chomp, giving us a better object system, or fixing path handling.

      First, I claim that "giving us a better object system" (i.e., Moose) would not have happened without having first having had the opportunity to see what would be done by a total rewrite. (In particular: multimethod dispatch, function signatures, strong typing, invariant sigils on variables, and twigils.)

      Second, I think that what Larry and the cabal eventually discovered (I wasn't there at the time) was that you couldn't incorporate most of the new suggestions into Perl without first going through a total rewrite. Yes, some of the ideas from Perl 6 are now making it into Perl 5, but I claim that this is possible only because the ideas were discoverable as part of the exercise of creating a total rewrite. Even if you claim the new concepts would've been achieved via a simple re-iteration, I'll still contend that the evidence shows that the timeframe wouldn't have been significantly shorter than what we have now (see below).

      In short, Perl 6 might have been basically a re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4. Only this time we could break backwards compatibility to fix some of the hairier bits.

      I wasn't involved at the time of the RFCs, but my understanding is that the issues involved in bringing these new features to Perl were (and still are) far greater than simply dealing with backward compatibility. A number of Perl 5 experts have told me that the other reason for "total rewrite" with Perl 5 is that fixing Perl 5's core codebase would also take a huge amount of work and have uncertain chances of success. And guess what, those experts were correct -- it took 7.5 years to get from Perl 5.6 to Perl 5.10. Thanks to the heroic efforts of a number of pumpkings and core hackers, the Perl 5 codebase of today is orders of magnitude improved over what existed in 2000. But I also believe (from what others have told me) that many of the fundamental problems are also still present.

      (Anticipating those who will say "Perl 5.10 would've arrived much quicker if we hadn't gotten distracted by Perl 6", please (1) cite your evidence for such a claim, and (2) note that many well-known Perl 5 experts and insiders, including pumpkings, strongly disagree with the notion that work on Perl 6 has impeded Perl 5 development in any significant way.)

      Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN) and cleaned up the worst warts. Had we cleaned up the worst parser edge cases you might be running jPerl on your JVM now instead of jRuby.

      I think this is even more speculation contradicted by available evidence. I don't know of any Perl 5 core hacker who seriously contemplates making significant changes to the Perl 5 parser, or that such changes could reasonably happen in just a few years. And I certainly have plenty of evidence available to indicate that even minor changes to the Perl 5 parser have taken years for evaluation, testing, and being incorporated into an actual release.

      Several Perl 5 experts (again, including former and current pumpkings) have told me that Rakudo and Perl 6 remain Perl's best (and some say only) chance for Perl (both 5 and 6) ever making it to the JVM or .Net virtual machines. And anyone who wants to port Perl 5 to other virtual machines would certainly want a better parsing engine than what is currently available, which brings us back to needing a new grammar engine, which brings us back to needing Perl 6.

      It was claimed that there was no existing VM that could run a lot of dynamic languages, now it turns out that the JVM/.Net can do that just fine...

      Okay, you're essentially accusing the Perl leaders of 2000 of having imperfect foresight. And you're omitting the fact that JVM and .Net weren't at all "open platforms" then (and in many ways they still aren't), so if "the new Perl" needed something not available through those VMs at the time, there was little chance of having that something added in a timely manner.

      Regardless, the debate about whether Perl should have pursued a new VM is ultimately a red herring in my book. My other points still stand-- even using Perl 5 as the underlying VM it has taken Larry a couple of years to write up a parser for our new language. And from an early date that parser has required Perl 5.10 and Moose, neither of which were available in any sort of usable form until 2007 at the earliest.

      (I grant that it's entirely plausible that Larry could've created his standard grammar implementation using 5.8 and without Moose. But my speculation is that Larry would've instead taken the time to design something like Moose and the additional features he would need in 5.8 to support the grammar. Which, if you think about it, is in fact exactly what has happened. :-)

      10 years later we still don't have our apple pie.

      Answer 1: I have an apple pie, and a new and better tasting apple pie shows up at my doorstep each month. Perhaps the apple pies I'm receiving aren't sufficiently cooked to your culinary standards (yet), or aren't the type of pie you're looking for, but it's wrong to claim there aren't any apple pies being produced.

      Answer 2: Maybe you don't have your apple pie yet, but I guarantee that your Perl 5 pie is now much tastier and better for you because of the work that has gone into making the Perl 6 apple pie.

      But it's interesting to speculate on what could have happened differently. Maybe we'd have a Perl 6 for 6 years already by now...

      No, you'd likely have a Perl 5.10 that would be called "Perl 6". And you would have only had it for two years (Perl 5.10.0 was released in December 2007). It would probably be seen as having the same level of "incremental improvements" over Perl 5.6 that Python 3 does over Python 2, and with a similar (slow) adoption rate.

      It probably wouldn't have had the ~~ smart match operator, cited as "the most exciting change" in Perl 5.10 over Perl 5.8.

      It would still be considered ugly (many people find Perl 6 much less ugly by comparison). And Ruby and Python would still be where they are today.

      If the speculations being offered were being used to improve on what is happening today, then I might agree that it's "interesting to speculate". But much of what I see is speculation used to justify FUD like "10 years later we still don't have our apple pie" and "We'd have Perl running on the JVM by now", i.e., statements that I find to be totally unsupported or contradicted by the available evidence.

      Pm

        Second, I think that what Larry and the cabal eventually discovered (I wasn't there at the time) was that you couldn't incorporate most of the new suggestions into Perl without first going through a total rewrite.

        This was exactly the conclusion of the RFC process. Larry et al decided that there were enough contradictory proposals to patch problems on the surface that any real redesign of the language required deeper thinking to achieve cohesive consistency.

        Any alternative history which glosses over the Perl 6 RFC period (or, as is the case in this thread, ignores it outright) has divorced itself from reality and entered instead the weird realm of Perl 6 Fanfic. I half expect to see a hard requirement for a race of militant space pandas enslave Europe in some of these alternate proposed project plans.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://836381]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (9)
As of 2014-09-17 08:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (66 votes), past polls