use Perl

• yeah, that's fair (Score:3, Insightful)

  by lachoy (1663)

  <rant>So if I wrote a poorly informed diatribe about how perl sucks so much because I can't use it for my medical imaging needs*, would it be equally valid? Why is it so awful when people spout FUD and nonsense about perl but it's fine when it's about other languages?</rant>

  What's funny is I wind up saying the same thing to Java people about Perl :-)

  (*It could be great for my hypothetical medical imaging needs, but that's beside the point.)
  • Re:yeah, that's fair (Score:2)

    by Matts (1087) on 2003.02.27 2:46 (#17556) Journal

    I thought the article had some valid points. The startup performance issue is a bit of a red herring (i.e. so don't use it for command line scripts then), but it's still a pain in the ass and I don't see why it has to be that way. This is what the author didn't go into - why can't Java start up quickly? If so much effort has been spent in making Java run quickly, what on earth are they doing wrong at startup time?
    
    The whole CLASSPATH situation is a nightmare - much worse than (say) Perl's PERL5LIB system. The fact that you can't run a .class file directly is just dumb, even worse that you can't chmod +x it and run it that way.
    
    I agree with you that FUD is bad, but I didn't find this article all that fuddy (but yes, just a little).

    Reply to This

    Parent

    • Re:yeah, that's fair (Score:2)

      by lachoy (1663)

      I didn't think the whole thing was dumb:

      • Command-line programs should have better error messages. But that's a problem with the programer, not java.
      • Startup times are slower, but you generally don't use java for unixy pipeline stringalongs where this would make a big difference.
      • It would be nice if you could put all your JAR files in a directory and use the directory as the classpath rather than specifying each JAR file. But if this was really important I can just explode all the JAR files in a directo
      • Re:yeah, that's fair (Score:2)

        by djberg96 (2603)

        You have some valid points - he does judge Java harshly at times and perhaps he is comparing apples and oranges from time to time.

        One of the major drawbacks to using Java (gui apps) from a sysadmin perspective is something I think the author touched on - remote display. Have you ever tried running a Java GUI app remotely? It's a friggin' joke. It goes something like this:

        1. Start remote Java app
        2. Get coffee, chat a while with buddies about latest Buffy episode
        3. Return to desk and find Java app just now st
      • Re:yeah, that's fair (Score:2)

        by ziggy (25)

        A few nits:

        It would be nice if you could put all your JAR files in a directory and use the directory as the classpath rather than specifying each JAR file.

        Java is somewhat extensible in this respect: if you don't like the classloader, write your own. That's how JAR files got integrated into the platform around Java 1.2 or so.

        Not only does jar do more (compression, so he'd have to add a 'z' to his calculations for actual operation time, but tar + gzip will still be faster), they're built for entire
      • Re:yeah, that's fair (Score:2)

        by Matts (1087)

        The point I was trying to make is that while it's not sensible to write command line apps in Java, there's absolutely no technical reason for this, and no reason to accept it as the status quo.
        
        Java should be a nice general purpose programming language, but because of the startup overhead and crappy default error messages (stack trace!) it's not. It's limited to persistent environments or long running programs, which is a shame IMHO.