I came across this page while reading some posts from comp.unix.solaris. Pretty funny (unless you're the person using it I suppose).
It's from a sysadmin point of view, but still totally valid.
<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
Matts on 2003-02-27T07:46:08
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).Re:yeah, that's fair
lachoy on 2003-02-27T14:21:32
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 directory and use that.
- Running a class directly would be nice, but it's really not a big deal. If you're running someone else's program they're generally nice enough to bundle it up in a self-executing JAR for you. And most of the things I run are run through Ant or a shell wrapper anyway.
But....
- He's coming at this from a sysadmin perspective. Cross-platform isn't a big deal for him. It's huge for an application developer. The fact that our product can run on many platforms by default is fantastic. Despite his casual dismisal of this, it does work and works well.
- The straw man of faster programming coming at the expense of quality is just silly. Bringing in the people who think they can program in Java without knowing programming is wrong wrong wrong: do we point the finger at Perl when people practice cargo-cult programming?
- Comparing Java's speed using tar and jar is just dumb and tells me the author is picking a fight. 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 entirely different purposes -- tar is a general purpose archiving tool, jar is built for creating distributable Java libraries. In one sense, this is like comparing the performance of the pure-perl ptar to tar. Wow, it's slower, no kidding. And even worse, he confuses the speed issue by expanding the startup time to the millions of hits on a website. This is like saying Perl is slow because CGI startup times are slow.
- The whole "Sun won't eat its own dogfood" argument is stupid. The most recent outbreak of this was about a Solaris admin console where they had no need for cross-platform functionality and they already had an existing codebase. This is a damned-if-you-do/don't scenario for them: if they do rewrite it in Java, it won't be as complete (rewrites never are for a while) or fast (native GUIs are faster until you get up in hardware a little, altho I don't know how this plays on Solaris). If they don't rewrite it in Java, people say they're hypocrites for not using it everywhere. Oh well. (Plus this confuses Sun and Java: another red herring.)
- Finally, there's this attitude throughout that everyone using Java is just deluding themselves. Not only is it condescending, there are an awful lot of opensource Java hackers who'd strongly disagree with that.
Re:yeah, that's fair
djberg96 on 2003-02-27T14:50:10
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:
- Start remote Java app
- Get coffee, chat a while with buddies about latest Buffy episode
- Return to desk and find Java app just now starting up.
- Click "File/Save As" - correction, click "File", read a few journal entries
- Click "Save As" - respond to a few journal entries.
- Enter filename - slowly - you're typing faster than the characters appear - don't overload the buffer!
- Click "Save" - clean ears while no one is looking.
- Click "File/Exit" - oops, I meant click "File" - read latest posts to comp.lang.perl.misc.
- Click "Exit" - swear a few times. Send nasty email to Sun
Re:yeah, that's fair
ziggy on 2003-02-27T15:29:32
A few nits: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.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.Not quite. At the heart of it all, jar is just a java-based implementation of zip and unzip. JAR files aren't magical; they're just ZIP archives with a different suffix.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 entirely different purposes -- tar is a general purpose archiving tool, jar is built for creating distributable Java libraries.Re:yeah, that's fair
Matts on 2003-02-27T15:59:23
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.Re:yeah, that's fair
djberg96 on 2003-02-27T14:06:34
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?I think that analogy would only hold true if the company that manufactured the medical imaging equipment also wrote and owned Perl - then forced you to use Perl. I probably should have said "totally valid for solaris users" in my OP, though.
What we have in the case of Sun/Java/Solaris is a company that owns the platform and thus owns the sysadmin tools on that platform (the default ones anyway). So now they're replacing old, but quick and stable tools like admintool with slow, bloated (but pretty) Java programs like Sun Management Console.
One thing I got out of the article (reading between the lines a bit) is that Sun is so intent on promoting Java that they're forcing it on the rest of us instead of just improving the original tools. In my mind it's not much different than the MS/C#/Windows thing (well, except for that whole monopoly thing, but I digress).
Of course, I'm one of those weirdos who actually like CDE, so take my opinion with a grain of salt.
:-P Re:yeah, that's fair
lachoy on 2003-02-27T14:25:41
So now they're replacing old, but quick and stable tools like admintool with slow, bloated (but pretty) Java programs like Sun Management Console.
Well, that's just dumb.:-) Doesn't Sun have enough to worry about without rewriting major pieces of software their core constituency depends on? Not only is it violating the "don't fix it if it ain't broke" law, it's introducting change to sysadmins who IME tend to be a group who doesn't respond well to change. With good reason: change frequently comes at the expense of stability and predictability.
