2010-08-06

Why Am I not using Perl 6 Yet?

I'm not here to deride it, I think its pretty, the syntax is nice, and it lacks some of the annoyances I currently have with Perl 5. Its got great features, and I whole heartedly want them to keep on trucking with that project.

My problem is not a petty squabble over things like Hurr, not perl5 enough or Derp, uses too much rams!, or Its too slow! or qualms about its completedness or its buggyness.

To a pragmatic person, none of those things really matter that much, you have to be doing really heavy work for speed and ram to be a problem on a Modern machine, and for a lot of things, I could not care less if startup time was a WHOLE SECOND LONGER. Hell, the total amount of time spent bitching about load time and speed now, in the real world, is likely to exceed the net total amount of time spent actually waiting for Perl6 to start. And the volumes of text and debate on this issue is almost certain to be a much larger waste of memory ( considering how much a single bit of information is replicated everywhere, and how it has to be replicated just to be *read*, and all the transport stuff that makes that possible ).

Back on the subject!

I think my biggest reason for not using Perl6 yet is that I'm not using Perl6 yet. I guess this is somewhat circular reasoning. but the problem is when I think "Oh, I have a task to achieve", my brain instantly starts forming it with regard to Perl5 and its idioms and methods.

Additionally, When I use Perl5, I'm not really spending a great deal of time messing around with its syntactical nuances. What I'm spending more time doing, is importing and using code and modules that already exists. I have a good mental understanding of all those great Perl modules from CPAN, and which ones I can JustUse to do whatever it is I want to be doing.

When I want to be doing something I don't already know how to do, the first thing I'm hitting up CPAN to see if somebodys done it already in a way I need, or to see if there are a few aggregate parts I can scrape together to make what I want

Also, most of my coding these days revolves around my various Perl5 modules, enhancing, maintaining, etc, and all this of course requires Perl5 to be employed. Its silly to consider depending on Perl6 to make a Perl5 module. And although I know I probably should be helping to reduce this problem by making Perl6 ports of my modules, its a bit chicken-egg because many of my modules are extensions for other Perl5 modules.

So, essentially, going Perl6 would require me to basically throw out everything I know, and then resort to doing things myself? If this is not the case, I don't understand/see how else I'm expected to do something in Perl6.

There's lots of fun examples of people doing raw hacking in Perl6, but I don't see boatloads of people using modules, and I don't see boatloads of Perl6 modules on CPAN when I'm searching for things I need to do.

If there's a secret second c6pan somewhere I'm just not seeing that these magically awesome Perl6 modules are being served on instead, Somebody should post a link to somewhere I'm likely to stumble over it.

Because presently, the gut reaction is barely better than suggesting I move back to PHP, where I have to reinvent every wheel myself in the event my behaviour is not implemented by a core PHP feature.

And the idea of being stuck back in that mindset is less than inspiring to me.

What would it take me to switch?

In a nutshell:
  • A much more obvious path to adoption
    • Obvious path to learning core syntax
    • Obvious path to finding extensions/modules
  • A More Comprehensive Archive of Perl6 modules.
  • Being things I currently use available on Perl6 in similar ways to how they are now, so I can jump ship, and start using those versions instead, and then start hacking on/improving those things with my own modules.

6 comments:

  1. Expecting Perl 6 to offer you the best of CPAN perl 5 right now is borderline ridiculous given the current state of affairs.

    Comparing Perl 6 to Perl 5 or any modern scripting language right now is unfair at best given how young and in infancy perl 6 is.

    To contrast:
    When did you learn perl 5? It was created in 1987.
    When did you learn ruby? It was created in 1993.
    When did you learn python? It was created in 1989.

    Im actually having a hard time finding out when rakudo started, but Parrot itself, the virtual machine that runs rakudo and is being developed concurrently was created near the end of 2001.

    Given the discrepancy in age, I think perl 6 is in great shape relative to its competitors. Within the next few years the gap is going to close rapidly.

    ReplyDelete
  2. @anonymous: Thats fine, sure, but to me, using any language is more dependent on its support libraries than its core syntax. If a library lacks support libraries, regardless of whether or not its core syntax is sexy, regardless of how slow it is, its not likely to garner a lot of attention for me.

    In my mind, expecting people to be migrating *right now* when the amount of CPAN modules are very limited is the borderline ridiculous notion.

    The solution of course is to start producing these modules to make it more attractive. =) . If we wait for Perl to be 'fast' enough before we start building these modules, I can't see large scale adoption hitting in the short term. And as large scale adoption is required to get the module growth up, chicken-egg hits again with a /perceived/ limitation imposed by how unattractive the speed is.

    ReplyDelete
  3. I don't think the Rakudo developers expect anyone to switch to Perl 6 right away and they are fully aware of the chicken and egg problem. The whole reason to release "Rakudo Star" was to try to help overcome it.

    The idea would be to increase the number of early adopters who start to build modules and application in Perl 6 and by that helping to drive the development and paving the way for the next wave of adopters.

    With that said Rakudo * also comes with a few modules you can already use and more are popping up on Github every day. You can also use a number of CPAN Perl 5 modules using Blizkost.
    See the full announcement for details: http://www.rakudo.org/announce/rakudo-star/2010.07

    ReplyDelete
  4. "In my mind, expecting people to be migrating *right now* when the amount of CPAN modules are very limited is the borderline ridiculous notion."

    As far as I know, nobody involved in Rakudo or Perl 6 expects people to migrate anything "right now". That's exactly why Rakudo Star is being described as an "early adopter" release -- we want people to help us build modules and iron out the kinks. We aren't claiming that everything should move to Perl 6.

    Even when Rakudo moves beyond "early adopter" releases, we have no expectation or desire to completely replace Perl 5 or CPAN.

    Pm

    ReplyDelete
  5. As a data point: I am right now implementing some modules useful to myself in Perl 6, and hopefully some of them will be useful to others. The Rakudo Star release worked for me, at least. I do not expect to use Perl 6 at work this year (we are a Perl 5 shop for now), but we are fully aware of it, much more so thanks to Rakudo Star.

    ReplyDelete
  6. The main killer feature that's missing for me right now is any sort of non-blocking IO features. Once Rakudo obtains some non-blocking, I shall have a go at porting IO::Async to Perl6, and then we'll see where that goes...

    ReplyDelete