Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why Perl 6 scares the hell out of me 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The mutable Perl 6 grammar scares me too, but I'm hoping that people never use it and it doesn't become a problem.

    In my "Bird's Eye View of Perl", the talk I give to managers, I talk about Perl being a single language that comes from the same source. The idea of multiple implementations looks good on paper, but it doesn't work out in practice. Besides knowing the core language and its libraries, now the mere mortal users have to wrestle with pecularities of each implementation and grammar. It the reason I stopped using Java a long time ago (and it's probably much better now). I didn't have anything against Java, but I wasn't going to waste my time making perfectly valid code work with the three or four slightly broken VMs. I hope that Perl 6 eventually won't have that problem.

    I'll wait to see what happens and what the reality is, but I'm certainly concerned since I'm writing Learning Perl 6. That's much easier if there is One True Grammar and One True Implementation instead of footnotes for "In Pugs this happens but in Some Other Thing this happens". Anything beyond that is a lot of work for the benefit of a few people.
    • The mutable Perl 6 grammar scares me too, but I'm hoping that people never use it and it doesn't become a problem.

      Yet, whenever I raise my biggest objection I have against Perl6 (meaningful whitespace), I always get thrown back "well, you can change the grammar you know...".

      • Yeah, I was just going to say that. "Just change the grammar" was used to end Perl 6 language debate sort of like "God works in mysterious ways" is used to end religious debate.

        Thankfully I haven't seen it come up as much lately. Maybe folks are starting to realize that easily mutable grammars are a powerful and awesome tool but not the sort of thing you want every kid on the block to use.
    • I see multiple implementations as a strength.

      At some point you simply HAVE to be able to have an IronPerl6 and JPerl6 simply for long term language flexibility and health.
      • I thought that was the point of parrot---you didn't need different implementations if you had the byte code.

        I don't see different implementations as necessary to anything. Some people might like it, but in reality people will code to the implementation's features. It happens in Java, Javascript, Lisp, Smalltalk, and probably a lot of others that I haven't used. The conversations at the pub are about who supports what and what you have to do to make good code on one implementation work on another.

        It's not so
        • There's going to be many cases where people are already standardised on a particular environment, typically CLI/.Net or JVM.

          They already have management infrastructure in place to deal with it, and if you can fit in with the existing it's a huge plus.

          Not to mention that if you can run on multiple implementations it's a huge advantage ecologically speaking, you can respond to environmental disasters much better.

          (Just look at how Catalyst dealt with the Class::DBI disaster compared to Maypole)
          • Catalyst dealt with the Class::DBI disaster by using something different. That's not how I want people to deal with Perl. :)
            • Similar analogy...

              How is some users of Python/Ruby dealing with their C implementations can be slow?

              By switching to JRuby/IronPython/etc...

              Similarly Catalyst survived by leaving Class::DBI, but nobody that was using Catalyst had to leave Catalyst. The same cannot be said for Maypole.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.