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.
  • Perl already runs more places I care about than Java does, so to me, porting Perl to the JVM is an extravagant waste of time. Worse still, forcing Perl to be performant on the JVM would doubtless require language changes. Witness the recent trend of JRuby toward not implementing things because they're "too slow" or "too hard." I expect JRuby will either languish in obsolescence like JPython, or become a separate language competing with actual Ruby.

    That said, Perl's having missed the "OMG Dynamic!!!" tr

    • I expect JRuby will either languish in obsolescence like JPython, or become a separate language competing with actual Ruby.

      If Ruby 2.0 comes out soon and achieves many of its goals (especially with regard to performance and deployment characteristics), JRuby may be less appealing.

      • It'll have to be fast, because the JRuby guys are *very* good marketers. Watch how they gradually get people to refer to Ruby as "Matz' Ruby Interpreter" or "MRI", making it "just another implementation," and spin their really fast Fibonacci function into performance supposedly equivalent to Ruby 1.8. I don't think they're attempting a "language takeover," but they could almost certainly pull it off if they (and Sun) wanted to.
        • by djberg96 (2603) on 2007.07.26 20:26 (#56519) Journal
          I think that's a bit harsh. I personally have no problem with the term "MRI" since there are now multiple implementations (JRuby, IronRuby, Rubinius), and I don't use any of them.

          Performance may be an issue, but I think a much bigger issue for JRuby will be memory and cpu consumption. I don't know that it's solveable with the JVM, either. Then again, most Java programmers have never given a damn about apps like Weblogic sucking the life out of their systems, so they probably won't care if JRuby does it, too. :|

          • Performance may be an issue, but I think a much bigger issue for JRuby will be memory and cpu consumption.

            As I understand it (though one of my references is the JRuby literature), this is also a problem with standard Ruby and one of the motivations of JRuby.

          • It may be a bit harsh or paranoid, but I don't see how a language without a formal spec can survive multiple implementations. Python, Perl, and Ruby have been coherent so far because Guido's, Larry's, and Matz's implementations of their languages simply *are* those languages. Looking farther afield, even Java survived in part because Sun fought Microsoft tooth and nail to prevent its producing an alternative, incompatible "Java" (Visual J++?). Haskell thrives because GHC is the de facto standard. And Sc