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.
  • Why exactly is C supposed to be better than Perl for large systems (ignore speed of execution, assume that both can in principle satisfy your requirements)? What large-scale development advantages does it, as a language, have? What if you had raised an incredulous eyebrow and asked this gentleman, "you write large systems in *C*???" What would his response have been?

    It's kind of the thing I (try to) have in mind when I hear the word "enterprise". When a system gets big enough and lasts long enough, the

    • I agree, writing large programs in pure C is nuts. Writing large systems in anything that doesn't have automatic garbage collection, is nuts. OTOH other people argue you should only use a strongly typed language for large systems. So, we can't all agree. :)

      Despite the fact that he dislikes Perl, I largely agree with this guy [caltech.edu]. (I don't remember who pointed me to that article, it could easily even have been you (Ovid).)

      Anyway, if you define "system" as something that is really big, then I strongly feel that C
      • Despite the fact that he dislikes Perl, I largely agree with this guy.

        Thanks for the reference to that excellent article, (Scalable computer programming languages) [caltech.edu] by "this guy" (Mike Vanier).

        Given that he dislikes Perl, I noticed a couple of glaring omissions:

        CPAN doesn't even "come close" to Jarballs?

        Java libraries are wonderful, but no mention of CPAN anywhere in the article.

        Julian Morrison sent me this email:

        There's a very important feature you missed, and it's the real explanation for the success of Java: separable, atomic, pre-packaged, versioned functionality. Jarballs. Those, more than anything else, make reusability real. Java programming is about plugging together ready-built parts. Nothing else comes close.

        I have to agree with him on this, and it's a major omission from the discussion above (the component stuff is sort of related to this). I don't find Java to be a very inspiring language, but I like the Java infrastructure a lot (the same comment applies to C#). With Java, you can download packages and have pretty good confidence that everything will work as it should (with some caveats that I'll mention below). There are a bunch of features of the Java infrastructure that make this possible: bytecode, having the same virtual platform on every real platform, versioning, metadata, etc. but they all result in a chunk of code which (ideally) "just works". In fact, it doesn't always "just work" but it "just works" more often than in most other languages I've used.

        Vanier likes Parrot and Haskell, is waiting to see on Perl6, but doesn't mention Pugs

        Vanier on Perl and Parrot:

        I am not a fan of Perl. Basically, I think that Perl is simply Python with an incredibly obfuscated syntax and a few extra features that nobody really needs. Perl is incredibly non-scalable; I dare you to try to understand any Perl program of more than a hundred lines or so. The fault is not just the syntax; the semantics of the language are full of little oddities (e.g. overloading on the return type of a function), and frankly, I recommend that you just stay away from Perl. Maybe Perl 6 will not be as painful; but then, maybe it won't. I'll check again when Perl 6 actually happens.

        Parenthetically, one cool thing that has come out (actually, that is in the process of coming out) of the Perl 6 effort is an amazingly cool project called Parrot, which is a virtual machine targeted at dynamic languages. The goal is to have a common virtual machine for running Perl, Python, Ruby, Scheme etc. I like this project very much, so please check it out.

        Vanier on Haskell:

        Since writing the last epilogue, I've gotten very enamored of Haskell, which I've been interested in for a long time.

        Has anyone written to Vanier about these things? If so, what was his response, if any?