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 war between PostgreSQL and MySQL continues to rage, which is disappointingly stupid--they should be trying to steal installations from Oracle, just as Perl and Python shouldn't be fighting with each other, they should be taking the battle to C++ and Java.

    The cause of the infighting is obvious. Everyone likes to think they've made the right choice, so everything else must automatically become the wrong choice. This is sad. Personally, I think Java is a fine language -- if you have the right problem

    • Personally, I think Java is a fine language -- if you have the right problem space. I once found myself in the position of recommending Java over Perl due to this, but have listened to people be absolutely astonished that I could even think such a thing.
      I say with no malice or sarcasm: I'd be fascinated to know what this problem space was.
      --

      ------------------------------
      You are what you think.
      • No worries, I realize your question was legitimate and while I'm answering at length, don't take that to mean I misunderstood your intent :)

        I won't go into detail about the particular project, but as a general guideline, I think it's fair to say that while Perl can tremendously increase the productivity of individual programmers, Java is still a safer language for many programmers.

        In Java, you have to go out of your way to forget to check whether or not your file access was successful. There's not really an equivalent of open FOO, "< $foo"; (note the semicolon). Even changing the checked exception to a runtime exception will still eventually generate an error, if present. There are no such guarantees in Perl. (I think the analogous situation in the Java world is the newbie programmer ending all try/catch blocks with an empty catch that catches a generic exception object.)

        Another example would be method overloading. Due to proper method dispatch based on signatures, much of the conditional logic we see in Perl is not present in Java, thus eliminating a major source of bugs:

        public void foo (int x)

        public void foo (String x)

        public void foo (int x, int y)

        Those are three separate methods and, if they're all available as method calls for the same object, you rarely have to worry if the correct one is being called. To do that in Perl, you either use Class::MultiMethods or you you write bug-prone conditional logic:

        sub foo {
          if (@_ > 1) {
            # handle int x and int y
          }
          elsif ( $_[0] =~ /^-?[[:digit:]]+$/ ) {
            # handle int x
          }
          else {
            # handle String x
          }
        }

        Any Perl programmer should see plenty of problems with the Perl version of that. Those problems don't exist in the Java version, but you might think "so what? How often does that become a problem in Perl? Well, what if you have a code base of 80,000 lines and you have to trust that every one of your Perl programmers will always handle that correctly?

        Java also lets you declare private methods and data. Java also has data inheritence. You don't have those in Perl unless you jump through a few hoops. When you have a team of many programmers and you fail to notice that one person's bad habit of breaking encapsulation your life gets miserable. $foo->{bar} should almost always be $foo->bar().

        Don't get me wrong, though. There are plenty of things about Java that are just a royal pain in the rear, but you'll notice that the Java programmers still publish plenty of code. Just because you found that an autoloaded method call that tweaks the caller's namespace was a perfect solution for that very weird problem doesn't mean that the Java programmer won't find a solution. It may take longer but he or she will get it done.

        Perl is concise and powerful; Java is verbose and safe. If you have the money and you can't seem to find quality Perl programmers, the latter might be a better choice. If your choice of programming languages were limited to those two, you would need to assess the trade-offs of legibility, programmer availability, safety, power, expense, etc.

        Note that throughout all of that, I was talking about core language issues. There's no need to pull out the tired "applet/device driver" limitations to point out that different languages have different strengths. And note that all of the above is being given by someone (me) who strongly prefers Perl. Regardless of my preference, though, I would be doing myself a disservice if I didn't honestly examine a particular language's boundaries.

        • Hm.

          I guess there's a certain divergence in philosophy to some degree. "We want it to be easy to produce powerful things" versus "We want it to be hard to really screw up too badly". (I suspect highly that it makes it sound like I'm not an advocate of the second view. Philosophically, I do disagree with it. I suppose it's like the difference between anarchy and "relative policing" -- if you've got only self-restriction, you have a theoretically high freedom to do good things, but there's always some sc

          --

          ------------------------------
          You are what you think.
        • Perl is concise and powerful; Java is verbose and safe.
          That's probably the best two-sentence summary of the languages I've read.