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.

Dynamic languages 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Not strictly related, but: "Ruby 1.8.6 and Python 2.5 are both first-class languages for Mac development [apple.com]".
    • I really don't understand why Apple don't list perl there too. Camelbones will support the scripting bridges stuff too, so it'll be just as "first class" as the others.

      Plus Camelbones has an awesome example app [sergeant.org].

      • I see you're the author of the awesome example app, heh.

        (I don't really even know what Camelbones is, but) I was wondering if you use Algorithm::BinPack [cpan.org] for that. Your kind of application is even mentioned in the synopsis (s/CD/DVD/) of that module.

        • I don't, because it would put things on the discs out of order, and I don't want that.
      • Well, it might or might not yet be a "first class citizen [mail-archive.com]" (which I mean to take "ships with the development tools"). However, you're right; unlike Leon's examples, there is a Cocoa bridge. I put that down to the fact that Sherm Pendley's worked for years on CamelBones with little or no reward, but at least some encouragement.

        I suspect the answer to Leon's original question is a combination of "nobody wants to do it", "nobody wants it" and "the Perl world is too insular".
        • Sigh, that reply to Leon's question doesn't make sense; let's try again. "Where's Perl?" "Nowhere, because either nobody wants it, nobody wants to do it, or the Perl world is too insular and nobody noticed anyone else doing it."
        • Nobody develops for Perl anymore, CPAN is too crowded.
    • Why? I'll tell you why.

      Because Perl is resistant to being processed by development tools.

      Plain and simple.

      This is the same reason that Google goes for Java and Python mainly, because you can write huge toolchains around it.

      Perl is impossible to parse.
      • What makes Perl impossible to parse (note: compared to Python)?

      • Is it true that a subset of Perl that eliminates string eval and a couple of other features is parseable? What's happened to efforts based on that?

        I'm running on low sleep, and there's probably an answer to this, and I should probably know it, but I'd like a refresher for my poor brain. :)

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

        • I think such a subset is conceivable, but it won’t be of much practical interest, as it must necessarily exclude BEGIN as well as assignment to globs, which effectively means no use.

      • Perl is impossible to parse.
        No longer so. Take a look at PPI [cpan.org], which is a programmatic way to parse and manipulate Perl code without perl. But I agree it probably came too late (2002? 2003?).
  • Perl is In a cold oven [ansys.com]. I sit forever before the oven, thinking about how hungry I am. When night falls, I do not turn on the light.

  • I think I have proceedings from TPC 4.0 including somebody's paper about doing this. I don't think it was ever finished.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • I ran across the "Dynamic Languages Symposium 2007" which doesn't list Perl as dynamic language in its synopsis either...
    http://www.swa.hpi.uni-potsdam.de/dls07/ [uni-potsdam.de]
  • 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.

      • That's a good point. My gut tells me the Java programmers who want to be able to use an easier language, but still interface with the Java libraries, will stick with JRuby. The rest will move over to Ruby 2.0.
        • 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, t

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.