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.
 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 s
    • 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 something I'm looking forward too.

        • 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.