Why is Java Considered Un-Cool?

jg21 writes "After the Slashdot discussion on Paul Graham's 'Great Hackers' essay, it had to happen. Java developers have taken umbrage at Graham's assertion that "Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero." Now in JDJ Sachin Hejip pinpoints the Top Reasons Why Java is Considered Un-Cool and to tries to debunk them. He levels some of the blame at the Java compiler for "too much chaperoning" and speculates that Java fails the geek test precisely because "it's such a language-for-the-masses." But isn't he missing the point? Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"

Comments

What is this responding to.. exactly?

[Defiler]

I'm not sure the article author has actually read the Paul Graham essay that he is responding to.
He almost entirely fails to discuss any of the attributes that Graham assigns to languages that 'Great Hackers' like to use.
In particular, Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.
I could go on, particularly since the Sun JVM isn't open source, and Graham makes a point of claiming that Great Hackers prefer to use open source tools. I think frantic defensive articles regarding Java aren't helping anyone. The managers that choose Java don't read Paul Graham articles, and I doubt Paul Graham much cares what a Java-oriented business journal has to say about his articles. Please note that I am just relating the opinions that Graham has put on his website. I do not necessarily share his views.

Re:What is this responding to.. exactly?

[skaffen42]

Yeah. Java really sucks and is uncool. No open source programmer would ever use it.

Hell, could you ever imagine an orginization like Apache producing Java code. If that ever happens I'm giving up and moving to Jakarta.

Re:What is this responding to.. exactly?

[LWATCDR]

I do not find java all that verbose. Terse or not the really key to getting real work done quickly is a large collection of libraries so you do not spend your life reinventing the wheel. Look at Perl it is not a pretty language but cpan makes it so useful that it has yet to be replaced by Python or Ruby.

Re:What is this responding to.. exactly?

[mwood]

"the managers that choose Java"

Hey, waitaminute, who let the *managers* choose?

"Fred, here's a saw. Go pound some nails in."

Re:What is this responding to.. exactly?

[jimfrost]

studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language

This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.

Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors:

1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.

2. Garbage collection eliminates whole classes of memory mismanagement problems.

3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality).

All three of these affect both time to deliver and quality of delivered code. We're not talking about minimal changes in productivity, either. I've been watching and working with Java and C++ since ... well, pretty much since they made it out of the laboratory. The improvement in real world productivity seen with Java is a factor of two to four greater on average versus C/C++ (measured by "how long does it take to get this feature to work", which is not necessarily the same as "how much code did I have to write"). Often lower for GUI work (depending on which GUI toolkit/tools you're using) but much higher for network code. Moreover, bug counts in released code are dramatically lower, like one tenth as many, and they tend to be less serious (a feature may fail, but seldom does the entire application fail).

In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.

Your mileage may vary, contents may have settled during shipping, etc.

Re:What is this responding to.. exactly?

[ArbitraryConstant]

meh

The Java API is so large that wheels often get reinvented because no one can bloody find the 19" wheel with a particular bolt pattern an the type of treads they want.

Re:What is this responding to.. exactly?

[Tim C]

Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

So, use a decent IDE, one that features code completion - type the first few characters of the name, hit ctrl-space (or whatever, as appropriate) and it completes the symbol for you. Meanwhile, having more descriptive names improves code readability (and thus maintainability).

Next argument agaisnt Java, please.

Re:What is this responding to.. exactly?

[LWATCDR]

That is an interesting idea. Too many choices? Better to spend the time hunting for a 19 wheel with the right bolt pattern than having a chunk of ore, a forge, and an anvil handed to you.

Re:What is this responding to.. exactly?

[mav[LAG]]

Paul Graham points out why this happens in another of his essays, Revenge of the Nerds.

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java.

Why does he think this? Let's take a look inside the brain of the pointy-haired boss. What he's thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won't get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.

Well, this doesn't sound that unreasonable. But it's all based on one unspoken assumption, and that assumption turns out to be false. The pointy-haired boss believes that all programming languages are pretty much equivalent. If that were true, he would be right on target. If languages are all equivalent, sure, use whatever language everyone else is using.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

Java is anything but terse.

I know there's been a gazillion comments, but there's one thing I don't see mentioned that I want to mention. Before I do, a brief note on my background: I learned BASIC in high school in the '70s, then Fortran and Vax 11/780 Assembler in college, then taught myself 6502 Assembler and programmed a lot on my Apple //e. For over a decade, I didn't touch anything to do with programming. Then I had a chance to put some programs together and start my own business. I had to learn languages that weren't even around when I had programmed before. I've had some formal classes in programming, but I'm mostly self-taught. I've had some coder friends tell me that I seem to automatically follow a lot of "good programming practices" that I was never taught.

I started with (and hated) Tcl. I found a book on Perl that was about 75% off, bought it, and was writing useful Perl code in under a day. When I had to learn Java, it took several books and was 2-3 weeks before I could write anything useful (in part due to needing to get used to the API before I could do anything I needed).

When I code in Java, I'm always reminded of the scene in Spaceballs where Col. Sanders keeps saying, "Prepare for..." and Dark Helmet interrupts and says, "Why do you have to prepare for everything?" In Perl, if I want to do something, I do it. It takes a line or two of code, and I'm done. In Java, to do something I have to prepare for it AND do it. I often have to create from 1 to 3 objects to finally get the object I need, then I can finally do what I wanted to do. For example (and please don't get picky -- I'm picking a simple, quick example and there are thousands of others), if I want a list of files in a directory, in Perl it's:

@file = glob($filename."/*");

In Java, I have to do:

File myFile = new File($filename);
String[] myList = myFile.list();

It's a small example, and I know I can combine creating the myFile object with getting the file list, but the point is I can't just DO it, I have to prep it and do it. I'm always going around my thumb to get to my elbow. In Java, I'm too busy keeping track of object types, creating objects (and sometimes creating objects, using that object to obtain another, then using the obtained ojbect in creating a third...) that I feel like a lot of my focus is on taking care of Java's needs rather than on writing my own program.

I like working in Java. I like the cross platform abilities. I like Swing, since it is (to me) an esay GUI to write for. I like the class structure. But I don't like writing in Java as much as Perl and, given a choice, I'll take Perl whenever possible. I've found I can put a program together in Perl in a day and it'll take 2-3 to write the same thing in Java.

Re:What is this responding to.. exactly?

[Tassach]

[N]one of the source forge crowd's top 3 languages are open source

Can I have some of what you're smoking? C and C++ are ANSI- and ISO-standard languages with multiple independent fully open-source toolchains. The Java language specification is still controlled by Sun, so it isn't an open standard; however, there ARE open-source implementations of that standard.

Re:What is this responding to.. exactly?

[Paradox]

The reason Java is considered 'uncool' in a majority of cases is a lot like the reason certain people are considered uncool in high school. It's mostly prejudice from people who are desperate to be accepted by their peers. Certainly some people have given Java a fair shake and decided they hate it, but the majority are just jumping on the bandwagon.

BS. Java is eclipsing Cobol now. Everyone has used it. If you've written code, you've probably at least written one small app in Java. Ubiquity is a double-edged sword.

Now, people hating Haskell might just be jumping ona a bandwagon. People who hate Lisp might be jumping on a bandwagon. People who hate Ruby might be jumping on a bandwagon. These languages are comparitively rare.

But Java? No.

Frankly I expect better from geeks. It's come to the point where I don't even listen anymore because every diatribe against Java is based on some small pet peeve or overly specific scenario. Everyone rehashes the same old arguments ad nauseam. Quit yer bitchin' and write some goddamn code and you might be useful for once.

How about this then? Java's type system sucks. It sucks, sucks, sucks. Java generics are only marginally fixing the problem. You cannot design your program up front. Heck, to refactor Java most programmers say you need tools. If your language is so intractable that it requires a tool to make refactoring reasonable, then you have a crappy language.

Java's primary GUI API, Swing, is not "brilliant." It's obtuse, lacks many features, and is unnecessarily slow.

Java's "Native Interface" (or FFI, "Foreign Function Interface") is hideous. It's difficult to get much of anything done at all. Ruby and Python provide much better models.

Are these complaints general and clear enough? Java is so riddled with flaws that it's amazing it's gotten this far. A living testament to the fact that marketing overcomes all.

Re:What is this responding to.. exactly?

[zipwow]

Col. Sanders keeps saying, "Prepare for..." and Dark Helmet interrupts and says, "Why do you have to prepare for everything?"

This is an interesting example, because I think in the real navy, there's a straightforward answer: Sometimes your preparation fails.

In the example you gave, there are *two* points of failure. The first is that you can't find the directory you pointed at, and the second is that you can't get a listing of it. Making those things be separate forces you to consider the failure cases.

A large part of what Java is about is failsafe enterprise-level applications. When you write to that level of safety, you need to identify the different causes of issues.

In the same way, your day-sailer on a 12' boat doesn't shout to his crewmate "Prepare to tack!" because there isn't any reason to. If you're sailing an 80' schooner, however, you do shout to your crew of six "prepare to tack!" And then you wait in case someone shouts back, "Port side winch is jammed!".

-Zipwow

Re:What is this responding to.. exactly?

[Jerf]

Ignore the other two replies to your post as of this writing; they fall into the trap of "countering the opponent at all costs", even if it isn't the best idea.

The real problem with your post is that nothing in it is specific to Java. A lot of other modern languages do those things without the other weaknesses of Java, like Python. The only difference is Python doesn't have checked exceptions but that's a good thing.

Like the Fine Article seems to be (I can't read it, server hosed), that's a fine defense of Java in general, but it only reinforces Paul's attack, IMHO, by listing the "good things" about Java that are in no way unique to it. Paul didn't compare Java to K&R C like you implicitly do, he compared it to Python. You're going to have to work a lot harder to defend Java against Python... in fact I don't think it can be done as I'm basically with Paul here, but if you want to try, that is the real challenge, not defending Java as "better than C". (What isn't? If it isn't better than C somehow, it's dead.)

(The only other major point to make that I am aware of is the so-called "benefits" of static typing, which are also dubious if you actually examine the issue instead of swallowing what the theorists have pounded into your head. Both of the links to Eckel are only samples, there's a lot more on both topics; "eckel " + "static typing" or "checked exceptions" will bring up a lot more in the Google hits below #1.)

Re:What is this responding to.. exactly?

[jimfrost]

The real problem with your post is that nothing in it is specific to Java.

Certainly not. There's nothing whatsoever new in Java, it inherited every single feature from somewhere else. That in no way makes Java less interesting, since it does a pretty good job of combining a lot of good features in one place -- and being popular enough that you can pretty much count on an implementation being available, too.

Regarding Paul's article, you might notice that I didn't take issue with any part of it other than the idea that the best hackers avoid Java. His clique presumably does, but it's plenty easy to find high power hacks who either are building or have built significant amounts of code using Java.

For that matter, it's been my experience that the best are relatively language agnostic -- writing code in e.g. C, C++, C#, Python, and even -- god help 'em -- Perl. Pick J. Random Hacker and ask 'em what languages they've made significant use of over their career and you'll almost always get a laundry list.

Whatever gets the job done, right? The relative "goodness" of the language has little to do with it, which is easily proven by looking at how much work gets done in C and C++.

Re:What is this responding to.. exactly?

[LittleDan]

That is a straw-man argument. Java isn't just more verbose than Perl; it's more verbose than just about everything short of Ada. Take the extremely simple example of a mutable record with 2 fields (we'll make them integers for this example). Here's how it might be done in Java:
class TheRecord {
private int first;
private int second;
public int getFirst() {
return first;
}
public int getSecond() {
return second;
}
public int setFirst(int value) {
first = value;
return value;
}
public int setSecond(int value) {
second = value;
return value;
}
}
In other languages, this would be much shorter than the 18 lines required to do that in Java. Take, for example, the scheme version:
(define-struct the-record (first second))
(it's not restricted to ints, but if you wanted it to be statically type-checked and you have bigloo, you can change it to (define-struct the-record (first::int second::int)), which is still much shorter.)
all of the getters and setters are automatically generated, and it was all only one line! Nevertheless, the Scheme version is perfectly readable provided you know what the define-struct macro does (for Java, you just as much have to know what the class keyword does, so...). What could be cooler than reducing 18 lines into a perfectly legible 1 line? I think instead of asking why Java is uncool, we should ask why Scheme is uncool.
Daniel Ehrenberg

Paul Graham?

[LimpGuppy]

Here's a hint: Paul Graham's view of the development world is fairly myopic.

Why is Java Considered Un-Cool?

[illtud]

...I'd love to tell you, but I'm trying to fix my $CLASSPATH

Re:Why is Java Considered Un-Cool?

[Frothy Walrus]

Try translating it into Hindi.

Re:Why is Java Considered Un-Cool?

[CountBrass]

1) Java in OSX (as an example) doesn't require a classpath at all.

2) Two problems with pointers: a) even "real" programmers make mistakes. b) in real, rather than one-developer toy, development who owns an object/lump of memory and therefore can/must delete it is an issue.

Re:Why is Java Considered Un-Cool?

[chez69]

3) leet programers love to bash java for lacking pointers but suffer segmentation faults when they fuck up a reference.

oh please. Most programmers can deal with pointers just fine, but like using a high level language to get more done.

Re:Why is Java Considered Un-Cool?

[mark_lybarger]

let me go verify my LD_LIBRARY_PATH has everything it needs before i get started.

Re:Why is Java Considered Un-Cool?

[Aardpig]

2) No pointers. Real programmers know how to use memory properly. That is all.

Real programmers also know how pointer aliasing can absolutely kill optimization. They therefore avoid pointers wherever possible, resorting instead to constructs such as Fortran 90/95/03's ALLOCATABLE(:) arrays.

Re:Why is Java Considered Un-Cool?

[das_cookie]

CLASSPATH for sure, but how about the lack of upward compatibility of the various runtimes? Who hasn't had to install yet another jre because this app doesn't quite work right with the latest runtime. Take a look at Oracle for an example. Long after java 1.4 was out, Oracle 8i STILL required 1.2. I think the latest Oracle (10g) runs 1.4.

Hey, I *like* java, but this kind of crap is definitely shooting yourself in the foot material.

Re:Why is Java Considered Un-Cool?

[BeBoxer]

Bingo. That's why I hate it. The whole "platform independence" is pretty much a load of crap in Java. Yes, in theory, it's there. In practice, all of the real Java apps I end up having to deal with require some specific runtime. Then I fight with CLASSPATH stuff.

I understand that truly cross-platform programs are a difficult problem. But that doesn't change the fact that Java is pretty bad at it. And don't even get me started on the fact it has multiple GUI API's.

Re:Why is Java Considered Un-Cool?

[mwood]

"I'm trying to fix my $CLASSPATH"

There's something to think about. Java does need some things to make the app.s a little less fragile.

Every sizable app. needs a custom-built CLASSPATH long enough to climb to the moon. Java needs a *standard* place to drop stuff so that all the libraries are "just there". I've fallen into the no doubt disreputable habit of dropping .jars into jre/lib/ext, which is probably gonna bit me some day.

Java needs a *standard* place to put systemwide settings (and not Preferences, 'cos the standard classes don't use those). I'm tired of typing -DTHIS -DTHAT -DTOTHER -DKITCHENSINK.

Oddly enough, the Java environment seems to have been designed more for the lone hacker than for those who work in a shared environment and need shared libraries and defaults.

Re:Why is Java Considered Un-Cool?

[Aardpig]

You talk like pointer aliasing is something common within an application.

That's missing the point. If I have a C/C++ routine taking two pointer dummy arguments of the same type, then there is no way of guaranteeing that the pointers won't be aliased (i.e., point at the same object). Therefore, notwithstanding whether they are aliased in a given program which uses the routine, the optimizations that can be performed when compiling the routine are severely limited, in order to allow for the possibility that the arguments might be aliased.

Re:Why is Java Considered Un-Cool?

[daBass]

Real java apps are packaged in a Jar file with a manifest file that takes care of everything...

Re:Why is Java Considered Un-Cool?

[brianjcain]

The stupid $CLASSPATH. Since I don't do a lot of Java work, I don't actually set this stuff up in .profile or .cshrc or anything, but any time I want to try to compile

How is this any different from LD_LIBRARY_PATH or gcc -I/some/src/path?

No pointers. Real programmers know how to use memory properly. That is all.

That's total BS. Real programmers make mistakes. Real programmers benefit from the abstractions that C provides over assembly. When you write Java, do you find yourself wishing that you could address members by adding pointer offsets? Or do you long for the days when you could conditionally branch to a label instead of writing a for() loop? Pointers are a necessity for many computing environments, but I don't think that PC application software is one of them. You gain nothing, IMO, and risk everything.

Re:Why is Java Considered Un-Cool?

[jhunsake]

ONE used such a device

You don't use pointer aliasing, it's a concept. Pointer aliasing does occur quite commonly by the way, evidenced merely by the existance of memmove() and memcpy().

Here's pointer aliasing that most people wouldn't even recognize:

void swap (int* a, int* b)
{
int temp = *a;
*a = *b;
*b = temp;
}

int v[40];

swap(&v[20],&v[21]);

You make me worry

No, you make me worry. Especially after the HUNDEREDS of applications you've written. You can't even spell "hundreds" correctly for Christ's sake.

Re:Why is Java Considered Un-Cool?

[JamieF]

No, you just need apps that have a startup script (or double-clickable runner icon or whatever). If you're running "java -Dfoo -Dbar -Dbiz" you're doing it wrong, or your app supplier is lazy.

Dumping all your libraries in the JRE lib dir for autoloading is risky, unless you're careful to avoid duplicate libraries with different versions.

Java as a platform suffers from "jar hell" (kinda like "DLL hell") because there isn't a systemwide package management concept for Java itself. Most OSs at this point have a central package management scheme that includes manifests that say what dependencies exist as well as installers that know how to put the files in the right place. The Jar manifest file has entries for relative URLs of dependencies and a pacakage version number, but that's not really enough to build a package manager around. That stuff was really designed to solve applet requirements, not app requirements.

So, you take a risk when you upgrade a library to a version that didn't ship with the app you're using, because there's no declarative structure that tells you that the new library uses the same API as the old one, or which packages depend on the old one and thus need to be upgraded at the same time, etc. like you'd find with RPM, APT, etc.

It's better (where "better" is defined to mean "more stable", not "more efficient in terms of disk space usage") to just install the libraries you need multiple times - once per application. If you consider that disk space is cheap and sysadmin time is not cheap, it really doesn't make a lot of sense to obsess over pointing a bunch of Java apps on the same box at a shared copy of a .jar file.

A couple of things could fix this problem. One fix would be to have each OS package management organization start to "own" Java libraries along with native libraries. That's not very cross-platform, though. So maybe Sun should propose a new Jar manifest format that solves this? Or maybe it's in a JCP committee somewhere that I'm not aware of. :)

Re:Why is Java Considered Un-Cool?

[pjt33]

If your solution to avoiding using CLASSPATH is to put everything into the Java extensions folder then you should be claiming that CLASSPATH isn't needed on any platform, because they all have an extensions directory. It is, however, a crap solution. It doesn't allow you to switch between different versions of a library unless you want to keep replacing a symlink. Moreover, unless you do your development in /Library/Java/Extensions (which is _really_ crap) it forces you to cd to the directory into which you compile before running anything.

How about

[antifoidulus]

people just concentrate on the best tool for the job instead of worrying about things like, "coolness".
These, "my programming language is better than the rest and here is a list why" arguments are BS. Every situation is different, every problem requires different tools/methodologies to solve. You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you? You would be laughed at and possibly hit in the head with said hammer. Same goes with programming languages.

Re:How about

[black mariah]

It goes hand-in-hand with the social ineptness of the typical geek. An inability to fit in with the majority of society gives way to a need to fit in with SOMEONE, SOMEWHERE, and the tools one uses are the most apparent thing. This doesn't apply only to geeks though. Think about the old woman with fifty cats, or the obsessive housewife that fills every room in her house with frickin' Beanie Babies despite not having any (or perhaps BECAUSE she doesn't have any) kids. Same thing, different level.

Re:How about

[Takeel]

You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you?

Sure I would! You wouldn't want an inferior hammer working on your carpentry, would you? That could result in costly downtime.

Re:How about

[Bastian]

people recognize that using the best tool for the job every time isn't the way to do it, either. It's good to be comfortable with a lot of languages, but if you're constantly switching between FORTH, Perl, C, C++, Java, SmallTalk, VB, Ruby, Common Lisp, Python. . . you're never going to actually get good at anything.

There are cases where you want to choose the best tool for the job because some options are just terrible. There are also cases where you should stick with what you know. If I'm banging out a quick workflow integration app that needs a GUI on a Mac, AppleScript may be the 'best' language for the job, but it's also true that I don't work with AppleScript much and my level of expertise in it is low enough that I would probably get the job done faster and better if I did it in Objective-C despite its not being the best language for the task.

This "best tool for the job" analogy shouldn't be taken too far. Comparing hammers to programming languages is like comparing hammers to engineering contractors.

Re:How about

[Anonymous Coward]

I absolutely disagree.

The more languages you know, the better you are at choosing the right tool for the job - and the better you are at programming in any of those languages.

Sadly, the best (practical) tool for the job is often decided by secondary factors (availability for the required platform, availability of third-party libraries) rather than the nature of the language itself. However, the knowledge of multiple languages (especially fundamentally different languages) is always an advantage.

As an example - if you need to write your code in C, the knowledge of assembly language can help you figure out what's efficient, and the knowledge of functional and/or OO languages can help you design the right kind of abstractions for the task.

Seriously, once you know sufficiently many programming languages, writing code well in any language not entirely inappropriate for some task comes naturally. I'm saying this based on experience.

Sufficiently many means assembly language, at least one of (C, C++, Pascal, Ada, Modula*), at least one of (Lisp, Scheme, Python), at least one of (Standard ML, CAML, Caml Light, OCaml), at least one of (Haskell, Clean, Miranda), at least one of (Oz, Erlang, Concurrent ML), at least one of (Java, C++, Simula), at least one of (Smalltalk, BETA, JavaScript), at least one of (Perl, SNOBOL, Icon), at least one of (APL, K), at least one of (Forth, PostScript), at least one of (Lisp, Dylan, Scheme).

Each category could be expanded, since I was thinking of a particular paradigm/feature in each case, and admittedly there are a couple of categories that are not that critical (I'd say the string processing - Perl, SNOBOL, Icon - and stack based - Forth, PostScript - are the least relevant).

The thing is, anyone interested enough in programming to be a Really Good Programmer(tm), will want to learn and understand as many languages and paradigms as possible.

a few reasons

[becauseiamgod]

Firstly, most applications written in java run awfully slow which sends a lot of people to other languages. Secondly, virtual machines running byte code creates an extra step in compiling/rolling out programs which can stray away a lot of beginners. In general, not a lot of production software is written in Java, and a lot of people get into programming because they want to emulate something that already exists and make it better. C/C++ are languages of choice of the industry so they tend to go into them.

Also, i remember someone saying, saying java is good because it works on more platforms is like saying anal sex is good because it works on both sexes :-P

Re:a few reasons

[lmsig]

In my career I've written more C then anything else. Followed by PERL for test automation. Recently I'm working a new program that is 100% Java. It has been a pleasure. I do not see any huge performance problems that people seem to complain about. I'm not just writing a database/forms program either but doing REAL work in image processing.

I have no idea what you mean about byte code making it harder. You compile things into a JAR, in most OS's you can double click the JAR and run it. How is that difficult?

Tons of production software is written in Java. Especially server side.

C/C++ are out there but the reality is that they are too hard to use for very large project. It can and will be done successfully but it costs a fortune. I can do so much more using Java with so much less budget that its amazing.

As far as being multiplatform. It comes close. I've never had any huge problems outside of cosmetic differences that might need to be tweaked, but that it easy. I was even doing 3d graphics on the mac and demoing them blindly on a windows PC without testing on Windows (I refuse to own one of those) and had no problems.

Re:a few reasons

[Everleet]

They're still trying to debug each other's code, in preparation for a rollout that will never come.

Re:a few reasons

[drago]

For an interpreted language java is damned fast, that's right. Especially due to JIT there is almost no difference between C++ and Java regarding speed any more.

The only thing still awfully slow is Swing GUI and all efforts in making that faster result in making it less portable. I remember an article linked from slashdot some weeks ago, where the author promised fast and platform independent Java GUIs, which turned out to be JNI bindings for GTK+ ... not really what you want on one of the stranger platforms.

The one real problem I see with java is the high amount of memory it needs which is no problem on PC hardware, but can be much of a problem on embedded devices where due to the huge quantity of sold units every cent you spend on memory can cost thousands of US$. Even JavaME still consumes more memory than an app written in C.

Having said so much in favor of Java I must still say that I personally do not like it, and that's not because of having less experience with it.

I'd use it

[immakiku]

I'd use Java for whenever I have a project that's a little bit higher than simple but doesn't require high performance. To me, it's very useful in the right situations.

Its just a tool

[hoofie]

Java is a tool - just like every other programming language.

People do/don't use Java for many reasons - the choice of a programming language in a commercial environment depends on many different factors.

I work in Java - I can't say it excites me but it does the job.

Re:Its just a tool

[Lodragandraoidh]

We have replaced several Java apps at my job with Perl. It runs faster, uses less resources, and is simple to modify (no compilation needed).

Most web based apps I build now are either Perl CGI or Python Zope - and I am leaning more and more toward Python as the language of choice for large applications.

I don't think the problem is so much the language itself, or its implementation as much as the lack of understanding of developers in the IT shop to use Java as a matter of course - rather than a logical selection.

As stated elsewhere, using the right tool for the job should be developers number one skill. With the emergence of 4GLs and web development and presentation frameworks, coupled with the increase in computer and network speed capacity, there is little impetus to waste time offloading CPU cycles to the user's computer (via Java applets). To add a final straw to the Camel's back, the emergence of the CSS, and script standards as deployed in modern browsers and leveraged in modern development frameworks, provides more lightweight (and thus faster) options, particularly in concert with backend server processing.

Finally, all of the applications I build anymore are strictly web based - which puts a premium on efficiency - difficult to achieve using Java.

Re:Its just a tool

[Anonymous Coward]

This is just messed up.

Are you talking about replacing Java applets with Perl scripts? What? And who does serious web development with Perl CGI!? I'm a full-time perl programmer and won't touch CGI. CGI.pm, sure, but not unless it's under mod_perl.

And Java not good for web-based applications? Have you not even considered the enormous rise of Java as a popular back-end server language purely for large-scale websites? And hey, in some cases Java's regexps are faster than Perl's!

I love perl. I make money writing perl. I teach people perl. But I also know Java (mostly from college) and can tell you don't know what you're talking about.

Re:Its just a tool

[Hulfs]

If I do X with Java and I similarly do X with Perl/CGI or Python/Zope - and the result is faster using the 4GLs - then it seems clear to me that the best approach is to not use Java. A process is a process - regardless of whether it runs on the server or the client. What differentiates them, then, must be performance.

Actually, your parent poster was precisely correct. You're trying to compare completely seperate entities. Applets were meant to be a way to deploy thick client applications to end-users as opposed to your perl scripts which are completely server/thin client based deployments.

If you truly want a closer apples to apples comparison you really should check into using jsps. On any decent application server a jsp deployment will outperform cgi based perl script (I can't speak for a mod_perl based deployment). I'm not trying to bash perl here, I love it. I'm just pointing out your error in comparison of applets (which are all but dead -- replaced with java webstart [.jnlp files]) to server side perl scripting.

Re:Its just a tool

[Anonymous Coward]

Have you heard of Servlets/JSPs at all?

Have you actually tried integrating with not just one RDBMS but multiple RDBMSs (Oracle, DB2,etc.) and going to the mainframe and tons of other Unix boxes (Linux, Solaris and AIX) all at the same time to aggregate data and present it into one coherent interface either using WAP or HTML based on the web request? That's the kind of issues enterprise developers deal with. Enterprise application development involves much more than just hacking together app in a a few hours or week.

Re:Its just a tool

[Lodragandraoidh]

Python/Zope will allow me to interface with multiple RDBMSs easily. The key is to use the tool that best fits the job. One size does not fit all. There is room for Java solutions; however, I have seen no pressing need to change from the perl/python I am using now for those server-side solutions.

Enterprise application development involves much more than just hacking together app in a a few hours...

My job is to make my customers (be they internal or external) happy. If that means hacking together something in a few hours - then I am going to do it. I am going to use every tool in my arsenal to deliver the solution when (before if possible) they need it - and then factor out any bottlenecks not anticipated (something you will still have to do regardless of what environment you use).

This goes to the core of the difference between classic 'waterfall' development techniques, and more progressive agile software development. The focus in classic design is to have everything defined up front and is reflected in the tools chosen for particular jobs. In reality, unless the application is trivial, this is not attainable in practice. Given that - I can't see any convincing argument that will bring me to embrace Java (on the server or client side).

I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects. I have seen enough projects go massively over budget and fail to deliver the promised functionality to know that classic 'authorities' do not trump results.

Wait

[Lord Grey]

The title of the article is "Top Reasons Why People Think Java Un-Cool - Debunked" (emphasis mine). I did RTFA, and I saw no debunking. Just a list of reasons why people might not like Java.

This is news?

COBOL

[sql*kitten]

Java is the new COBOL. No, I mean that quite seriously. COBOL means "COmmon Business Oriented Language". Java is the language of choice for modern day corporate application development. In the corporate world - which probably accounts for more actual lines of code than anything else - applications fall into two categories, forms (inputting data into databases) and reports (getting data out of databases). The corporate world wants legions of cheap, interchangeable programmers to work on these applications. Kids are taught Java at college or learn it themselves. The language makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go. That's the reason "hackers" don't like Java - they've just transferred their traditional dislike of COBOL to it.

Re:COBOL

[Marlor]

Java is the new COBOL. No, I mean that quite seriously.

Well, considering what COBOL programmers are earning these days, Java might be a valuable skill in the future.

Re:COBOL

[TopShelf]

I read articles like this and just get depressed. I actually long for the days when I worked on COBOL! The last couple years I've had to work with RPG *sob*. For many companies, it's not about the latest & greatest, but rather the cheapest that still gets the job done...

Re:COBOL

[RetroGeek]

COBOL was developed the way it was to allow managers to look at the code and have some reasonable chance at understanding what it does.

Which is why you have "sentences" and "paragraphs" and why COBOL is so damned wordy.

It is supposed to read like English. And if you go to some trouble with the naming of your variables you can almost make it like that.

Perl is the opposite of COBOL. Succinct to the point of incomprehensibility.

Re:COBOL

[Epistax]

I agree entirely. Java is slightly akin to Visual Basic, just with more control and (obviously) wider compatibility. If you want an interfacing program, especially one with a GUI, more traditional approaches (C, C++) fall flat due to coding overhead. In Java this is traded for execution overhead, which largely doesn't matter given the speed of modern CPUs (although I hate to say it) and the fact that a user interface doesn't have to be any faster than the person using it.

Last summer I worked for Rutgers University in the genetics department. One person had a piece of software someone else had developed in java, which interpreted the results of a machine output. Without understanding the output, or how the program worked, or anything about biology what so ever, less than a day's time I was able to implement changes that a graduate student wanted to assist in his operations, namely, enhancing the GUI with some specific features. If it had been written in C/++, it certainly would have taken me much longer (although I don't have any sort of proof, what I can say is Java is easy).

Re:COBOL

[dinog]

Assembly language is considered "cool", and yet talk about baby steps ! Indeed, CS as a whole is mostly finding the simplicity in a seemingly complex task. For large tasks, there is nothing wrong with stepping through a task in a simple, logical, and above all maintainable manner.

We need to require new academic standards for programmers. First, CS majors need to have at least one class where they are required to debug, maintain, update, and add new features to someone else's uncommented 10000 line perl program. The second part of the course would be writing a new program. Students have the choice of commenting or not. If the student turns in a well organized and commented program, they will be given a well organized an commented program to debug and modify on the final. If they turn in an uncommented and/or poorly organized program, they will be given such a program (but not their own) to debug and modify on the final. (Yes, I do maintain code for a living, why do you ask ?)

That said, why don't you like Java ? It has the obtuseness of C, the verbosity of COBOL, and even more compiler restrictions than Pascal. What else could you ask for ?

Dean G.

Re:COBOL

[animaal]

Everything is broken into "baby steps" because at each of those steps, there are a number of ways to accomplish the next step, achieving a different level of efficiency, error handling, thread synchronisation, etc.

Think of reading from a file. A less verbose language (like C) would just say something like int h = fopen("myfile", "r")

Java might say something like :

BufferedReader r = new BufferedReader(new FileInputStream("myfile"));

Definitely longer. But probably less than the equivalent code in C if the C programmer had to do the same buffering of input from the file.

Java code in general is easier to maintain, since it's easier to read. Not a big issue for leet programmers, but a big issue for their employers who have to find somebody to maintain the code after they've jumped to another employer.

The java code also won't puke up a GPF if there's a runtime problem.

Too verbose

[random_culchie]

Some of the things in java are terribly verbose. especially when going to design GUIs.
Using the language you just "feel" as if there should be an easier way.
I'm no fan of microsofts products but I think C# is an excellent language to program in. It addresses alot of Java's shortcomings and it is a joy to program in.

Re:Too verbose

[MarkoNo5]

Requiring the keyword 'virtual' to be added to almost every method is not verbose ? I think my definition of verbose is out-of-date then.

Re:Too verbose

[CynicTheHedgehog]

I agree. I especially love the concept of "properties", which address the concept of getters and setters without the need for naming conventions. I also like the foreach( ) loop syntax, and the way Collections are handled.

But with Java you'll find that things are more verbose because they are more extensible that way. There are tons of places where the object model can be optimized to suit your needs at the moment, but they are they way they are for a reason. A good example is the JavaMail API. It's a pain in the butt to add attachments to E-mail (because the MIME stuff is so complicated), but I've used the JavaMail API to parse multipart-encoded form elements to write a file upload Servlet. It wasn't the intended purpose for JavaMail, but the MIME stuff was so well-written and abstracted that I could easily apply it to another (unrelated) MIME application.

I think probably the real problem is that some people prefer procedural languages (C, badly-written C++, Perl, etc.) than object-oriented languages. If you're one of those people, you're not going to like Java or the Java APIs. Java takes OOP to the extreme.

And with Java 1.5 (Java5) you get generics, enumerations, and that new funky for loop, which should make Java slightly less verbose while making it more robust.

Also Speed

[mfh]

> Java is anything but terse.

I had to use Java back in school and I won't touch it unless my superiors threaten the branding iron (again). Java loads too much overhead and it doesn't have the same responsiveness as C based apps, IMHO. I don't think Java is optimized enough, and it shows. All the cross-platform support comes at a price and that price is speed.

Re:Also Speed

[Ignorant Aardvark]

I had to use Java back in school and I won't touch it unless my superiors threaten the branding iron (again). Java loads too much overhead and it doesn't have the same responsiveness as C based apps, IMHO. I don't think Java is optimized enough, and it shows. All the cross-platform support comes at a price and that price is speed.

Java is optimized ... for security. Java has all sorts of neat features built in like automatic bounds checking on arrays that simply don't exist in languages like C. This means that it may run slower, but in a computing environment where processor speed doubles every 18 months, would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm? Programming in C leaves you wide open to buffer overflows and other attacks, and it takes a security-oriented programmer to overcome those problems. And guess what, once you get all of the code in there necessary to make it secure, it runs at about the same speed as Java. Java just puts all of the security stuff in by default, which I don't think is a bad decision in this age of computer worms and viruses.

Re:Also Speed

[Stephen Williams]

in a computing environment where processor speed doubles every 18 months, would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm?

"They who would trade essential CPU cycles to gain a little temporary security deserve neither CPU cycles nor security."
-- B3nj4m1n Fr4nx0rlin

Hmmm, it seemed considerably funnier in my head...

-Stephen

Re:Also Speed

[putaro]

Nonsense. You can provide a nice, safe, memory access with the right native classes or by modifying the JVM appropriately. Sun turned out a Java OS back in 1998.

Re:Also Speed

[Gr8Apes]

I think it really depends on what you're programming for. For user applications, especially small ones, it doesn't really make sense to program in java unless portability is your overriding concern. For business applications, especially server applications, java makes much more sense precisely because of the security features inherent to the language, not to mention the maintainability of the code, provided that programmers with half an ounce of knowledge are working on it.

If Paul thinks lots of "great" programmers work for MS (they code in C, hence they must be "better" than java coders) I'd like to know how he explains the never ending list of bugs, many of them security bugs/buffer overflows that seem to permeate the entire set of MS code?

That aside, yes, a great programmer will be able to code something fast in the terse language of choice. That same code will most likely be unmaintainable when the poor maintenance guy comes along to attempt to track down the buffer overflow or whatever other error has cropped up in said code.

And just because you use a language like Java doesn't mean your code has to be verbose. You can approach C's terseness with Java, although you cannot utilize some of the pointer variable morphing attainable by C. But you certainly can approach C or Perl's unmaintainability with ease with Java, all it takes is 1 or 2 people that don't understand the language, architecture, nor OO. (Think 14K line "classes" here with 20 or so methods, 5 "inner" classes, and lots of circular dependencies)

Re:Also Speed

[the quick brown fox]

I've been using .NET for the last 18 months and Java for the last four years, and they seem about the same speed and take about the same footprint.

Re:Also Speed

[Tassach]

I agree. Java is not a language for systems programming. The question is, what percentage of programming tasks entail low-level systems programming versus high-level applications programming?

The VAST majority of software being written is high-level business applications; hence there are at least an order of magnitude more JOBS available for application programmers than systems programmers. For virtually all business apps, programmer productivity, code maintainability, and predictable scalability are FAR more important than raw execution speed. This is where Java puts C++ to shame.

Not responding

[gr8_phk]

The site must use a lot of Java code.

The Horror!!!

[Meostro]

Does it bother anyone else that this page has 65 ads on it? It frickin' hurts to read, it's almost as bad as http://www.seizurerobots.com/!

Also it bugs me that this guy has to rant and rave about Java, but he can only come up with eight "uncool reasons" to debunk. C'mon man, the standard Top Ten list has TEN items.

What's not to love about Java?

[wayward_son]

It's got the simplicity of C++.
The freedom from corporate interference of Visual Basic.
The speed of an interpreted language.

And you wouldn't believe how efficiently it uses RAM and CPU power.

I don't see why everyone doesn't use Java!

Re:Maybe because it's slow ?

[Anonymous Coward]

Java is slow when you are starting something up and the Java vm isn't started. When the vm is started, Java is outright fast. Many people fail to realize this is what's going on, but it's simply the way it works. The first time it's going to be very slow, every time after (until the vm is killed) it will be comparable to a C/C++ application in speed. When you're developing enterprise applications, that first time slowness doesn't outweigh the benefits of using Java.

This isn't to say Java is perfect for everything, but it is for some things.

Who cares?

[Anonymous Coward]

Who cares if it's cool or not? From my point of view, it pays the bills.

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

So everyone wins. "Cool" stopped being important when I turned 18.

Re:Who cares?

[pHDNgell]

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

What are these languages? There really aren't that many languages that require manual memory management, or use header files, or have pointers, etc...

You've basically said it's more productive than most other C based languages. Well, yeah.

I'm far more productive in python or ocaml. They're both higher level. Python has more APIs available, but ocaml is safer, faster, and more expressive.

Even in java (which the majority of my job requires), I will often implement classes in jython and then port them to java for deployment (which makes them much, much larger).

Paul Graham isn't Cool, Duh.

[freality]

See how easy it is to assert that something isn't cool?

When I read Graham's article, I was disappointed. It had that air of someone being passed by, by a lot of fun. Saying Java isn't cool is like saying Scheme or ML isn't cool. It's just a personal preference, and when you express it, you run the risk of sounding anal and/or ignorant. His older articles were better considered.

Here's my utterly ignorant statement of the day: No matter how many ultra-cool hackers I know tell me that Lisp and Scheme and ML are cool, I never have fun using them. They force my brain into such an unpleasant state of nerdliness that the only thing I can program in them is a mathematical proof or some sort of logical system.. in short, I'm forced to become a boring CS professor using them.

Don't bother debunking reasons why Java isn't cool. The only path to cool is the acceptance of luserdom. Only when you have nothing to lose will you dare to do something audacious.

Look at punks. The only time they're cool is when most of society considers them fringe lunatics with no social graces. And then the rock happens again. It's when they're "cool" that the music invevitably begins to suck.

Being called uncool is a blessing in disguise. Thanks Paul.

Re:Paul Graham isn't Cool, Duh.

[awol]

No matter how many ultra-cool hackers I know tell me that Lisp and Scheme and ML are cool, I never have fun using them. They force my brain into such an unpleasant state of nerdliness that the only thing I can program in them is a mathematical proof or some sort of logical system.

Er, that is every single computer program you have ever written. First let me disclaim that I make my living writing in C (a little C++ and some interpreted languages). But I firmly believe that until we approach every program as the "proof of a logical system" we will be burdened by the inexorable piles of poo that is the vast majority of the software written today.

Functional programming is the way forward. I don't mean this as a personal criticism of the parent poster, just a general comment. The fact that they (most programmers) cannot see that every program they have ever written is a logical system is an indictment of how most people get into the industry. Code is just applied mathematics and most coders do not have the mathematics to apply. The sooner we fix this the better the quality of the programs we write will become.

Re:Paul Graham isn't Cool, Duh.

[Fnkmaster]

Well, you hit on an interesting point, but I think your expectations are unrealistic. Humans just don't do a good job thinking in that way. There are a very few people who do, and they are mathematicians - and it even takes them a long time to write successful, logically complete proofs.

You could take the approach that every piece of software you write has to have that level of detail and accuracy, proof-like precision if you will. I think you'd find that your productivity would be far lower in terms of logical constructs completed per unit time. This is probably an acceptable trade-off if you write control systems for nuclear power plants or if you work for NASA where budget and time-frame are vastly greater than for your average business programming problem.

But for most applications, there is not only a set of requirements, things it needs to do, but a very short period of time to make it do them in. And if you go to the boss and tell him it's going to take 14 months and cost 1.3 million dollars because everything has to be written as a logical proof, he's just going to fire your ass and get a team of third-world guys to puke it out in Java in 3 months.

I'd love to be proven wrong here - if you can show me a study that indicates that use of ML or some other language type results in substantially more bug-free code _without_ sacrificing development speed, then by all means, I'll admit that I'm wrong. My own personal experience is limited to small apps I've written in OCaml, which were cool and everything, but OCaml isn't purely functional, and I found several aspects of its use quite painful, despite feeling very "elite" as I hacked away in a semi-functional language.

Most particularly, the idea of not specifying an explicit contract between chunks of a system with the types of information passed between them really irks me - to me this makes a development language unusable by more than one person, or even by one person in a sizeable programming project. I constantly refer back to other chunks of my code to see what type of data I need to feed to some function or method - and when using somebody else's code I'm far more likely to be interested in the interface than the implementation. Without that kind of separation, I don't see how this stuff is usable (I can't "keep the whole proof" in my mind at one time when I'm doing mathematics either, that's why you have lemmas and theorems and other mini-proofs that you call out to).

Maybe somebody can point me to a more usable version of a functional language that doesn't "feature" static typing, or that was designed with real programming tasks in mind and thus would be worthy of more study re: the development speed and team usability characteristics I mentioned above?

Re:Paul Graham isn't Cool, Duh.

[mmusson]

I could not agree more with your post. There was another quote that went something along the lines of: a cool language is one that teaches you something by learning it. I thought learning and using Haskell and Lisp were very useful for a different and complementary mindset that they help create. I think my C++ programs are higher quality because of my functional programming experience.

Languages like Java or Basic are not cool for me personally because they did not teach me anything. These languages are primarily designed to protect the computer from the programmer. I think the proliferation of buggy programs is due to languages like Java or Basic that make it easy for a person without the proper training to program. Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?

Re:Paul Graham isn't Cool, Duh.

[RAMMS EIN]

Wow. Someone here who cares more about the theory than the application. I'm impressed. Explain one thing to me, though: what does it mean to approach a program like a logical (or mathematical, if you prefer) proof?

I mean, if I want to write a server that reads messages from each client and then relays them to every other client, I would just write a program that does that. I don't think there is any mathematical or logical proof to be considered here. In fact, since the server doesn't terminate, I don't think it proves anything at all.

Of course, I am very inexperienced with logic and functional programming, so I might be missing something here. That said, functional programming is very elegant and efficient - though sadly it cannot do everything.

Re:Paul Graham isn't Cool, Duh.

[pkhuong]

Statefulness & update-in-place can be implemented using monads (Moggi) or linear objects (Girard's Linear Logic), which are mathematical objects with known and proven properties. I think monads are more easily adapted to regular programming (where copying & deleting is free), and so are usually used to implement state. Someone with better a theoretical grounding will hopefully reply :)

Re:Paul Graham isn't Cool, Duh.

[bugbear]

It's a bit misleading to say that I called Java uncool. I said in Revenge of the Nerds that hackers think Perl and Python and Ruby are cooler than Java, but I'm not claiming that that's how one should decide what language to use.

I dislike Java because (a) it lacks abstractions I need, (b) it is horribly verbose and bureaucratic, and (c) it is another Frankenstein in the C++ tradition of languages created by bolting features from dynamic languages onto a C substrate.

I'm often accused of being a language bigot because I violate the taboo against comparing one language to another. But if you think about it, anyone who works on language design *has* to do that, taboo or no. If you can't compare alternatives, how do you decide what direction to go in?

Java pays!!!

[KrisCowboy]

During the recruitment week in our university, one of the companies that visited was CA(Computer Associates). CA guys gave an options. The students can chose either one of C, C++ and Java for their exam. Well, 80% of the guys went for C, because it's their `first language'. Rest of them went for C++ and only 1 student out of 120+ students opted for Java. To cut a short story shorter, he got selected after a technical and HR interviews which were cakewalks compared to other guys' interviews. Well, if a language's gonna pay me 25,000 bucks(Indian Rupee) a month, I'd be more than happy to go for it. Cool or not.

Re:Java pays!!!

[mschaef]

To cut a short story shorter, he got selected after a technical and HR interviews which were cakewalks compared to other guys' interviews.

To be frank, it really concerns me when the interview process is a "cakewalk". It generally means that the interviewer is too lazy, thoughtless, or inexperienced to come up with challenging questions. If a company takes that attitude towards their most important fundamental activity (bringing in talent), it doesn't bode well for anything else they do. (Plus, I like working with people that can teach me things...) ObJava: I've seen some _tough_ Java interviews, so Java doesn't necessarily mean anything about the difficulty of the interview process.

Re:Java pays!!!

[DevolvingSpud]

Agreed. I work in the government contracting space in the Maryland/DC/Virginia area. Every contractor up here wants Java/J2EE right off because that's what the government is into. It gives them maintainable, cross-platform code that pretty much anyone can understand. Given the wide range in skill levels of personnel working on these projects and/or future versions of them, this is essential. Not necessarily *cool*, but certainly good use of taxpayer $$ over the long term, especially given the wildly heterogeneous server environment in the government (NT, XP, Linux, all 32 flavors of Un*x, AIX, Cray Solaris anyone?).

And in our area, it's much easier to say "what economic downturn?" especially if you know Java and have some kind of security clearance. Email me if you do, we're hiring :) The point is, here and now Java's popularity yields significant gains for those who can program in it.

Whether this is cool or not depends on the observer.

Uncool to me

[infinite9]

Want to know why it's uncool to me? This may be flaimbait, but it's the truth. A disproportionate number of Indians favor this language and environment. This makes it nearly impossible for me to take these contracts since it tends to drive down rates. Same thing for oracle related work.

Re:Uncool to me

[JavaLord]

They go where the work is. Plently of Indian workers programming in .NET and other languages. Your just not tendering for them.

or maybe it's because one of Sun's co-founders is an Indian, and favors Indian workers. This isn't speculation on my part, see Sun's co-founder says Sun favors Indian workers

The quote was:

"At Sun, people from India are favored over almost anybody else."

If Bill Gates said something like this about American workers, he would be called racist. God, I love the American media.

Re:lame

[forgotten_my_nick]

>Java GUI is slower than native alternatives

Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.

>Java is not supported by all platforms

You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old).

>All the Java "binaries" I've tried relies on me having installed a local interpreter.

Actually you can get a program which will create an EXE for you, but then that defeats the purpose of Java doesn't it? Everyone moans about having to download the JVM, why don't people moan about the VBRUNxxx.dll and MSFC that you have to install to get EXE apps to run sometimes.

> Hey, I said this is MY list. I dislike object oriented languages,

Your basis of dislikes is hardly a good argument for what is wrong with Java.

Well...

[thrill12]

..on the laptop I use for work (a Pentium-2 ...) it's just like that. Don't understand me wrong: I have programmed in JAVA, I liked it.
But as corporations nowadays still have little budget left for buying their employees decent PC's, JAVA still has this practical limitation.

Re:Well...

[DrJonesAC2]

Agreed, I'm currently developing an RPG in Java (It's for school). I am doing it on an old IBM thinkpad 600e. It does have some slowness but nothing killing playability. On more modern systems the game FLIES!. I am in no way a pro Java developer so I know my code could be optimized quite a bit. Anyway my point is that I find Java can do anything that C/C++ can do and I have a very easy API to work with.

Re:Well...

[Rattencremesuppe]

Anyway my point is that I find Java can do anything that C/C++ can do

you never did device drivers or realtime systems, did you?

Re:Well...

[black mariah]

If you're doing device drivers in an interpreted language, you're a fucking moron. Conversely, if you program a web-based app in C, you're a fucking moron. Wow, different tools for different jobs... who'd have though?

Re:Well...

[AKAImBatman]

Oh, go jump off a (virtual) cliff. Java can handle "soft" realtime just fine, and extensions are being worked on for "hard" realtime support. And yes, some people actually write device drivers in Java. Java isn't slow because it's actually slow, it slow because:

1. C programmers write 10 lines of REALLY LOUSY Java code and decide that proves their point about Java being slow.

2. People like you WANT it to be slow. I'm sorry, comparing Java programming against device driver writing? That's the height of hypocrisy. Just because you're sore that *you* can't write high performance Java code while maintaining the beauty of an OO design, doesn't mean you have to take it out on everyone else.

BTW:

4k games
Amazing OpenGL game
More Java games
JDiskReport
Best BitTorrent client ever

etc, etc, etc.

Re:Well...

[AKAImBatman]

FYI, Java is Just In Time compiled, not interpreted. Otherwise, I agree completely.

Re:Well...

[struppi]

Exactly what has to be said about java. At the moment I'm working for a company where I have to write C++ code (since the data we handle is simply too large... our C++ apps use up to 2GB of ram), and it's a lot harder to write clean, secure OO code than with java.

So: if you can efford 256 MB of RAM and a recent CPU Java will run most of the applications fast enough. I know java has a long startup time compared to C or C++ applications (long as in 4 seconds compared to 1 sec), but this is a time I can wait.

Re:Well...

[AKAImBatman]

It's interesting that people are working on this. But you wouldn't use that in production systems, would you?

20 years ago, you wouldn't have used a C based Unix machine in place of a Mainframe, now would you? Back then, OSes were written in "safe" languages like ALGOL, FORTRAN, and LISP.

Because you can't do the low level stuff in Java.

You can, and you can't. Generally, you can't do it in Java because the API has been designed to prevent it. This is INTENTIONAL for security reasons. You wouldn't want an ActiveX control to install itself as a device driver, would you? But it *can* be done in Java as long as you have an appropriate API toolkit. JNode has one, and Sun actually provides such a kit for all the embedded Java development going on.

I never wrote about the slowness thing, I just didn't like the "you can do anything in Java" statement made by the parent poster.

I apologize if I misinterpreted, but your post did make it sound like you were referring to Java having too poor of performance to act as a platform for things like Device Drivers.

Re:Well...

[Kiryat Malachi]

Java is being worked on to deliver stable guaranteed time to interrupt? That being the chief characteristic making a "hard" realtime system useful.

I'll believe that when I see it.

Re:Well...

[AKAImBatman]

Java is being worked on to deliver stable guaranteed time to interrupt?

Exactly. It was the first JSR created as part of the Java Community Process. The final API can be viewed on the JCP website. The "reference implementation" being used for testing can be found here.

Keep in mind that the API is most likely to show up on hard real time systems and probably won't be available on your standard desktop OSes. (Windows? Hard realtime? *rolls eyes*)

Re:Well...

[the quick brown fox]

Are you purposely ignoring all the other benchmarks? For example, the one immediately preceding the one you cited.

In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.

Re:Well...

[freedom_india]

Actually you can write device drivers in Java if your processor is a Java Virtual Machine hardware implementation.

Java is NOT just a language but a VM also. Most people forget that.

Re:Well...

[AKAImBatman]

You sir, are an idiot. I'm downright amazed at the chutzpah you display in posting this. You are comparing a Virtual Machine platform designed to optimize large and long running programs, against simple scripting languages? With a Hello World program no less!

Allow me to repeat: You sir, are an idiot.

Now go back to school for Comp-Sci, and learn about the tradeoffs programmers must make in order to make things "fast", "small", or "abstract". Hint: It's a lot like Physics. You don't get something for nothing.

Oh, and I love your web page. A "Windows Perl Hacker" you say? Lord save me.

Re:Well...

[nickos]

Conversely, if you program a web-based app in C, you're a fucking moron.

Please break it gently to Google!

Re:Well...

[AKAImBatman]

Yeah, let's write task schedulers in LISP! ROFL

I don't know why you find that funny. That's exactly what Symbolics did. They beat Unix to the "Workstation" market by several years, too. Many Unix Haters were very upset when their LISP machines were replaced with Unix:

This is the fifth day I've used a Sun. Coincidentally, it's also the fifth time my Emacs has given up the ghost. So I think I'm getting a feel for what's good about Suns.

One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven't already. It's inspiring to those of us whose LispMs take all morning to boot.

Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there's a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it's fast!

Besides, it's not like a task scheduler is a hard piece of code to write. It's actually stupidly simple to write. The hard part is creating an algorithm that will most effectively extend CPU resources to running programs. What is effective depends on the purpose of the OS. See "The Dining Philosophers Problem" for an example of the issues that task schedulers must resolve.

AFAIK, its not the API but the language features (VM and garbage collector) that don't allow deterministic behavior.

1. VMs by their very nature are deterministic. If they weren't, your CPU wouldn't be either.

2. Garbage Collection is as deterministic as the algorithm behind it. Standard "mark and sweep" algos are indeed deterministic.

None of this has anything to do with compiled Java code, which runs in as deterministic a fashion as you code it. Do you even know what "deterministic" means?

I'm not saying that C/C++ are better languages but you don't have these problems there.

Yes you do. Any problem you code, you have in any language you code it. If you choose to write a device driver with a random timeout inserted, you must take responsibility for that behavior, no matter what the language. If you require that your device driver have an uninterrupted time slice of X milliseconds, then you must use the OS services available to ensure that you have a time slice of X milliseconds.

It's not a question of performance, but deterministic behavior and guaranteed maximum latency.

Maximum latency is not a determinable factor in ANY language, save for when real-time services are utilized. If you utilize real-time services, then it doesn't matter what language you use as long as you have access to those real-time services.

Re:Well...

[AKAImBatman]

You need to access an area of physical memory. JAVA has no pointers.. what do you suggest? (this is a memory mapped device so yeah, to write a driver for it, I do need to access its physical address space)

You use the APIs provided for Device Driver writing. Java allows you to access memory mapped areas (see the java.nio package). All that's needed is an API to obtain that area. Since you normally don't want to give that functionality to developers, it would have to be part of a Device Driver API like Sun's JDDK or JNode's OS services.

Re:Well...

[AKAImBatman]

-1 Troll? It seems that someone around here doesn't like hearing how computers ACTUALLY WORK. *shakes head*

Re:Well...

[AKAImBatman]

This was extended in C++ to allow non-scalar comparisons so now one can write equality operators to do what ever one wants for a given pair of objects.

Which does the EXACT SAME THING as the Java function. The only difference is that C++ allows operator overloading while Java does not. Given the number of bone-headed ways operator overloading has been abused, I'm inclined to agree with Java's way of handling things.

So in C for instance the equality operator would promote 3 == 3.00 to 3.00 = 3.00. This is a convince.

Which is different from what you said. The original poster claimed that 3 and 3.00 are not equal. He was correct in his statement. You then called him a liar. Now you're doing an about face. Seems you owe the original poster an apology.

Dweeb.

Standing tall and proud. :-)

Re:Well...

[Theatetus]

Logically 3 does equal 3.00. In any reasonable language if one compares the two with a simple equality operator it will return true.

Umm, depends on what you consider a "reasonable" language.

C says 3 == 3.0
Lisp says (= 3 3.0) but not (eq 3 3.0)
Forth will just compare the most-significant word of 3.0 to 3, though you have to bend over backwords to get a floating point number on the data stack to begin with
The ML family will throw a type error
Scripting languages will for the most part either promote 3 or demote 3.0

I think there's a lot of variety in what a "reasonable" language will do in such a situation.

Re:Well...

[Anonymous Coward]

You are a tard. Let's see google, ebay, and (I think) amazon all do or have done web development in C. See, these guys know that being able to serve a large number of customers without breaking the bank on hardware is worth a little more development time.

Re:Well...

[AKAImBatman]

What the fuck are you talking about?

Tsk, tsk, tsk. As the old saying goes, "Profanity is the crutch of a small mind."

3 and 3.00 are not identical at the binary level

Which you claim to have understood.

from a logical stand point they are the same.

Which was fairly obviously not the original poster's point.

The equality operator works as expected in this case.

Which was not something the original poster mentioned.

So why should the equality operator behave differently for other types ?

Because it behaves differently for EVERY type. You have to tell the compiler how to compare them.

If I'm comparing objects I am most likely interested in a logical comparison and not in a comparison of their respective addresses.

Which is why Java has the "equals()" method on objects. Congratulations, you've taken about two hours of time to come to this simplistic conclusion.

Re:Well...

[Kent Recal]

The == operator - quite consistently - tells you whether you're looking at two references to the same object. I personally find it quite useful and pretty obvious, don't you?

Use What Works

[grunt107]

There are Java pundits, and LAMP lovers. Not to mention .Net-sters.

The real issue is use what works, regardless of 'cool' (hell, COBOL was probably cool once and is still used in some places).

As the story points out, Java is not used for low-level (device) programming. And Assembler is rarely used for data movement (ETL).

I say, for QuADs (Quick And Dirties), use a slower coding language that allows for quick development. For Enterprise-level Web/XML apps use something like Java or .Net (MONO). For low-level use C++/C/Asm.

Or try Bison...

Re:Maybe because it's slow ?

[Ignorant Aardvark]

Java is slower because it's safer: automatic bounds checking on arrays, which helps to prevent buffer overflow attacks, etc. A program made in Java without an eye to security is going to be more secure than a program made in C without an eye to security. Also, for simple things, like programming web game applets, the speed difference doesn't matter much. I'm proud to say that my language of choice is Java.

Re:Maybe because it's slow ?

[xer.xes]

It's really time to dump your 386 and move on to at least a Pentium.

Why is Java UnCool?

[DesScorp]

Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard. Perl has the same difficulty and has it's own cultish crowd (Perl users are the Greatful Dead fans of computer science). Python is somewhat trendy as well.

But Java....Java was designed to be easily learned, and to especially be used in web-based apps. To Unix geeks, that makes it kind of the Visual Basic for the Slashdot crowd. Not something to brag on.

Fact is, it's a great language, and it's still growing. A friend of mine is a professional Java developer (mostly server side stuff), and he's one of the brighter bulbs in the lamp. He loves it, and still thinks Java's potential is largely untapped. Whereas we know what C can and can't do, Java is still growing. He thinks it'll be used (and used effectively) for things we can't even imagine yet.

Re:Why is Java UnCool?

[Atzanteol]

I never minded the language itself. It's pretty easy to use, but I've never found other languages terribly difficult. The one thing that makes Java so much more damned difficult is the environment! Settting up a system to run a given Java application can be a nightmare (CLASSPATH anyone?).

Especially with large applications or J2EE containers. Just getting things to work can take a long time.

As an aside, I don't know why in the hell CLASSPATH has to refer to individual .jar's. Stupidest 'feature' of Java ever. Let it reference a directory containing .jar files, and load them as necessary. Then we can have /usr/local/java/lib or some such.

Re:Why is Java UnCool?

[pthisis]

Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard.

That's not it at all. First off, I'd say Lisp (not C) is the geek Gold Standard--most of your top-name geeks, from Mccarthy on through RMS to Jamie Zawinski and ESR have been LISP hackers, with the notable exception of kernel/systems guys. Even GIMP was written by LISP fans. But C is definitely in the running, primarily because it fits a (rather large) niche very well--it's the closest thing to a portable assembly out there when you need to get down to the nuts and bolts and still be kind of portable.

[Note that I am not supporting any of the following arguments, merely enumerating what I think some of the objections to Java are.]

What Java doesn't do, from a geek standpoint, is fill a niche very well. A true hacker wants a language that is committed; if you're going to be strongly typed, be VERY strongly typed and have a decent type inference mechanism a la Haskell or ML. If you're going to be dynamically typed, by really dynamic like Scheme and Lisp. If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO). And if you're going to be functional, do _that_ full-out like Lisp and ML.

Note that these are all language features. Most geeks want to support a language based on the language itself, not on the libraries or the implementation ("those can be fixed" is the somewhat insightful and somewhat naive argument). As a language, Java isn't anything new and doesn't fit any of those areas as well as other languages.

I think it's almost secondary that Java is a B&D language; it's the failure to be pure about how it implements various programming paradigms and type structures that gives it the geek *yawn*. C++ suffers from the same thing.

Re:Why is Java UnCool?

[j3110]

If you want to refer to a directory of jars, you need to use the boot class path parameter to the VM.

Most people, however, will either use a manifest file:
manifest.mf:
Class-Path: main.jar lib/library.jar lib/otherlib.jar
Main-Class: org.slashdot.example.MainClass

(Don't for get the blank line at the end).

And/Or they will use WebStart, where you declare what you need in XML, and it can be launched and is automatically updated through the internet when available.

All this is free of course, and so is Ant, which you can use to automatically compile and build your directory structure, including your executable jar file and any libraries you need.

If you have a hard time running a Java application, it's the developers fault. There are PLENTY of ways to make it easy... easier than installing software on any other system.

Enterprise grade and Cool

[DG]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?

Perl.

No, seriously - properly written perl is both "enterprise grade" and as cool as hell.

Of all the languages I've ever worked in, nothing let me build systems as easily, as robustly, and as QUICKLY as perl did.

Remember the Daimler - Chrysler merger? Perl was the glue that unified the HR systems and LDAP directories. As far as I know, it still does. Our LDAP - LDAP replicator tool (written in Perl) was a damn sight more reliable than the native replicators, plus it would do schema translation, plus it had a smaller footprint.

Somehwere along the way, perl seems to have picked up a bad reputation for being illegible and obscure - and certainly one has the freedom to write the cliched "line noise" programs if one wishes. But perl done right can not only be legible, it can be beautiful.

DG

Re:Enterprise grade and Cool

[michaelggreer]

Totally true, but Java does a better job of enforcing readable coding, so you never get into that (pretty common) obscure Perl programming. Lots of Perl code is one-off quick fixes, prototyping, glue, etc, so does not get the attention it deserves. Its not Perl's fault: its just so quick to code up.

Perl can be very beautiful. However, that's it problem: its so expressive that the code can be very individual and unique. Not good for the next guy who has to maintain the "poem" you wrote 3 years ago.

Let's not pretend Perl code is easy to read because it would be in an ideal circumstance. In the real world, I would hate to get handed a 5 year old, 1000 line Perl program to update.

Re:Enterprise grade and Cool

[smack.addict]

Perl is not an enterprise programming language. It is a system administrators tool gone mad.

The number one reason: Perl is a maintenance nightmare. This flaw is a result of its beauty, namely a given solution to a problem can be expressed in hundreds of different ways using syntactic elements from a variety of languages. Thus, if you bring in someone who is a Perl novice, they may have no idea what it is going on in Perl code written by someone else.

With Java on the other hand, any novice can come in and understand what is going on inside the code.

Oh come on

[Phaid]

It's just not that hard to understand this. For good or ill, programming has always been an ego-driven profession. You hear stories of punch cards and marathon hacking sessions, and how cool it was that some guy arranged all of his code so that memory accesses were precisely in alignment with the rotation of the memory drum. You do not hear about how cool the fact that someone's applet can't crash because of automated bounds checking and lack of explicit pointers.

Java is seen as uncool precisely because it protects you from your own mistakes -- it's an attempt to make programming approachable to the masses, and the fact that it's forgiving makes it look like programming with training wheels. And just like the 50 year old MBA will never fit in with the Harley crowd, Java programming will never be seen as cool as "real" hackers' languages like C.

Re:Oh come on

[imbaczek]

Look at Python. It's a clean, easy, portable language that protects you from your own mistakes and it somehow manages to be cool. Java is too verbose and doesn't fit my brain; that's why I don't consider it cool.

Type System

[BarryNorton]

Says the article:

Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong. Too much chaperoning?

The problem with most Java code is that there was (for nearly a decade, despite this being a well-established feature of type systems) no parametric polymorphism, therefore using the containers collection meant throwing away the typing information and casting... and, no, the compiler doesn't tell you when you're wrong, not even the static type checker does, the dynamic type checking fails at run time! That's not cool!

I think the guy needs to learn something about modern programming languages before sitting down to write...

If *Java* is uncool....

[revscat]

... where does that put C#? In the basement with the red Swingline?

Classloading, not VM startup is slow

[Anonymous Coward]

VM startup is quite fast these days (tenths of a second on reasonable desktop hardware):

user% cat hello.java
public class hello {
public static void main(String[] args) {
System.out.println("hello, world!");
}
}
user% javac hello.java
user% time java -cp . hello
hello, world!
0.140u 0.020s 0:00.29 55.1% 0+0k 0+8io 0pf+0w

Classloading is slow as all get-out, and even moreso when you're suffering through the startup of a Swing application, since Sun saw fit to make every Swing class reference every other Swing class.

Why Java is popular

[Scarblac]

Java is used a lot these days. There are three main reasons, in my view, why it became so popular:

• In the beginning, there was an amazing amount of marketing and hype.
• After that phase, it continued to be popular because by that time there was a large amount of libraries, both free and commercial.
• As a language, it's not that hard to learn, and it gives some protections that C++ doesn't have.

So if you look at it purely as a language, it's just not that cool. You don't see amazing Java hacks. It's not great, it's just not bad. Add to that a few really irritating things (that are being addressed) like constant casting and having to check every exception all the time... Why would it be considered "cool"?

Re:lame

[Cocoronixx]

Java GUI is slower than native alternatives

Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.

Apparently, one of you two is smoking crack. Take a guess on which one.

Swing

[raffe]

Swing is a brilliant, although hard to learn, API.
Can someone please tell me the brilliant part about Swing. Honsestlly. I want to know! This is not a flameware. Please tell me what I am not seeing here. I code in java almost every day and i like it a lot but the Swing part i dont get.

Re:Swing

[Malc]

I'd also like to know why it's considered hard to learn. When I tried writing some Java stuff (a few years ago) I found Swing extremely straight-forward and obvious. Perhaps that's because I had previous experience with GUI toolkits in Smalltalk, C++ (including MFC!!! ;)) and Modula-2. Perhaps it's not easy to learn if you're a newbie to programming, but then any large class library is going to be challenging.

Re:Making an interface

[cs02rm0]

What would you recommend as an alternative? I've found it hard to stray from Java to other programming languages, even though I'd like to learn a few more, simply because building a GUI with anything else means learning not just the language but an unrelated toolkit or something. I can't find anything else to program in that isn't harder to learn to create GUIs with!

(It needs to be a viable linux option for me though... having just wondered if you're talking about something like VB).

Re:IMHO

[ruckc]

If an application in a language constantly crashes, its 99.999% of the time not the languages problem. This actually brings to light one of the benefits of using java, you know exactly the kind of errors you can get if you read the API. Based on these errors you know you could get, you should make the program recognize and handle the exception.

Totally mis-informed

[brunes69]

The number of mis-informed posts on this subject is staggaring. An attempt to debunk some of them:

Java is slow - This is a myth. A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize. This is highly unlikely.

Java UIs are slow - Java UIs are only as slow as your toolkit. Yes, Swing blows ass. But there are Java bindings for Gtk, Qt, and wxWindows, all of which are pretty cross-platform. And there is also the SWT toolkit from IBM which uses native widgets when possible, and when not falls back on its own widgets.

Java needs a VM so you can't run it everywhere - THis has to be the dumbest one of all. Since when can you write any resonably complex C or C++ application for multiple platforms without some effort? Any C/C++ app targetting anything more than basic POSIX will be littered with #ifdefs everywhere. With Java at least you can complile it just once, then ship multiple VMs , rather than having to adust your code and re-compile for every target platform.

Re:Totally mis-informed

[Anonymous Coward]

In theory, all of hte above is correct.

But I am a JAVA developer using Borland JBuilder X (one of the leading JAVA IDEs, implemented in JAVA) on a 3Ghz machine. The UI is the slowest, most unresponsive thing on my system. If the maker of one of the leading JAVA IDEs can't package their system (w JDK of their choice, toolkit of their choice, etc) so that its responsive on a modern machine using XP Pro, then I think it's fair to say that JAVA is slow for GUIs. (Yes, XP pro sucks, but every other app on my machine, most of which are written in C/C++, work fine.) Try eclipse - even using SWT, my experience is that its about as unresponsive, compared to Microsoft's C++-coded IDE, and even compared to Emacs, which is largely written in bytecoded LISP (and not even a very fast LISP) and has been known as a hog for decades.

Also, while hotspot VMs in principle can grow to faster cpu performance than native compilation, the major cause of JAVA's slowness is space cost, not time, plus startup time (of the JVM, classloader, etc). I've never heard of any JVM which is reasonable in space terms. Most need a 10M resident set for hello world, and go up very fast with increasing complexity of app.

Starting BEA (_the_ leading JAVA app server) on my system takes 30 seconds. This is absurd. (And it's not even precompiling the JSPs needed, because as soon as I hit a page, it chokes again for multiple seconds.)

Plus, htere are things that native compilers are better at than hotspots, as they can make lower-level decisions than a bytecode compiler while they can still see the source tree. I don't think either type of compiler is clearly better than the other, but I don't think its fair to say that JIT is always faster. Try using a few JAVA apps, then using a few C++ apps, and see which one works better.

That said, JAVA has a huge security advantage over C/C++. Even experts screw up sometimes using those languages (look at the occasional security hole in carefully coded bits of core unices). _Any_ garbage collected, bounds-checked language has much of what JAVA has (excluding secure classloaders, sandbox, bytecode verification) for security, in fact. Some, such as OCaml and Common LISP, can potentially be far faster than JAVA, especially at compute-intensive tasks. If speed is no object, use Python or Perl (and I know, sometimes they're just as fast).

Tool choice depends on the task. And sometimes the task is "interface to these twelve hoary enterprise systems using the same language the standards committee decided the other twelve hundred programmers will use." Don't laugh. I think the analogy from JAVA to COBOL has some truth to it...and just think how much better of a COBOL JAVA is, in most ways. But that doesn't mean that Paul Graham should like JAVA. He made his career by seeking out the kind of problem that is NOT subject to the above constraints, but very different ones. (Did anyone actually _read_ his article? Or his other 30?)

Re: Totally mis-informed

[er_col]

Maybe it is a myth, it's one backed by reality. I mean, if after surfing the web my system slows down quite a bit,

killall java

always brings it back to normal. Actually I should use past tense, because I disabled Java globally a few weeks ago, and plan to keep it that way.

Re:Totally mis-informed

[iGN97]

The HotSpot will in time be faster than C++ is an interesting argument, and while it's not illogical or directly wrong, it's unlikely.

The typical argumentation goes along the lines of "in Java, we can monitor the program at runtime to do specialized optimization".

Well, guess what, you can do the same thing in C++. You simply profile the code with live production data and recompile using the profiling reports.

It might not be functionally equivalent, but you have the benefit of knowing exactly what binaries you are deploying and you need not worry that time will be spent optimizing at runtime things that can be perfectly well optimized ahead of time.

I've actually only ever seen one program that outperformed a C/C++-implementation, which was a highly recursive fibonacci-calculator; implementation extremely naive and favoured Java. Implementing the same thing in "real C++" allowed the program to solve the same thing in constant time (at compiletime using template metaprogramming), and even then the compiletime was more than 10 times faster than the Java execution.

I am, however, as always interested in pointers to other pieces of code that isolates a situation where Java outperforms C++, immediately or over time.

string handling

[Spazmania]

I can't speak for anyone else, but the thing I don't like about Java is that the string handling sucks ass. There are how many different types of strings that you have to convert back and forth between in order to do something simple like accepting text from a network socket, altering it, and presenting it on the screen? At least three major type conversions that come to mind as the minimum-path.

Strongly typed...

[Yrd]

...Java's strong typing isn't a problem because it's strong typing. C++ does strong typing rather nicely. Haskell does it even better. Java's libraries, because they don't have anything like templates (at least until Java 5), require huge amounts of casting and instanceof checks to pull anything out of a container. That's when static typing gets in the way instead of being helpful.

I'm quite a fan of static typing, really (honestly), but not the way it works in Java. Of course, I hate lots of other things about Java too, but it's not because it's 'un-cool', it's because it's crap. Even if nobody used it, it still wouldn't be cool (I'd have a party though).

And although it pains me to say it of a Microsoft product, I hope C# takes over from Java, because although it's not perfect (no language is, or can be), it's for the most part what you might call 'Java done right'.

Maybe it's because...

[blackmonday]

Maybe it's because a whole lot of us are too busy working on multi-million dollar financial projects to stop and tell you how cool it is? Java is all about the server side, so if we're not coding desktop apps, its because there's more appropriate software out there for that. That doesn't make Java uncool - there's a lot to be said about enterprise Java. Whether it's cool or not, it works.

By the way, I frequently use a very cool Java desktop app - It's an Amp/Effect editor from Line 6 that controls their Guitar and Bass Amps - It's all Java, looks and runs fantastic. Check it out if you have a Podxt.

Re:Maybe it's because...

[eddison_carter]

Only multi-million dollar projects? Bah :)
Look to C, Assembly, and (but deceasingly) Ada for the multi-billion dollar projects ....

Re:who cares what he says?

[SparafucileMan]

That's bullshit. Didn't Graham start and run his own software company? Didn't he write production-grade code that handled thousands (or hundreds, at least) of users simultaneously? Didn't he make millions doing it? And what language did he use?

That's right, he used LISP.

First Impressions, then second

[Ozwald]

First impressions for java weren't all that good. Back in the early days it wasn't just slow, it was painful. We'd ask "why does VB have a user interface that's so much quicker?" I still don't know. We also asked why every interface looked different. Java never did successful wrap the APIs provided by the OS and there's no reason not to.

By the time of the second impressions, Sun and Java zealots started to become annoying, promising silly things like it was faster than native code. Maybe in some cases it is, but certainly not where it counts: the GUI.

Oz

Java *is* un-cool

[glenmarshall]

One reason Java is un-cool is that it is just another proprietary technology, owned by Sun. If Sun goes away, as it very well may, the Java code-base is at risk. And that would be very un-cool. Linux and Open Source development are cool. Geeks tend to like consensus-based technology that doesn't have a heavy intellectual property burden. Ultimately, Java is un-cool for the same reason that Windows is un-cool.

Java's problem is Sun's mismanagement

[Master Of Ninja]

The problem with Java is that Sun really has managed it properly. We all thought it was cool when it came out, but the promises really weren't true. Write Once Run Anywhere mostly managed to work on different platforms, but the GUI is so god awful slow nobody really wants to bother. Its just easier to code native. I'm not exagerating here that even Visual Basic programmers could have come up with something better.

Sun has let the technology stagnate while Microsoft has caught up (and IMHO surpassed) Java with their .Net products. Hate MS all you want but .Net actually is really easy to use.

Plus I don't know what's going on at Sun marketing, but they've descended Java into acronym hell. Plus the naming conventions don't really make sense now. The new version of Java is J2SE5 (I'm not even sure that it is this now).

I'm taking this from the perspective of desktop developers (rather than the server side as they seem to use Java fine). Java really does blow, and there are now better technologies to use. Sun has even ignored integrating other, better technologies (*cough* SWT) due to NIH syndrome.

If Sun went and fixed their mistakes rapidly (a bit late IMHO) then Java could still be cool. But everyone on the desktop who's used it considers it a steaming POS.

Re:Java's problem is Sun's mismanagement

[wilder_card]

Another big example of mismanagement is that the Sun implementation is so godawful. Java the language isn't too bad (until you compare it to Python). But the Sun compilers are buggy and slow, and the virtual machine uses so many resources it can bring a good server to its knees.

I've seen it stated that adding new features to Java has been given a higher priority than fixing existing bugs. The result is a huge collection of libraries, none of which can be relied on to do what the documentation says they will.

Oh double negative, why do you haunt me!!!

[pottymouth]

"And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero"

Why do I get the feeling I wouldn't want to debug this guys code??

Re:Maybe because it's slow ?

[CurMo]

Java really isn't -that- slow. That's a common misconception.

Everyone thinks "Java is slow" because the only time they experience Java is in a Swing app. Swing is VERY bloated and therefore very slow. The only other "slow" processes in Java are Garbage Collection, which is pretty minimal if the app is written correctly, and the initial startup of the VM.

Look, for example, at Eclipse IDE. Eclipse is a Java app, and its extremely powerful and not very slow. Why? They use their own widgets that have less overhead, they are not using Swing widgets.

Also, a correctly written OpenGL java app has been proven to perform at 85% the speed of its C counterpart (yes C, not C++). A couple of guys (I can't find the link) ported QuakeII to java to get this statistic. Not bad considering the relative youth of OpenGL bindings in Java.

I once had a "Java Sucks" attitude myself (I've been a hardcore C++ programmer for over 9 years), but I must say, after using the language for quite some time (~2 years), I've become very fond of it, and have written several large & FAST Java apps -- in about 70% of the time it would have taken to write in C++.

This is mostly babble.

[theonomist]

First, I've read Graham's essay, and his definition of "Great Hacker" is on the vague side, and consists largely of platform advocacy. It turns out that his "great hackers" are all people he knows. Fair enough: He can't really judge anybody else. But that leaves him with such a small and selective set of data that his conclusions are meaningless. For example: He claims that all "great hackers" refuse to work on Windows. He works at companies developing software for UN*X. Not surprisingly, most of the programmers he knows are UN*X people, who don't work on Windows. So what? This proves nothing at all. He has merely suggested (however plausibly) that Windows developers tend not to develop for UN*X and vice versa, which is tautological. Dennis M. Ritchie has a Windows box on his desk these days, but Graham doesn't know Ritchie personally, so Ritchie's not considered. Graham's working from a thin set of anecdotes.

Secondly (and this has been said before), Graham's "great hackers" are prima donnas who refuse to deal with practical problems outside some very limited set of problems that they enjoy. I remember a story about Richard Feynman helping paint the walls at Thinking Machines when he worked there; I guess Feynman wasn't a "great hacker".

Finally, I often hear from Java advocates that the memory-lebensraum problem and the speed problem are due to programmers not understanding the internals well enough to work around their flaws. This is not said to be true of any other programming language on Earth, as far as I know.

It all sounds like a crock to me. Knowing the tools better will always help, but if only an expert can write usable code -- not great, but merely usable -- the language is junk, or at best the implementation is junk.

Re:This is mostly babble.

[bugbear]

if only an expert can write usable code -- not great, but merely usable -- the language is junk

Is that really true? In many fields there are tools that only experts can use properly. Why should it be different in programming? I think Michael Vanier makes a good point about LFSPs.

Re:promise

[proj_2501]

Java is completely unrelated to JavaScript, JScript, and ECMAScript. JBoss is not a separate language; it's an application environment written in Java.

Re:who cares what he says?

[alex_tibbles]

never built a real world system?

Re:who cares what he says?

[originalsyn]

Unfortunately, your assumption is completely false. Paul Graham has been wildly successful in the corporate arena. For just one example, he's responsible for the software behind yahoo shopping's dynamic web stores (which was written in Lisp). While I don't agree with the man on a lot of things, his track record lends him quite a bit of credibility.

Perhaps hackers like hacking?

[mwvdlee]

And hacking requires low-level access to the system which Java simply does not offer.
Yes you can add low-level functionality to Java, but you're not programming THAT in Java now are you.
I am a full-time Java developer and for all the goodness it brings there is also the lack of a decent referencing system to allow ingenious algorithms, good GUI mechanisms (Eclipse does a decent job to proof a Java GUI can work but is still no match for a native application) and, for instance, a standard and well-performing OpenGL API. There are many other things missing but most of it just boils down to the fact that it cannot access OS-specifics when needed.

Re:Maybe because it's slow ?

[nkh]

Java is not more secure than Ruby or Python. They all check the access to arrays, are object oriented, have exceptions support and a cool standard library. The only advantage for Java is that its standard library is bigger than the other languages.

Re:resentment

[JavaPriest]

I surely believe what you are telling, but in what way is Java responsible for that? Your companies uncool recruiters are to blame here.

Re:Maybe because it's slow ?

[Florian Weimer]

A program made in Java without an eye to security is going to be more secure than a program made in C without an eye to security.

I wouldn't count on that. The classes of vulnerabilities that affect typical C and Java programs are just different. Of course, buffer overflows aren't a problem for typical Java programs. On the other hand, lack of synchronization is not such a big problem in the C world.

For example, if you write a web application in C, it's quite unlikely that it exposes data from a different session if you hit the browser's back button. With Java, such problems do occur (because the same servlet object is used in different sessions and some programmers use it to store session-specific data).

Re:Maybe because it's slow ?

[banzai51]

You may not like to hear it, but it is still TRUE. It's a problem that has to be addressed. You can't take the Microsoft tact and hope hardware speeds up enough so the difference is too small to matter. Full programs written in Java simply suck. They're slow, don't follow any native UI guidelines, and are a thorough pain in the ass to use.

If a company brings their product in and it is written in Java, they are demoted and booted if any of their competitors have a remotely close app. I hope SUN sits up and takes notice of that last bit. People using your little system are losing money.

Re:lame :)

[forgotten_my_nick]

Your refering to SWT making JNI calls to the native GUI API calls. SWT framework also allows it to be portable.

However eclipse itself is built on java and isn't slow.

Only slowness I have seen in java is in applets in browsers or coded to the MS JVM.

Re:Maybe because it's true

[EmperorKagato]

I used to say the same thing whenever I ran Azureus: A Java bittorrent client. Now, I am amazed by the new release. Azureus takes up less processing time and no longer memory leaks. Like all other languages Java has the potential to be optimized.

Who Gives A Shit?

[jjohnson]

Anyone still concerned with whether or not their favoured language is cool or not is a 1) hack, 2) student, or 3) self-described 'geek' who's not nearly as good as he thinks he is.

Java works well in some environments and for some tasks, and poorly in others, and a lot of that depends on the programmer, not the platform.

Besides, success is its own argument. If you can't understand why Java is so big these days, maybe that's your fault, and not the world's.

Re:Maybe because it's slow ?

[danheskett]

Except that Flash 6 is like ~500kb and a decent JRE is like 30MB.

Flash 6 can install on accident even on a dial-up modem. You won't be accidentally downloading a huge runtime to get Java installed.

Re:Maybe because it's slow ?

[dajak]

I notice everytime I use JAVA, it simply eats processing time, even though I am not currently running anything.

That problem is solved if everything runs in Java, and Java is part of the kernel.

Heck, playing devil's advocate here, as I think JAVA as such has a very nice API.

I agree. Of the languages I am allowed to code in nowadays, it is also the most elegant one. One of the problems of Java is that there are gigabytes of example code on the internet of how not to program. Crappy memory and resource management and bad string manipulation are the worst problems. I rarely have performance problems, as long as I don't have to write a GUI or use an application server or XML related library.

Re:promise

[southpolesammy]

Why the hell is this modded up? Java has nothing to do with javascript, jscript, ecmascript, or jboss. That faulty premise is so old and tired that it surprises me that people still are confused by it.

And as far as Java 1.2 vs. Java 2 goes -- ever heard of versions? You really think that everything in the original specifications were rock solid and that nothing needs to change? That's ignorant.

-1, Troll

Re:Maybe because it's slow ?

[molarmass192]

I have news for you, you WERE right, it is because of "programmers who weren't leveraging Java correctly". The same crap goes for bad C programmers. The problem is that the VAST majority of Java programmers who haven't worked in C rely ENTIRELY on automatic garbage collection and produce excruciatingly fat code. To summarize, in C:

many mallocs - zero frees == bloated crapware

while in Java:

many news - zero "= null"s == bloated crapware

... the big difference is the first one is also a leak.

Re:Maybe because it's slow ?

[dtfinch]

Maybe Java is fast but what people see is that Java gui's are typically slower than hoped.

I've tried the 1.5 beta and it seems to go a long way toward addressing this problem. It feels as fast as native, and easily beats gcj in my own unprofessional benchmarks. But massive Java applications like Eclipse and NetBeans still perform horrendously slow for me, even with the server vm, and I doubt it can be blamed on any gui toolkit.

Re:Why, Python, of course.

[JSkills]

Won't be able to read your Perl program? Isn't that blanket statement? Does it really depend on who's writing the code?

Anything I write in any language is extremely readable by anyone - because I code that way. Period.

Re:Maybe because it's slow ?

[mwood]

It's the startup time.

I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

Notice that as the size of the app. grows, and the time you spend in it begins to dominate the time you spend getting there, this becomes less and less a problem. But it's still noticeable. The time-to-first-interaction is painful here on a box that opens non-Java, non-Gnome app.s in what my human nervous system perceives as zero time.

There's no reason writ in stone for code compiled to an abstract architecture, running on a suitable interpreter, to be slower than native code. It could be *faster*, if the architecture is well-designed and the interpreter well-written. I have no doubt that someone could trot out an app. which runs faster in Java than in native machine code made from well-crafted C.

Overheard in a recent Sun board meeting...

[Junior J. Junior III]

Exec1: Bill, we have to do something about Java.

Bill Joy: What's wrong with it?

Exec1: No one's using it.

BJ: The hell they aren't. Java's everywhere.

Exec2: Well, maybe, but no one wants to use it.

BJ: Why?

Exec3: Maybe because the performance sucks compared to programs written in C++?

BJ: That can't be it. Sun hardware doesn't perform very well either, and people use our servers all the time! By the way, you're fired.

*uncomfortable silence*

BJ: Well, why else can it be unpopular?

Exec1: Sir, I think geeks won't want to use it because it's not cool enough for them.

BJ: Not cool enough for geeks? How the fuck does that even make sense? Someone get marketing on the phone and tell them we need an X-TREME mascot for Java, right away. That'll make it "cool" enough for these geeks.

Secretary: Yes, sir. Right away sir.

BJ: Alright, now then, what else is on the radar?

Re:Go write me an OS in Java

[LnxAddct]

Here. I guess java is a cool language after all. BTW, the OS I just linked to is pure java with a little assembly stub that loads just enough to get a JVM running, from that paoint on its pure java. I love java, I also like C++, but I have yet to find a language that is comparable to java. If for nothing else, it is indispensable because of its amazing APIs, ease of use, amazing IDEs, speed (with the 1.5 VM from Sun, you can only achieve similar performance hand coding the app in assembly - look into hotspot, its on the fly optimizations at the lowest level), portability, and deployability (google for WebStart). Any real programmer understands the value of Java, we are just too busy being productive to convince the /. groupthink otherwise.
Regards,
Steve

Lack of Flexibility (Why *I* don't like java)

[dspeyer]

Java has no function pointers. If you want to include callbacks in your data structures, you need to do hideous things with interfaces and virtual functions. You probably need to waste lots of space instatiating them, too, because you can't put a class in a data structure. Granted, you could auto-generate this code (I would if I had to), but using code generation for something which is trivial in a lower level language like C is a very bad sign.

If this is too abstract for you, consider the following C code for a simple command-line interface:

struct command_t{

void (*)callback(char *data);
char *name;
char *help;

};
struct command_t commands[]={

{exit, "exit", "exit this program"},
{help_callback,"help","get help on a given command"},
{save_callback,"save","save you work to a file"},
(NULL,NULL,NULL}

};

void run_command(char *comm){

int i;
char *c;
c=strchr(comm," ");
*c=0;
for(i=0;commands[i].callback;i++){

if (!strcmp(comm,commands[i].name)){ commands[i].callback(c+1);
return;

}

}
printf("Unknown command: %s\n",comm); }
Implementing help is left as an excercise for the reader. So is handling bogus input. The point is that this way I can add a command without touching the command parser -- just write the callback and insert it into the list. If there's some more sophisticate processing needed on some commands, I just add a flag to the structure and do the work once in the parser. Short of code generation, how would I do this in Java? A switch statement is not acceptable, because it means that everwhere I deal with commands, the data will be duplicated (embedded in the code).

That's just getting started, of course. Then there's the type system, which uses hideous wrapper classes around the most useful types (this can and should be done transparently without involving the user -- lisp, python and ruby do it fine). There's the complete lack of introspection. There's the absolute need to put every helper function into a class whether it logically belongs there or not, bloating classes beyond the problem-space items they represent. There's the misdesigned basic library so complex I need documentation every time I read from a pipe....

It just takes far too much work to make Java do anything I want.

Re:Lack of Flexibility (Why *I* don't like java)

[Anonymous Coward]

What's the matter with the following code? (broken up into appropriate files, of course). I wouldn't call this "hideous", and as far as I can tell, it implements what you're trying to do just fine.

public interface Command {
public void execute(String data);
public void getName();
public void getHelp();
}

public abstract class CommandImpl implements Command {
protected String name;
protected String help;
public String getName() { return name; }
public String getHelp() { return help; }
}

public class exitCommand extends CommandImpl {
{
name = "exit";
help = "exit this app";
}
public void execute(String data) {
// do what you want here
}
}

public class someClassThatDealsWithCommnads {
Map commandMap = new HashMap();
public void addCommand(Command command) {
commandMap.put(command.getName(), command);
}
public void executeCommand(String name) {
Command command = (Command) commandMap.get(name);
if (command != null) {
command.execute();
} else {
// deal with bad input.
}
}
}

Slashdot's lameness filter bites my ass, so I have to put some more text here to give this post an appropriate ratio of "good" characters to "junk" characters.

Careful design can get around the need for hacks like function pointers (I know that I'm going to get flamed for that comment...). You don't necessarily design things quite the same way in Java as you would C, but that doesn't make it bad. It might mean that C programmers aren't automatically good Java programmers.

Relating to your last comment (about needing documentation to do things): don't confuse your lack of experience with Java with lameness. Sorry, but once you use it enough, you'll only be needing references to do things that you haven't done before. I guess that the alternative is to have slim class libraries that don't give you too much to remember, and as a result require you to code everything from the ground up. No thanks - I'd rather not re-implement the wheel every time I have a project to code.

Now the lameness filter is really starting to piss me off. How much do I have to type here? blah blah blah. Talk about lame.

Introspection: how about java.lang.reflect? Not used very much because you can use good design to do just about anything that you'd want to use reflection for, but it's there for those circumstances where you need it.

Really, what's the deal with the lameness filter? How much actual junk (as opposed to what it's calling junk) am I going to have to include here in order to get this thing posted? It took me less time to write the above code than it has taken for me to defeat the lameness filter! Lalalalalalalala.

Re:Lack of Flexibility (Why *I* don't like java)

[toriver]

ava has no function pointers. If you want to include callbacks in your data structures, you need to do hideous things with interfaces and virtual functions.

No, you use the Command or Strategy patterns to solve the problem the function pointer "hack" is used for in C/C++.

Java doesn't have function pointers because it's not C. I am sorry if anything non-C frightens you, but it's time to move on. If language A doesn't have feature B of language C, it means you need to learn something new instead of just apply the knowledge of C to everything.

C is just assembly that has put on finer clothes, trying to look like a higher-level programming language.

Re:Lack of Flexibility (Why *I* don't like java)

[Big Boss]

You obviously haven't used some of Java's more powerfull APIs. Take a look at java.lang.reflect.* sometime. You CAN put classes into data structures (other classes with the Class class), you can call arbitrary methods on objects (Class.getMethod()).

So you could do something like this:

public Class CommandHandlers
{
public command_Help()
{
// show the help here...
}
public command_Save()
{
// save here...
}

public void command_Exit()
{
System.exit();
}

public void doCommand(String command)
{
getClass().getMethod("command_" + command).invoke(this, null);
}
}

This is really basic, but you get the idea. Some of your other complaints are annoying, but not as big a deal as you seem to think. I have wanted autoboxing about twice, I don't use things like Integer much. I just use the primitives. I have wanted generics for quite some time, avoiding the need to typecast (and to get compile-time checking) when using collections, but that's a minor thing, and is coming in the next version (along with autoboxing/unboxing).

Helper functions have to be part of a class. So what? Make a Utilities.java if you want and call them from there. You have to put them all in a .c file anyway, so it's not THAT big of a difference. You don't even have to instantiate the object if you declare the methods static.

I don't find the class library nearly so complex as you seem to. I think it's eaiser to work with than standard C++ or MFC. Sure, clib is a simpler, but it's also less capable.

Most of the complaints I see about Java boil down to "but it's DIFFERENT". So what? Every language is different. They all have strong and weak points. If I could have Java's code with C's memory usage, I'd be so very happy. ;)

Re:Lack of Flexibility (Why *I* don't like java)

[Pentagram]

Short of code generation, how would I do this in Java? A switch statement is not acceptable, because it means that everwhere I deal with commands, the data will be duplicated (embedded in the code).

Polymorphism. It has the advantage of being far more readable than your code.


Then there's the type system, which uses hideous wrapper classes around the most useful types


Autoboxing.


There's the complete lack of introspection.


Reflection.


There's the absolute need to put every helper function into a class whether it logically belongs there or not


Every function logically belongs /somewhere/.


There's the misdesigned basic library so complex I need documentation every time I read from a pipe....


I'll concede that point. Streams are a bit of a mess. But at least the documentation is good :)

Re:Maybe because it's slow ?

[animaal]

Synchronization is not a problem for C because the average C programmer writes single-threaded code, and it tends not to be server-side (and if it is, it tends to be CGI, which doesn't scale well. It's possible to run Java in from a CGI script too). Of course it is possible to write multithreaded apps in C, but then synchronization becomes a big issue too.

Server-side scalability means pooling, caches, lots of things that imply resource sharing. This means some form of synchronisation, whatever the implementation language.

Re:Maybe because it's slow ?

[LnxAddct]

Thats a programmer error. A bad programmer can make anything happen.

Are your apps constantly restarting?

[FatSean]

Mine aren't. They run for weeks and months at a time. Startup time is irrelevant in the enterprise.

Re:Are your apps constantly restarting?

[Switchback]

You're correct, but I think we're comparing apples and oranges here.

On the server side, startup time isn't an issue and neither is the memory consumption or vast GUI issues that Java has. It is, however, a completely different story on the client side.

There are several problems with Java that more or less make it unsuitable for client side applications.

• While non-GUI Java is sufficiently fast, Java GUIs (particularly SWING) are horrendously slow. They also don't quite have the proper look and feel of a native application. Java GUIs also tend to be quite buggy. Both SWING and SWT have many problems.
• Java takes up too much memory. Client machines dont' have the memory resources that servers do. Java apps take huge amounts of memory to run and cause many machines to start swapping...especially if you are running 2 or more Java apps. This kills the client performance more than anything.
• Startup time is horrible. Again, this is not an issue with server side, but I don't want to wait a minute (which is perceptively a very long time) for an application to start up.

I could go on from a programming side as well, but that's off-topic on this thread.

Re:Are your apps constantly restarting?

[dasmegabyte]

I've mentioned this before, but the primary difference between a C/UNIX programmer and a C#/Java/Windows programmer is the perception of what constitutes a program.

In UNIX, a program is usually a tiny little thing which passes its output to other tiny little things, creating a network of programs controlled by a lightweight master program. Because of this, programs HAVE to have a small footprint and have to start up and close down quickly. A good UNIX program does only what it's supposed to, and then it quits.

In a Java/C#/Windows program, you generally start the program once per day/week/year. The program, once started, calls objects with functions that operate the same as individual programs in the UNIX paradigm. Because the program is doing all of the work and all of the flow control, it doesn't matter if the thing starts or stops quickly, doesn't matter if it uses a lot of memory, because you're not going to be using that memory for a whole lot else. A good Java program does so much, it's almost like its own windowing or operating system.

The essence of "I don't understand OOP, it's full of bloat" is the perception of what a program is and does. If you think a program should do one small thing and then pass its output or control to another program, you're essentially in the OOP mentality already...substituting processes for objects and programs for functions. On the other hand, if you believe as I do that programs should sit open and ready to use on a whim, even the fast startup time of the average UNIX utility is too much. You need the memory allocated, the commands loaded and ready to handle whatever you've got to do -- which is why OOP makes sense. You don't start your notebook every time you need to jot a note (I don't anyway)...you just pick it up and write.

Anyway, to get on topic: I always thought Java *WAS* cool. All the under-40 programmers I know LOVE Java, even if they don't use it. It's almost a spiritual thing (I plainly remember wearing a "Java is the Way" back when I was a Java coder) and it's even more mysterious because the older generation of C coders didn't like it. Not disposing of objects and relying on GC is the programmatic equivalent of not cleaning your room. And a good UML diagram reads like a map of a futuristic city.

Re:Are your apps constantly restarting?

[kill -9 $$]

I (like many others) have been saying for years that its a matter of right tool for the right job. Also, I'm very competent in Java, C/C++ and Perl. I also, typically develop exclusively for UNIX and stick to the UNIX philosophy of building small, highly configurable/reusable programs wherever I can.

The truth is though, not all applications can be distilled down into simple pipe/filter utility-type solutions. In these cases I typically like objects. If you understand OO programming, and I have found few who can both claim they understand and actually do (its about a 1:5 ratio from my experience) you can build very complex/robust systems very quickly. The tradeoff, memory. In this case I usually use java. Yes, its restrictive, and you can't do everything you can in a different language like Smalltalk or C++, but for most things it is capable. Its also cross-platform, if you know what you're doing, and there are hundreds of "standardized" API's for doing lots of stuff. Not to mention, because of those API's, you can actually get cross-platform database connectivity, web applications, and in theory but not really yet, enterprise services.

If it comes to writing simple utilities, throw away code, anything that I feel falls into less than 100-200 lines of Perl code, I'll use Perl typically. My experience with Perl is that it doesn't scale, from a software management perspective, as nicely to large complex systems. Its usefulness though, is that you can do some pretty powerful stuff, without having to get bogged down in datatypes, complex exception handling, complex string manipulation and other language-isms that you have to deal with when you use a more strict language like C, C++, or Java. I also like the fact that anything I can write in C I can typically write just as easy in Perl, so for some of that systems programming type stuff that Java doesn't do so well, its nice to use Perl and not have to get into the guts of a C program

As for C/C++, I avoid them whenever I can :). Only when doing embedded programming do I get into C and C++ is typically on a supporting existing code type basis.

Again though, it comes down to right tool for the job. I've had this argument time and time again with PHP, Perl, and Python programmers and it always seems to come down to size/scope of the problems they are trying to solve. Most people who love these tools have written what I view as smaller applications. They have never had to write an e-commerce system that ties together multiple enterprise datasources, call into SOAP/CORBA etc services on another box, etc. Or the other thing I experience is that if they have, they end up reinventing some API/technology/feature that was already present in Java or that had they implemented their solution in Java would have made their life much easier.

Anyway, this has been my experience, and this is the toolset I use to solve the problems that arise in my world. Everybody is different, use the right tool.

Re:Are your apps constantly restarting?

[darkarena]

Being in the "OO Mentality" and observing OO Design are two different things. The real features of OO Design depend heavily on Polymorphism and Inheritance - something which modules or procedures do not. This is not to say that the modules themselves to not use objects, but don't mistake the consuming of libraries and functions in a C Program for OO programming.

The difference between the systems in not so clear cut. It is true that JAVA programs (generally) have a larger startup time. The reason for this is NOT because of the Java language nor the byte code it generates, rather the extra startup time is because Java needs to run on Intel based machines using a Virtual Machine. This is both an advantage AND disadvantage to JAVA, one that a company (or programmer) would need to evaluate before choosing the language and Platform.

Do NOT, however, mix this up with C# and Windows Programs. Like Linux, Windows is an Operating System. Debates aside, the usage of .NET and COM programs is a lot closer to what you would find in the Linux environments then what you would find in the Java Virtual Machine. Running Java on a NATIVE Java Machine, however, and you'll notice all of those startup delays disappear.

The real truth here is scale. Bigger programs take longer to start up then smaller programs. In large implementations, the JVM start time becomes negligible. If start time is a consideration, then by all means writing code NATIVE to the machine will always have an advantage. JAVA, however, offers a WIDE variety of advantages over its older counterparts which, in my opinion, makes it a very strong competitor to other platforms.

As far as calling Java Programs LARGE is not a fair assessment. Many of them are simply because Java makes it easier to implement large system then it's native counterparts. Furthermore, one of JAVA's biggest advantages - it's cross-platform compatibility - is typically needed most in large applications. Your analogy of starting up your laptop is a valid (albeit a bit exaggerated) assessment of JAVA, but it greatly oversimplifies your assessment of the language in general. Good OOPs do ONLY what they need to in a class and then return. Similar concepts exist in C++ and C#. Perhaps the Windows libraries are not as LEAN as they should be, but again the concept behind their ten millions dlls is the same as in Linux, to provide small tools that a master program can piece together.

Debunking Pro-Java Myths

[Frankie70]

Pete Becker of Dinkumware has debunked a lot of FUD spread by Java Programmers. Pete worked on the Java Library & the C++ Library for Dinkumware (& earlier for Borland) so he knows quite a bit about the subject.

Here are his usenet posts on the subject.

Re:Debunking Pro-Java Myths

[brunes69]

Some of his posts are grossly incorrect. Examples:

But the semantics for many programs would not be correct, since Java requires array bounds checking. Disabling it means that you're not compiling Java.

True, if youe xceed the bounds of an array in a Java app you will get an array out of bounds exception - but that is the worst that can happen, a nasty error message. However, this is a totally different can of worms in C/C++. If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.

You've posted three examples of code that you claimed was as fast or faster in Java than in C++, and every one of them, when compiled properly, turned out to be faster in C++ than in Java.

Faster when run how many iterations under hotspot? 1? 10? 100?

In Java you have to write nine copies of the basic sort function: one for arrays of chars, one for arrays of doubles, one for arrays of Objects, etc.

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.

I could go on and debunk more of his debunking, but I can tell from his posts that ihe is quite biased and is not being resonable. Just for reference, I am *not* a Java developer. I write a lot of C++ code and a lot of java code, both are ideal for certain situations. For example, desktop apps with need for a fast startup time will always be best written in C++ until Java Vms are built into the OS. But for long-running business applications, where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down.

Re:Debunking Pro-Java Myths

[iGN97]

If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.

You don't need to check the bounds of every single array all the time. This is why STL puts some trust in you. It's easy as hell to make STL-code that compiles and crashes and burns, but it's obviously for a reason. Constantly re-checking data that should be validated elsewhere, relying on exceptions to communicate an error message is extremely inefficient. That's why it's not done in C++. Writing operator[] with bounds-checking has got to be one of the simplest things in the world in C++.

Faster when run how many iterations under hotspot? 1? 10? 100?

There it is again, the cluthing-at-straws "somewhere down the line it will be faster" that is so typical from a member of the Java community. What does it take to actually produce some code and a supporting environment that actually outperforms some C++-code and is not just a castle in the clouds?

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.

Java 1.5 doesn't have templates, it has generics. Generics in Java are not much more than autocasting and autoboxing; basically two constructs that introduce even more runtime overhead. It also has a number of other shortcomings, like the inability to tell the difference between a List<JavaCoders> and a List<Donkeys>, and frankly so have I.

C# 2.0 at least makes a decent attempt to get this right, but falls a little short if you're used to C++ templates. In C++/CLI you can have both and should be a happy camper.

The point the original poster was trying to make, however, is that C++ templates are better than Java generics because they lend themselves to implementing generic algorithms. Being how you're a C++ coder, you should understand this.

Re:Debunking Pro-Java Myths

[master_p]

I don't know how you ended up modded 5-insightful, but you are the one to be hugely wrong.

If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java

Why should I have the burden of array bounds checking forced on my neck? In C++ I can skip it wherever the array access is trivial, and that's a lot of cases. What happened to freedom of choice?

Faster when run how many iterations under hotspot? 1? 10? 100?

First of all, no benchmark runs 1 time only. Secondly, the hotspot compiler does not re-optimize an already optimized block of code.

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object

This has several drawbacks: a) it forces you to go back to where the collection is created to see want kind of key is being used b) it allows for any type of object to be inserted in the collection, which is undesirable.

Additionally, Java 1.5 has templates so it is a moot point.

Java templates are nothing more than autoboxing. The Java 1.5 generics still use Object-derived instances internally, with many disadvantages: a) losts of unecessary dynamic casts that slow down the program, b) lots of unecessary small object allocations like integers.

Just for reference, I am *not* a Java developer.

It is obvious.

both are ideal for certain situations

C++ is much better as a language specification than Java (with many minor problems), but the language environment has serious flaws. Imagine a C++ running with garbage collection and the same toolset as Java, and you can easily see what language is the best.

until Java Vms are built into the OS

BS. You don't need that built into the OS. VMs are frequently updated.

where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down

You got that one right, mate.

cheapest that still gets the job done...

[dpilot]

I'm not sure I see anything wrong with that, though I guess really you have to examine "cheapest" very carefully. I'm sure that the Slashdot crowd is even less likely to program in Ada than in Java, and gripe even harder about the higher "overhead" in Ada than even Java has, and how it gets in the way of their coding.

Yet you have to look at the initial assumption of Ada as a programming language *for embedded systems.* For the Ada target market, they had studies indicating that 90% of the programming "cost" was spent in maintenance. From this perspective, initial coding is a nit. Even debug was rated as more expensive than initial coding.

So you have to look at the meaning of the word, "cheapest." (If they mean cheapest tools, regardless of suitability to the job, I have to agree with your attitude, though.)

Re:Strongly typed - Good or Bad?

[brunes69]

Disregarding the about 35 syntax errors in your example, if it is doing what I think it is doing ( and because of the errors I cannot be exactly sure what you mean), this is no different from using the Object superclass in Java.

Object inJava is like void* in C/C++. Every class inherits from Object so you can cast to and from it when you need to pass around generic pointers.

The Java version of what i think you meant:

public class A
{
public void doStuff()
{
System.out.println("A::doStuff()");
}
}

public class B extends A
{
public void doStuff()
{
System.out.println("B::doStuff()");
}
}

public static void main( String[] args )
{
A a = new A();
B b = new B();
Object c = (Object)new B();

a.doStuff();
b.doStuff();
((B)c).doStuff();
}

Re: Cheap Shot

[freality]

Actually, programs are abstractions of electrical systems that, though I have programmed a simple CPU in an FPGA and wired up breadboards, etc. etc., I still don't understand. And Physicists don't even understand Physics! And thanks to Gödel, it's clear we don't understand Math! Argh. Who can save us?!

It's an indictment of Aristotle, Kant, the Enlightenment and the Scientific Method that all of our attempts at formalizing the universe blow up in our faces.

Until we approach every program as the algebraic systematic proof of a string-theoretic electrical circuit model, we will be burdened by the inexorable piles of poo that is the vast majority of the software written today.

Re:who cares what he says?

[Anonymous Coward]

There are. Several big commercial Common Lisp packages (eg.), and for Scheme (a Lisp variant), a nice little free download from Rice University. I've been playing with the latter since reading Graham's latest, and it's sweet...auto-indenting, highlighting to show matching parens, source-level step-by-step debugging, unit-testing support....then there's Emacs support of lisp code editing (again with the parens matching), and the Bigloo package for well-optimized code that compiles to native or JVM (with full access to Java libraries)...google and you'll find plenty.

Re:Maybe because it's slow ?

[LnxAddct]

Java is not slow. Have you used it in the past 3 years? With the JIT compiler alone, you achieve C++ performance, in come cases better (believe me, I've had to run these benchmarks a million times), and with HotSpot, some java apps run so fast that similar speed can only be achieved by hand coding the app in assembly. HotSpot does on the fly optimizations at the lowest level. It pretty much learns what paths the program takes most often and optimizes for them, its a truly amazing and indispensable thing. The notion of java being slow came from the Swing gui. Swing is a little slow to react everynow and then, but its mainly due to its robustness. Regardless, even Swing isn't really an issue anymore. One of the greatest java apps I've seen recently that was coded really well and shows some of java's potential is Azureus. Java is a great tool in a toolbox of many great tools (i.e. python), and thats how it should be treated. Also, deploying an application with Java's WebStart makes deploying applications fun again:)
Regards,
Steve

Re:Maybe because it's slow ?

[contagious_d]

I'm proud to say that my language of choice is Java.
I agree. During my first two years of school we programmed almost exclusively in Java. We were the first incoming freshmen to take the introductory classes after they made the change from teaching in C++, and I noticed that a lot of the people who spent their time complaining about the use of Java were the same ones that failed the classes and changed from CS or IS majors to IT, Meteorology, or Living in the Basement majors. At the time, I was doing most of my schoolwork on an old eMachine with a Cyrix processor, and, although the POS pretty much screeched to a halt when I launched them, it handled Java apps fairly well once they got up and running. Uh, anyway, Yay Java!

One word.

[Atzanteol]

CLASSPATH. This thing sucks. Worst design decision ever, I swear. Spend forever setting the frigging thing up, and hope to $DIETY things don't change. Oh, and make it so you need to reference individual .jar files too! What a great idea? What to add a library to your project? Be prepared to do battle with classpaths.

Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH? I'd love my CLASSPATH to just be "/usr/local/java/lib:${HOME}/java/lib" or something rather than specifying a million .jar files...

Re:One word.

[dajak]

CLASSPATH. This thing sucks. Worst design decision ever, I swear. [..] I'd love my CLASSPATH to just be "/usr/local/java/lib:${HOME}/java/lib" or something rather than specifying a million .jar files...

You want to dump all your libraries in one directory? Now that's a good design decision. Don't forget to check whether Micro$oft patented that practice.

Re:One word.

[anomalous cohort]

Would you rather have to depend on the system registry?

Ultimately, the CLASSPATH is good for you. I don't really understand what the problem is with adding another jar file to this environment variable. If you insist on being lazy, then rejar everything into one big jar. Ant can help you do that.

Re:One word.

[graveyhead]

A bit of shell script ususally solves this:

CLASSPATH=""

for x in `find /usr/local/java/lib -name '*.jar'`; do
CLASSPATH="$CLASSPATH:$x";
done

for x in `find $HOME/java/lib -name '*.jar'`; do
CLASSPATH="$CLASSPATH:$x";
done

You could put the first for x in... statement in the global /etc/bash.bashrc, and put the second $HOME for loop in ~/.bashrc so that it's run on user login.

At least this way you don't have to maintain it, but if you add .jars to one of the directories, you'll have to re-login to bash before starting the runtime.

Hope that helps!

Re:One word.

[Atzanteol]

Oh, god no! I just want it to behave more like 'libraries' under Linux/Unix. Let me edit /etc/java.conf to set which directories hold "libraries" (jar files). Java wants too much on the command line. One needs to be a good shell script writer (and/or batch script writer) as well as a Java developer as it is. Ever seen the weblogic startup scripts? *huge* shell script infrastructure just to setup all the correct params to java.

Re:One word.

[That's Unpossible!]

Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH?

This issue was solved a long time ago.

You put your .jar files in the jre/lib/ext directory of your Java Runtime Environment. They are magically found when you use the JRE as your runtime environment. I haven't had to set a classpath environment variable in a long time.

Re:who cares what he says?

[nessus42]

Of course there are full-featured IDE's for Lisp. In fact, the very first IDE's were made for Smalltalk and Lisp.

The fact that you can't understand Lisp speaks more to your intelligence than to the merits of Lisp. As Paul Graham says, he is talking about the tools preferred by the best and the brightest programmers, not by average programmers.

|>oug

LISP IDE

[flink]

Here you go.

Re:who gives a shit about paul graham?

[bay43270]

I'm reading his book (Hackers and Painters), which is a collection of these essays you talk about. He has an entire chapter in his book called "What you can't say" in which he talks about how often extremely controversial subjects turn out to be correct. He explains his method of guessing which shocking thoughts are wrong and which are just unfashionable. This outcry against Java is just an attempt to put his name in history as being the guy who said it first (as are most of his essays). It does him no harm for several reasons:

1. Because of his personal programming style, he would never like java anyway
2. Eventually Java (like anything else subject to technological change) will become unpopular and he will be proven correct
3. He prides himself on his nerdyness and doesn't care what management types think of him. He is looking for acceptance from the slashdot geek, who will more often than not agree with his language preferences

Because it is a limiting language

[An Elephant]

Java is considered uncool among good programmers because good programmers seek abstractions, and factoring out commonalities. Java limits painfully the set of abstractions you can express.

The one most painful issue for me (when I wrote Java) was function objects. Java makes using functions as arguments, variables, etc. very painful (not to mention Lisp or Python's ideas of constructing functions on the fly). C# delegates cover a whole lot of that ground. I read the articles on java.sun.com explaining why there will never be delegates in Java; they are nothing but hubris and NIH syndrome.

Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts. Now, go read Stroustroup about downcasts. In C++, there are exactly two situations where you really need downcasts:
1) you're interfacing with non-C++ code, sending pointers back and forth
2) A design error
This is because C++ supports proper type abstractions.
Then look at Python, Perl, JavaScript, or any other dynamic language: downcasts are not needed and make no sense.

So -- the most common operation (modulu assignment and method call) in Java is one that is not needed in dynamic languages, and indicative of a design error in proper static-typed languages.

Java forces one to repeat oneself, because it excludes important classes of abstractions. This is why it sucks, and why it is uncool.

Re:Because it is a limiting language

[graveyhead]

Man you are so full of shit I can't believe this post is modded +5 and no-one has responded.

First you say:

Java makes using functions as arguments, variables, etc. very painful

Yeah, and your point is? In case you didn't notice, passing functions as arguments does not make the worlds most legible / maintainable code. On the other hand, an explicit interface is both legible and maintainable, plus you have an explicit place for documenting the interface (Javadoc in the interface definition).

Then you go on to say:

Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts.

This is an implicit downcast:

class foo { ; }

class bar extends foo { ; }

foo f = new bar();

It compiles perfectly and works as expected.

The last line of this:

ArrayList l = new ArrayList();
l.append("A String");
String s = (String)l.item(0);

Is an upcast. and I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.

How such misinformed tripe ends up at +5, I'll never know...

Re:Java is slow, bulky, and mostly useless...

[smack.addict]

Applets (Java in your browser) make up a tiny minority of Java applications. I would be willing to bet less than 1%. Java is mostly used on the server where it is undoubtedly the best language for building applications (as long as you avoid EJBs).

Same reason as everything else

[Kohath]

Java is uncool because people are snobs. You can't think you're better than everyone else without thinking that the popular choices are beneath you.

Let me summarize the attitude:

I'm better than you. I'm one of the good ones, not one of the masses. Java? You still use that? I used to use that, but now I only program in the new super-trendy "Rubytalk" It's a Ruby-smalltalk hybrid, but I tweaked the compiler so none of the keywords are longer than 3 letters.

I have to go now. I have reservations at the new "Chittii" restaurant. I had to make them 3 months ago. All the food is vegan. You Java programmers probably eat at McDonald's and shop Walmart with the rest of the proles.

Bye. Oh, and tomorrow I'm taking the day off. PBS is running a six-part biography series on British showtunes composers. It's the only channel I watch.

Re:Java is unpractical!!!

[gwynevans]

And how much of the 3GB did you actually allocate to the JVM on startup? From memory, the default settings just allocate 64MB's memory...

Sounds like an ID:10-T error to me...

Re:Why, Perl, of course.

[sean23007]

HAHAHAHAHAHAHAHAHAHA.

Okay. Got that off my chest. But I should just point out that Python programmers can write the code as fast as anyone else. (It was kind of a main talking point for Paul Graham: great hackers like it because it communicates what they want to get done very quickly and with few lines.)

Re:Why, Python, of course.

[TeknoHog]

You can write PERL that is completely illegible, or you can write PERL that looks just like C++ with extra $, @, and % strewn about. It's all up to who is writing it and what coding standards they have to live up to (if any).

That's exactly the problem of Perl, having more than one way to do one thing. It's fine when you're the only one who reads your code. People tend to learn a subset of Perl that does everything. But what if you're collaborating with other people who know a different subset, and generally a different coding style?

Of course style can be enforced, like the Linux or GNU guidelines for writing C. But at that point you could just as well make the language itself clear and consistent, which is just what Python does.

The Pragmatic Program Inverse Theory

[kvnmcsc]

During the last 20 years that I've been a professional programmer I've developed a theory that says, the more practical an application will be to the larger masses, the less cool it is to programmers. A corollary being that the tools to create uncool applications will also be uncool.

Consider the coolest programming jobs: game developer, theoretical research and embedded missile guidance systems, etc...

Now consider: accounting applications, banking applications and word processors - arguably the most used, most common, most practical of applications - and low down on the programming pole.

And then there are the tools used to build those applications: at the top of the pole assembly, C, Perl; at the bottom: Java, Basic, C#. Again the uncool languages are associated with building uncool apps.

It's a simple as that.

Finally, the exception that proves the rule is operating systems. Linux being a perfect example of a cool thing to work on and eminently practical. I would argue however, that the OS is unseen by the masses. The translucent background against which applications are run, thereby exempting them from the theory.

Re:Maybe because it's slow ?

[molarmass192]

Solid post but I wouldn't say bounds checking is the primary reason why Java is "considered" slow. I think the blame rests squarely on Swing, not AWT, Swing. I primarily write console and server side code in Java and it's plenty fast (Java's console line buffer I/O is NOT cool ... but that's a whole other story). Swing has gotten better as of 1.4 with the switch to Java 2D, but it's still not responsive enough for some. With the renewed emphasis on desktop apps, hopefully the gap between Swing + Java 2D and native widgets will close even more. That aside, getting bad Java programmers to stop writting bad code is a whole aspect ... maybe a "Programming 101" enabled optimizer? :D

Re:Go write me an OS in Java

[IamTheRealMike]

An OS written in Java is the coolest thing, mostly because being safe you can do away with things like processes and IPC - huge swathes of infrastructure can be removed because there's no way a Java class can randomly puke over memory used by another app. Therefore, all you need are threads: the performance cost of switching address spaces, communicating using IPC and so on all just disappears.

It gets cooler. You can have very flexible and fine grained security - the Java type system has been mathematically proven sound, meaning that there's no way to subvert it (short of waiting for cosmic rays to flip bits, hah). That means you can limit the relationships between classes very easily: sorta like SELinux except more fine grained.

Basically an OS written entirely in a safe, managed language would be an awesome thing, the only problem being that it'll never happen as the huge quantities of code needed to make a good OS is all written in C! You could port it, but that'd be a lot of effort that isn't worth the gain.

That doesn't make the concept uncool though. A pure Java OS done right would be very cool indeed.

Re:Maybe because it's slow ?

[Cyberax]

JRE is about 7Mb.

Java Basher vs. Java Apologist

[RAMMS EIN]

I think the author could have done a much better job at debunking those myths. I, for one, am not convinced. Some snippets:

``you cannot really make your friends go ga-ga at amazingly brief programming constructs.''

Right. When you have to write BufferedReader in = new BufferedReader(new InputStreamReader(System.in)), that indeed doesn't give a strong sense of brevity. Nor does public static void main(String argv[]).

``Java has been considered slow for ages.''

And it's still slow. Each time a new release comes out, people get into the debate of Java is slow vs. you moron did you actually test that? Well, after 1.4 I have given up on testing. It's slower than unoptimized C for all programs I have tested with. Probably this is because I use the wrong kind of tests (ranging from simple loops and calculations to simple chat servers and clients), but just the fact that there are such wrong programs tells something, IMO. And startup time and memory usage continue to amaze me.

``Swing is a brilliant, although hard to learn, API.''

If it's hard to learn, what makes it brilliant? Certainly not its good performance or integration with the host environment. Themability and portability are good, but other toolkits have these, too.

``Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use.''

That's a fallacy. ML is also strongly typed, yet you don't have to tell the compiler the type you want to use.

``Java is popular. Anything that is popular has lost its elite status and therefore is not cool.''

You mean like Linux, Apache, Perl, PHP, gcc, etc. etc. etc. etc.?

Actually, now that I have read the full article, I don't think the author was trying to debunk any myths at all. More just summing up the points, so that those who want to defend/attack Java know where the battle is.

Mauve Was Cool In Its Day

[handy_vandal]

The reason Java is perceived as uncool is because they've got this horrible grey/violet default color scheme. Since when has violet been the color of cool? Exactly never.

In its day, mauve was all the rage:

In 1856, while trying to synthesize artificial quinine, 18-year-old chemistry student William Perkin instead produced a murky residue. Fifty years later, he described the event: he "was about to throw a certain residue away when I thought it might be interesting. The solution of it resulted in a strangely beautiful color." Perkin had stumbled across the world's first aniline dye, a color that became known as mauve.

"So what?" you might say. "A teenager invented a new color." As Simon Garfield admirably points out in Mauve, the color really did change the world. Before Perkin's discovery all the dyes and paints were colored by roots, leaves, insects, or, in the case of purple, mollusks. As a result, colors were inconsistent and unpredictably strong, often fading or washing out. Perkin found a dye that would always produce a uniform shade--and he pointed the way to other synthetic colors, thus revolutionizing the world of both dyemaking and fashion. Mauve became all the rage. Queen Victoria wore it to her daughter's wedding in 1858, and the highly influential Empress Eugénie decided the color matched her eyes. Soon, the streets of London erupted in what one wag called the "mauve measles."

Mauve had a much wider impact as well. By finding a commercial use for his discovery--much to the dismay of his teacher, the great August Hofmann, who believed there needed to be a separation between "pure" and "applied" science--Perkin inspired others to follow in his footsteps: "Ten years after Perkin's discovery of mauve, organic chemistry was perceived as being exciting, profitable, and of great practical use." The influx of bright young men all hoping to earn their fortunes through industrial applications of chemistry later brought significant advances in the fields of medicine, perfume, photography, and even explosives. Through it all, Garfield tells his story in clever, witty prose, turning this odd little tale into a very entertaining read.
--Sunny Delaney

Link

-kgj

Re:Maybe because it's slow ?

[nat5an]

I tend to agree with you. It seems intuitive that each interpreted virtual machine instruction would map to several instructions on the native processor (at the very least, since the virtual machine has to decode instructions in software, whereas the native processor can decode the instructions in hardware). Due to this increase in the number of instructions, the code would usually run slower. However, I do agree with the grandparent post that there is no theoretical proof which requires interpreted languages to use more instructions (hence more time) than natively compiled languages. It just seems logical and tends to hold most of the time.

There are lots of good reasons to use interpreted languages; they're easier to debug, they often have very powerful runtime environments, they're great for educational and research purposes. At the risk of short-circuiting the inevitable flamewar, certain languages are good for certain applications and there is no global measure of language "goodness."

Anger/distrust of liars, Sun-dependence, OS pain.

[dwheeler]

Some other reasons don't seem to get mentioned.

First, there's still anger and distrust of Sun. When Java first came out, Sun promised to help make Java a standard not solely controlled by any one vendor, and Sun started working with ECMA and ISO to make it so. IBM invested over $1billion with that understanding. Then Sun suddenly decided to take Java out of the standards process, and take complete control over Java. Yes, there's a "Java Community Process", but look at the process: if Sun doesn't like it, it's dead. Period. That's not an independence, it's a dictator model. And it's not necessarily benevolent; in an open source software project, you could fork the project if things went really badly (e.g., XFree86), but there's no mechanism for a true 'vote of no confidence' in the current process.

Fundamentally, developing in Java still primarily involves kneeling to Sun. We have lots of C and C++ compilers, with vendor-independent standards for them. Many other languages have standards, too. There's no need to return to a language totally controlled by any single vendor, that's a model from decades ago. Yes, there are other Java implementations, but not many; few others support the GUIs, and none support the massive library that's the primary point of using a language like Java. gcj does great stuff, but try compiling a normal Java program with Swing and other key libraries. C# is heavily controlled by Microsoft, and there are reasons to distrust that too, but at least Microsoft managed to release the language fundamentals to a more neutral party; why can't Sun exceed those low expectations?

And on most systems, implementing a Java system is a pain. It doesn't come with Microsoft, who's actively trying to kill it. It doesn't come with any purely open source software OS (Fedora, Debian, etc.), because it's not open source. This isn't a killing problem, but it does make development of Java applets essentially hopeless -- because it's quite likely that users will NOT have the necessary plug-in. You can do Java application development, and install the necessary libraries -- on servers that's not a big deal, but it's a little more painful on clients for client applications. But at that point Java enters a crowded field: there are LOTS of languages that can be used this way.

There's a lot to like about Java. But Sun has managed, through a series of missteps, to make a lot of people unhappy and avoid Java, even if Java would be a fine fit technically.

Re:Maybe because it's slow ?

[bruce_the_moose]

One word: Eclipse

IBM took a different tack than Microsoft, yes. They wrote an app that didn't suck and made it open source to boot.

Depends ...

[gstoddart]

In particular, Graham claims that terser languages are more powerful , because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

In my experience (which isn't huge with Java, but I've used it for commercial work), one of the things I liked most about Java was that it actually tended to save me lines of code.

Oh, sure it's got an explicit full-on syntax, but I'm comfortable with that. What I was most impressed with was there was a vast amount of standard data types and APIs available to accomplish a very huge amount of stuff. Looking at C++ and the like, the APIs are anything but cross-platform. (Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.)

For the type of code I was writing at the time (oddly enough, server side stuff behind a web front-end, no GUI) I found I could always find a standard routine to do what in the past I've had to implement from scratch.

I also specifically loved the good type checking and the like. I want that from my languages.

I'm actually planning on using it for some projects I want to work on for myself.

Would I say it's the perfect language? Nope. Would I claim it has all of the shiniest language features? Nope. Do I, as an old-school C-coder, think it's a straight-forward API rich language that I can get stuff done in? Damned straight!

Since I don't grok functional-programming and I despise languages with really wierd syntax and the like, for me, Java is like the Toyota Camry of languages. For the way I use it, it's fine.

Words from a programmer rather than a end user

[wolenczak]

This is why I really hate Java - Object casting and marshaling - Obnoxious try and catch structures for *EVERYTHING* - Int's can't evaluate to boolean - Native versus object typed numbers - Error, not warnings, on loss of precision - Lack of unsigned bytes - StackTrace mumbo jumbo - Compiler output is sometimes inacurate - CLASSPATH - Many others but these came top of my head

Re:Words from a programmer rather than a end user

[pomakis]

This is why I really hate Java - [...]

Some of the things in your list are valid gripes, but there are a few that I don't agree with. For example:

• "Int's can't evaluate to boolean" - So what? (a==0), (a!=0), is that so hard? I think good programmers generally do the expicit test like this anyways, even in languages like C.
• "StackTrace mumbo jumbo" - It's not mumbo jumbo. It tells you where the program fails and how it got there. Stack backtraces are a very powerful source of information for debugging. For programming languages like C you generally need external programs like gdb to provide this information. It comes for free with Java.
• "Compiler output is sometimes inacurate" - Is this really a problem with the language, or with bugs in the version of the compiler you're referring to?

Re:Words from a programmer rather than a end user

[BigGerman]

God bless you all.
I am glad that these are the only things the guy who truly hates Java can come up with ;-)

Eveything you listed is your friend, not enemy. Once you program for a while (and I mean 5,6,10 years), it will start coming to you.

Object casting
Often, downright ugly, this "feature" ensures that every object is what you think it is. You delegate all the checking to the compiler so you program, when it is incorrect, fails early, in fact, fails before it runs. Failing early is the sign of great code.

try and catch
Exception handling is a marvelous feature once you realize that from every situation there may be more than one (or two, ..) ways out. Using exceptions allows much cleaner separation of the "normal" logic and the "error" logic. Now, whether all the exceptions must be checked, or if C# model is better - is a different question.

int and boolean
Well, they are two completely different things, representing completely different animals in the real world. Why would you expect to be able to compare,assign, etc. apples to oranges?

native and object types
Tend to agree with you there.

Precision
Because IT IS an error when precesion is lost?

bytes
bytes are bytes and numbers are numbers.

stacktrace allows to pinpoint your runtime problems

classpath can be messy but it is precise: only stuff from classpath will be loaded by your program, nothing less, nothing more.

etc., got to go, do some uncool programming.

Why am I still hearing this?

[kahei]

Java is slow - This is a myth.

I honestly don't understand why people are still repeating this. It _is_ slower than either native C++ or .NET (MS implementation, don't know about Mono) for the vast majority of serious tasks (I am not including GUI stuff). It's all very well talking about how in theory HotSpot will optimize code beyond what a static C++ compiler can do, but the memory requirement of the Java program is typically so much greater that processing speed barely matters -- and it cannot be optimized, without a scary custom VM, because the app programmer has no direct control of it. I'm not just saying that for my health -- _look_ at Java memory footprints, _look_ at your options for reducing them (ie adjust the GC. Great.)

Java bytecode is not easy to optimize, having been originally intended for interpretation (my, how silly that seems now!). This is usually a minor issue compared to memory. I also suspect that, using the standard Java libs, IO is bound to be slower than a more direct approach unless the JVM takes some shortcuts and makes some methods into special cases. But actually, from the point of view of my actual work it doesn't matter what the reason is -- performance critical serious number crunching is done in C++, and that's pretty much a universal, because everyone relevant has made the same simple observations I have. This C++ can then be wrapped with a Java interface for the benefit of other systems that depend on Java and for people who only care about whether the system is Java or not (and so that it works with WebSphere now that the company is locked into WebSphere, heh heh).

So, _whyyyyyyy_ am I _stilllll_ told by posters on /. and people just out of university that "Java on Hotspot is theoretically faster than any compiled code!" I mean just stop it. Please. You are free to use Java. Java has many good points. Go use it and enjoy those good points and HUSH UP ABOUT HOTSPOT.

Re:Why am I still hearing this?

[Decaff]

Java bytecode is not easy to optimize, having been originally intended for interpretation

Hotspot does not optimize the java bytecode. It optimises the Java source (with techniques such as inlining and variable re-arrangement) and produces high-performance native code.

_look_ at Java memory footprints, _look_ at your options for reducing them (ie adjust the GC. Great.)

Java memory footprints can be very small - which is why it is favoured for use in many embedded systems. There are many options for reducing footprints, including run-time GC, stack and heap options and re-coding as a results of profiling, just as with any other language.

because everyone relevant has made the same simple observations I have.

Not true - there is a lot of work being put into Java numerics.

So, _whyyyyyyy_ am I _stilllll_ told by posters on /. and people just out of university that "Java on Hotspot is theoretically faster than any compiled code!" I mean just stop it.

Because in the experience of many of us, Java on Hotspot is not just theoretically faster, its actually faster, and we have benchmarked this with real examples. (IBMs VMs are particularly high performance).

Remember when C++ was 'slow'? I do. Almost anything written in it was declared to be memory hungry and sluggish. I remember the big fuss when major companies moved from assembler to C/C++ in the 80s. It was often stated that C++ could never be fast because of object orientation and because it could not be 'fine tuned' like assembler.

Seeing all the same old arguments with Java is just like Deja Vu all over again.

Re:Why am I still hearing this?

[Trinition]

performance critical serious number crunching is done in C++

OK, I'll bite. Give us an example, even the C++ source if you wish. I'll do my best to do it in Java and see what I can come up with. I'll even share it with the community to see if I've missed anything.

because your boss likes it.

[number6x]

Java is quickly becoming a de facto standard among management.

Some of the managers are technically savvy enough to realise that there is not much difference in choosing one language implementation over another. They choose Java because there are many programmers being taught Java at school. They are betting that should keep the labor pool large and the labor cost down in the long run.

These tech savvy managers know that python or curl is easier to write and maintain. They also know that other OO languages perform better, but they are adding the cost of staffing and outside support into their equations. They are projecting Java to become the next COBOL or C. None of them were 'perfect' coding languages, but they each dominated all other languages. What is technically 'best' is not always the 'winner' in the marketplace.It only needs to be good enough.

That said, most of the rest of the management (about the other 90%) likes the cool Java swag they got at the last convention. They think it makes them superior to wear it in first class while sipping cocktails and talking loudly on their cell phones about 'their' latest Java project implementation, and its overall downward effect on the cost ratios of delivering customer facing services, thus maximizing the returns for each level without jeopardizing the long term blah blah blah blah blah...

Bad article

[photon317]

Just like the last article slashdot linked from this source. For one, it's a straw-man argument. He gets to set up the 10 greivances that he'll knock down. How about he ask Paul for a list of 10 greivances to knock down? Secondly, the greivances he picks and his arguments against them clearly show that he's incapable of thinking in the way that people who despise java think, which makes him a poor arbiter of such things. Would a great hacker really say "Java sucks because it doesn't have a cool IDE like MS Visual Studio?"

rubbish

[animaal]

How can a language be un-cool? Could you call a hammer or a screwdriver "uncool"? And who'd listen to a guy wearing a beard, sandals, and white socks, getting red-in-the-face discussing the subtleties of static versus strongly-typed languages, deciding what's cool or uncool?

Programming languages exist to solve problems. Java happens to be among the best languages for mobile-phone apps (not the fastest, but very compatible), and scalable server-side apps. How can it be either cool or uncool? Personally, I wouldn't use Visual Basic to write production code, but I wouldn't call it uncool. It has its own niches.

Java still playing catch up with Smalltalk

[sideshow Pablo]

I know, I know, not another TOTL(The One True Language(tm)) comment.. but...

I'm amazed that how all of the current "state of the art" Languages/Frameworks still haven't caught up to Smalltalk yet.

Smalltalk is a Language/Library/ and integrated development environment all in one.

It's had for over twenty years:

1. multiple hardware support via Virtual machines,
2. garbage collection,
3. robust library,
4. Edit and continue debugging (the stack unwinds to the spot of the edit and it continues from there, once a coder experiences this, going back to pause, figure out problem, stop program fix, recompile and restart from the beginning sucks 'big time'),
5. Pure object based (everything including 'primates' is an object, at least how it appears to the programmer that is ;)and it makes it hard to write procederal code unlike Java/C++/C#, where it take coder discipline not to )
6. A good GUI framework (heck, it was used to invent Gui's),
7. Clean elegant language: 5 reserved words
8. Encouraged an iterative programming style( XP ).
9. And More...

Java/C#/.Net wish they had all of this "20 year old" tech. They are good Languages/tools that are slowly evolving into Smalltalk. Why don't you just save time and go to the top of the food chain?

It's amazing how one research lab, Xerox Parc, could have been SO far ahead of its time. Its like software has stood still for twenty years.

You can explore it via the open source squeak project. Understand it is written for coders by coders so it takes a little work to come up to speed on it, but in my option, well worth the effort. And Morphic just rocks. http://minnow.cc.gatech.edu/squeak/1

Re:Maybe because it's slow ?

[Glock27]

It's the startup time.

I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

You should try using Java apps compiled with gcj or one of the commercial traditional Java compilers. There's nothing set in stone that requires Java to be interpreted.

JRE 1.5 should help quite a bit also.

Great Programmers?

[Fujisawa Sensei]

Martin Fowler of Refactoring does Java.

Erich Gamma of Design Patterns is a major player on the Eclipse project.

Besides why should people consider a language cool at all? Shouldn't it be, "What I can do with a language" is considered cool?

Re:Great Programmers?

[the quick brown fox]

Guy Steele of Common Lisp: The Language and C: A Reference Manual and one of the creators of Scheme helped design Java.

(Although I think Martin Fowler's language of choice these days may be Ruby.)

Device drivers don't hit the Java "soft spot"

[argent]

About the only thing slower starting up than a Java app is a Java/Cocoa app. A Java device driver is initialised at boot time so you don't pay for the virtual machine creation every time you open it.

sponsored links..

[Suppafly]

Is it just me, or are there more sponsored links on that page than there is information.

I'm ok with people using ads to substidize content, but there are like 30 sponsored links surrounding the article.

SWT

[SlipJig]

All you people complaining about Java GUIs need to check out SWT. It's the GUI framework used for Eclipse. It's pretty fast, cross-platform, easy to program for*, and takes advantage of native widgets so your apps look like native ones. I also recommend this book on it if you're new to SWT as I am.

*You still need to use layout managers as in the other frameworks, but this is a given for cross-platform apps.

Java doesn't play nice with other children

[argent]

Let's see, here I am at a command line, I want to run a Java application. Any other compiled language compiles to a native executable that you run by typing its name. Java is just this random archive full of "stuff", and you have to use a "run" command like we were back in 1968 before Bell Labs invented the executable bit.

Here I am running a Java application. I type the command line to start it, and wait. And wait. And wait. And wait.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?

Java is like Mac OS used to be, its own little world and the only way to play is to leave everything else you've ever worked on behind.

Re:Java doesn't play nice with other children

[hikerhat]

Let's see, here I am at a command line, I want to run a Java application. Any other compiled language compiles to a native executable that you run by typing its name. ...
Compile in kernel support for misc binaries on linux. Read Documentation/binfmt_misc.txt to learn how to use it. Read Documentation/java.txt to learn how to use it with java. On any recent version of windows it works to just type the name of the jar file.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?
The first google hit - http://www.javaworld.com/javaworld/jw-05-2001/jw-0 511-legacy.html

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?
http://java.sun.com/docs/books/tutorial/native1.1/ It is really easy.

Re:Maybe because it's slow ?

[StillNeedMoreCoffee]

Well Java as I understand moves much of the optimization process down into the JVM whereas a compiled language like C++ does that optimization during compile time. Comparing the time I have spent waiting for C++ during the code, compile, run, code, compile run, I find I have wasted much more of my time. With the Caching of classes and dynamic inlining of code the JVM tunes up as you you go along.

You are correct that this model has a start up delay which can be seen as a problem if you do a lot of startups, but like many applicatons say a web server that starts a JVM and keeps it running while the server is up it is a one time charge. I find that given the saftey of the language especially around automatic garbage collection compared with C++ my envirionment is rock stable and the online Web apps we have only come down with the hardware needs maintenance.

The folks compainign about MS Java have a good complaint as that was an old buggy version of Java that has not been in general use for years by people using Java from the Sun source. The new versions of Java 1.4 ... current and 1.5 (Tiger) coming in a few months are light years ahead of that old MS version and should be looked at seriously.

I write my code on NT and W2k platforms (java 1.4.2) and field the same code on WNT W2k Sun Solaris with out modification and no changes for envirionments. With C++ or C# and the java clone this is impossible at this time. I have in the past had to field C++ code on different platforms and that was not a very nice time.

How do you want to spend your time. Collecting your own Garbage, writting very very carefully so you can use your code in different environments, or do you want to just get the job done right and once and get on with it?

#1 reason java is uncool....

[Kjella]

...is that if you don't program in Java, you've probably tried it. I know I've dabbled in everything from assembler, basic, visual basic, c, c++, java and various libraries/toolkits.

Java, by an order of magnitude, has the worst first impression of them all. Try writing "Hello world!" in a Swing window as your #1 tutorial. The start-up time, memory use and whatnot makes it seem like a dog.

Yes, I KNOW Java scales well to a large app, where it's not that relevant. That doesn't change the fact that if you dabbled in Java, and decided on something else as your language, your impression of it will be far less than stellar.

And you know how it is with every programmer telling you that "[MyLanguage] is the best", you'll think "Riiiiiiight. I tried it, not so buddy."

Kjella

Re:Maybe because it's slow ?

[Euphonious Coward]

It's not just because it's slow, but the reason it's slow (and Python, nominally 100x slower, isn't) is because of cache footprint. Java's garbage collector scatters storage all over as much address space as it can, so you get no effective locality. If your system ever swaps, it scatters its data all over the disk, too. That's why fake benchmarks always show it as "comparable to C++" (i.e. less than 3x slower) but experience shows you just sit and wait for a Java program.

But the reason it is uncool is because, outside of stuff written just for Java monkeys, there is no Free software to speak of written in it. Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%). Free Software coders have avoided Java for lots of reasons, including its not-really-portability, its bad performance, its hasty and stupid language and library design, its corporate 0wnedness, and their own resistance to hype and idiotic jargon.

Java killed Freenet in the crib.

Re:Java is unpractical!!!

[Anonymous Coward]

Not only do they do have to do this, but usually it's achieved by setting a custom "Java runtime parameters" string, it's not even as if you can type it into a little text box. Worse still, it's only centralised and "easy to find" (ha!) for the Java Plug-In: if you want to set options for .jars, it becomes a PITA.

And the "developer that creates scripts of executable that start the application" is essentially implementing a hack to get around this problem, not solving it. Java is supposed to be cross platform remember? You're supposed to be able to run a ".jar" bundle without setting custom options, remember?

Re:Maybe because it's slow ?

[markbthomas]

It can, in theory, be faster. Sometimes you discover data that turns out to be constant in the end, but you don't know this until your program is running. A JITter can use this additional information to compile to machine code that is a lot simpler and therefore faster. If you then execute this piece of code lots of times, you can earn back the time spent compiling and then start to profit from it. I remember some work being done into some research which did this in C: it generated some C based on a template, fork()-exec()ed gcc to compile it to a shared library, dlopen()ed the shared library and then ran the code. Of course, you had to do this explicitly, but I think since the chances of actually having an algorithm that benefits from this is pretty rare, that's not going to be a problem.

That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.

Also, it's not a case of interpreted languages not being cool. Perl, Python and a myriad of other languages are all interpreted (or run as some kind of byte-code), and no-one complains. Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language. If you've seen how JVMs work internally, I think you'll agree with me.

Re:Maybe because it's slow ?

[SkyWalk423]

System.gc() suggests running garbage collection, doesn't force.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc()

Masses? hat Masses?

[reallocate]

>>"Visual Basic was meant to be easy, for the masses"

First, there's nothing wrong with a language being easy to learn and easy to use. Power and ease of use are not mutally exclusive.

Second, what's with this stuff about languages "for the masses"? VB programmers are programmers. No one's running down to the local curb store for a loaf a bread and a $400 box of VB.net. MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?

Re:Depends ...

[Saucepan]

Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.

C++ has been around so long that by now there are jillions (possibly even hojillions) of C++ libraries/frameworks/APIs. Since you say you don't need a GUI kit, and assuming you are doing server programming, you might find ACE helpful.

I used ACE for a previous multithreaded server and the project was very successful. We developed on Linux and FreeBSD but had no difficulty porting to Solaris, and could have ported to Windows with a couple of days of effort (we had use the occasional POSIX-specific idiom, but this was our own fault, not the toolkit).

The author, Douglas Schmidt, is a well-known standards wonk and performance freak -- an interesting combination that results in a kit that provides full cross-platform support while running hard with C++'s approach of "you don't pay for it if you don't use it." The kit included a full CORBA ORB that supported realtime operation (ie, bounded maximum delay).

Probably the best compliment I ever heard about ACE was a from a very senior coworker who commented that ACE was "not bad, for C++." Trust me -- from him, that was high, high praise.

Having said all that, when I have to share the tree with other developers, Java is my favorite mainstream language.

Re:security

[Sj0]

The problem with your argument is that some people refuse to be educated. Hell, the biggest software company in the world is putting tons of money into educating their programmers, and after a couple years, there haven't been any appreciable gains(actually, since hackers have had that much more time to study, there have been extraordinary losses in the security department)!

Re:Maybe because it's slow ?

[seti32]

Eclipse itself was written in Java. From the Eclipse website:

The Eclipse Platform is written in the Java language...

Re:Maybe because it's slow ?

[freedom_india]

Are you serious? or have you never worked in an enterprise scenario?

Java is used in MANY thousands of enterprise applications at Server-side. Why do you think WebLogic, WAS 4.0 and even OC4J sell so much?

Java is manna for banking industry.

Why I Dislike Java

[Prien715]

My dislike of Java has nothing to do with slowness. It has to do with control and succinctness. Trivial example:

// Must be stored in a file called "hello.java"
public class hello {
static public void main(String[] argv) {
System.out.println("Hello world!");
}
}

Since everyone likes readability, I'd like to ask what part of "static public void" helps you to understand the program. Let's compare this to, oh say Perl.

print "Hello World\n";

Which, as Perl's reputation precedes it, is obviously harder to understand.

Javs relies on vast ammounts of knowledge drilled into the heads of students. If the OO paradigm wasn't so popular, Java would be entirely obtuse. Anything not memorized must be looked up. You wanted to add that integer to the float? Too bad. Go look it up type converting. Additionally I'd like to conjecture that the human mind is better at remembering small things than large ones. Therefore, system.out.println() is more difficult to remember than print. I'd rather remember something like "-e" (Perl) to test for file existance, than the Java equivalent, which I have looked up and since forgotten (though I've used each the same number of times).

While C may be verbose, it allows you to have near complete control of the physical operations of the hardware (e.g. when you delete memory or use a pointer, this has a physical analogue).

Java is both verbose (lots of commands to do simple stuff), clunky (really long commands), and forces you to use the OO paradigm whether or not the problem demands it. It's these reasons why I dislike it.

Re:Why I Dislike Java

[Capt_Troy]

Your sample just goes to prove that java and perl may not be suited for the same tasks (which everyone already knows). Comparing languages is pointless, it's like comparing a fork and a spoon. Forks are good for steak, spoons are good for soup.

I use Perl when I have a task suited for Perl, Java when it better suits a task.

I do agree that it's difficult to do some simple things in Java... I personally feel that it's benifits outweigh it's detractions in most cases though.

Re:Why I Dislike Java

[MemoryDragon]

My dear friend, this is easy to answer. The reason why your hello world is as verbose at it is, is that java in the core is OO (not really pure thanks to the hack... core datatypes and operators, but pure enough, that the example is justified as it is)

Perl on the other hand is in its core procedural, like C++ has a procedural core.

Perl is not harder to understand, but the main problem of the language simply is, that it has so many shortcuts to problems that you easily end in a mess of shortcuts, ditto for C++

Java basically sacrifices some of those shortcuts for the sake of readability. What in the end comes out, is probably 10-15% more locs but much more readability and less bugs.

Well if you go for the fast hack this approach might not be the best, but if you have to design huge software systems, are more readable approach which some security nets builtin is heavens sent.

Now if we go to Python, python developers always claim less code, but I did a few things with Python, and the less code approach is more or less not justified, the class libs of this language arent too far off the ones java and C# use, and the only code reduction i could see was to use inlining instead of brackets for block signing (which is a matter of taste but saves a few lines per class, not very much) and the non declarative character which removes you of the responsibility of having to declare a variabe.

The non declarative approach maybe in the long term saves around 1-2% of code, but causes lots if trouble regarding typos in variable names, idiotic assignments and so on, which have to be covered by unit tests, which add another 15% to the code, to reach the same stability.

So non talkativity in large systems is a question on how fast you can achieve an elegant decent result, and often non talkative languages with shortcuts, prove to be worse solutions for middle sized and large systems, than ones which look on the first sight not that elegant.

Ugh

[That's Unpossible!]

You mean you own a TV?

Re:Masses? hat Masses?

[kisrael]

First, there's nothing wrong with a language being easy to learn and easy to use. Power and ease of use are not mutally exclusive.

True. But sometimes "ease of use" runs into "quick and dirty", and all the difficulty in maintaining and extending that that implies. VB and Perl lend themselves to quick and dirty and require more self-discipline to stay well-engineered. Java usually pushes you to more forethought, and while crap code is certainly possible, it's somewhat less likely.

Second, what's with this stuff about languages "for the masses"? VB programmers are programmers. No one's running down to the local curb store for a loaf a bread and a $400 box of VB.net. MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?

Yes, currently VB is just another language.

But I grew up with built-in BASICS, and when I got introduced to it, VB3 seemed to be positioned in a similar role. I got a student edition for cheap and had a lot of fun.

As for the "for the masses", that could also be "for the non-techie, business-knowledge people in your company". I don't know if VB (especially the Office-centric versions) still do that well or not.

I do think that we who grew up with computers that booted into BASIC have an edge over people who get the start button. Making goofy, kiddie programs had a much lower barrier to entry back then...now it's almost certain you'll have to install something, or go nuts with the Javascript.

the real reason

[pchan-]

here is the REAL reason hackers don't like java, and most of them don't even realize it.

the job of an organization developing a software product (whether it's a company, an open source team, whatever), is to get a product out. nobody outside the project cares about languages or anything else, as long as it all works in the end. but to get a product out, the manager eventually has to pick a strategy. they usually fall somewhere in between the two extremes:
A) use a few brilliant (possibly well paid) hackers and let them do the work. they're smart, and good enough to rely on to just do it. managing them is like herding cats, but why would you need to?
B) use an army of keyboard monkeys and manage the hell out of them. these guys can pound out mediocre code, but with enough software engineering from the top down, well defined specs, and massive testing and integration, their work is sieved into a release-quality product.

real hackers hate being marginalized, having their creativity stifled (yes, for those of us who actually write code, not just implement specs, creativity is involved), having to do the dumb solution just because everyone else is too weak to do their part of the smart solution.

java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for.

perl, a RAD (and rad) programming language, does not suffer this stigma. perl is accepted by hackers, precisely because it is not idiot proof. it's easy to confuse the B coders (and yourself) with some maliciously written ascii barf. you can do some crazy tricks in perl. it does not lend itself well to software engineering and the micromanagement of the B coders. perl is a hacker's language.

many real hackers i've seen instinctively feel resentment towards java and the like, because they see marginalization of the software industry. java is for the blue collar coders, part of the greater plan of "software factories", where reproducability, meeting deadlines and specs, and easy replacement of people is way more important than doing cool shit. those of us who wish to stay at the top of the game, to do the cool shit, to write the programs that interest us the right way are often drawn to the languages that keep out the idiots, that have a higher barrier of entry, and let us do the cool hacks.

i don't dislike java, and i don't dislike you B coders out there (you know who you are). i just don't want to be one of you.

thanks for reading my long-ass post,
p.

Re:the real reason

[fakeplasticusername]

I understand your point, but i would have to disagree. Partially.

I am a java coder. I consider C/C++ a knowledge based coding language. If you take your time to learn all the tricks of the trade in C, you will probably be a better coder than I am. Java isn't as tricky of a language, most everything you need is in the javadocs.

I can gaurantee you that the C++ master would write cleaner code than the casual java coder, and probably even better than the java master, the difference being the java coder doesn't have to know every nook and cranny of the coding language to write a good program. I would never presume to call the C++ programmer more intelligent than the java programmer, merely more knowledgable and likely more passionate.

I personally don't use java with the desire to become a java guru or a programming master, i just want to write software that works, and i don't want to spend a great deal of time doing it. I don't program for the joy of programming, i program for the joy of solving a problem. The amazing thing about java is that it gives the ability to write software to just about anyone. Yes there are B coders in java, but many of them are A engineers who see coding as a means to an end, not the end itself. Whether they can write good software or not is a function of their intelligence, in my opinion, not of their language choice.

Re:the real reason

[BigLinuxGuy]

The saddest statement is that great code [in whatever language] still ends up being crap if it's based on bad (or missing) requirements and a lousy design. Unfortunately, most coders are not good are requirements or design because they want to focus on the code for the instant gratification. It's even more poignant when application developers suddenly think that they are enterprise application developers by virtue of using a toolkit or spec that has the word "enterprise" in it. Far too often the desktop application programmer mentality becomes apparent when so-called enterprise applications require the resources of an entire server for a single application (and frequently a cluster of those servers).

I've sort of given up on common sense coming to bear because of the "just buy more/larger servers" or "drop in more RAM" mentality that is far too common in the industry these days. So let's hope that Moore's Law doesn't slow down any time soon because all of these "advanced" enterprise applications will need all the help they can get.

Re:the real reason

[BigLinuxGuy]

Interesting post. My observation is similar, in that management has been trying to do away with the need for developers for at least the last 20 years or at least commoditize them (see tools like PowerBuilder or Visual Basic). Is this a bad thing? Well, as you note, it allows less-skilled workers to be successful (to a degree). However, you often get what you pay for (see another "rant" on my part in this chain).

Realistically, hackers like to think of themselves as outsiders to a degree because that's how they measure their "coolness", i.e., by their code kung fu. Well-established languages with visual paradigms, such as VB and now Java, become increasingly looked upon as children's toys.

To balance things, Java is a very clean language that builds on the footsteps of its predecessors. However, the frequency of change and the size of the required virtual machine (and its resource demands) may make it less desirable for some projects.

For most of the things I do, Perl, Python, PHP, and occasionally Tcl/Tk are more than adequate. I'll go to C or C++ if I need more speed and FORTRAN 77 if I need all the speed I can get. But I guess being multi-lingual is too much of a strain for what you characterize as "B" coders. ;-)

Re:the real reason

[delete]

You sound rather bitter. Is it perhaps because you have found that real companies actually like to meet deadlines and produce reliable software in a structured manner, rather than letting "A coders" (based on whatever ad-hoc criteria you use) like you waste time doing some "cool hacks"?

I would certainly argue that the ability to understand complex problems and implement novel solutions is what separates good coders from those who might be more suited to other jobs. However, surely "doing cool shit" does not depend on your choice of language, but on the individual. If you're unable to do that in Java, is it really the language's fault? Do you believe that no developer is capable of originality or creativity merely because they use Java as their primary language?

The level of language bigotry in this thread is amazing. Ironically it was Paul Graham, the champion of oft-rediculed language, who started this discussion.

Re:the real reason

[TheLastUser]

Typical anti-Java bunk. You forgot the "Java is slow" comment by the way.

The truth is that there are B coders that write C and perl too. It really doesn't matter what tool you give a B coder, you still don't end up with A material.

In our shop, we code in both C++ and Java. Nobody upstairs tells us what to use, we even use a bit of perl now and then. Most of our stuff gets written in Java. Simply because its vastly easier than to do it in C. Java has a really fantastic set of libraries that allows very complex applications to be written easily. This lets us concentrate on producing a kick-ass product, instead of fiddling with memory allocation, etc.

For web applications, C and Perl are less than useless. Java app servers are so far beyond apache/modperl that the comparison is a joke.

As a C bigot and part time anti-Java stooge, I am sure that your inane construct of the A and B coders serves you well. It must be very satisfying to produce a bunch of C that does next to nothing, in between seg faults, and say to yourself, "This is a masterpiece and I am a god".

What we do in a month, you couldn't do in a year, and that, my friend, is why your shitty language of choice is headed the way of Ada.

Re:the real reason

[Anonymous Coward]

It is good that you don't want to work for hte big software shops, as it would never happen. Let me give you a manager's persepctive on why "cool hackers" are not desireable as hires; you just listed all the reasons why I would never, ever hire you in a million years to work on my major financial system.

1. You think you are too smart to work from a spec. Implementing a spec does not leave no room for creative solutions to problems. It just guarantees that you won't be a typical "midnight cowboy" loner who programs an 31337 solution that does not actually meet the requirements of the users. I will take someone who can solidly do the work I need done over a genius who gives me a creative app that fails to implement the spec any day of the week. And I will have more confindence in the B coder who I know is not a prima donna.
2. You look down on the concepts of testing and integration. Imagine 40% of financial derivative deals in the world financial market suddenly unable to be valued and executed for a day, a week, a month - that is what happens if my system goes down. If an appliation outage means potential damage to the company and a noticeable impact to the world financial market, testing is not just a good idea. It is everything. Hell, yeah, I manage the hell out of my team. I don't sit at their desks and micromanage them, though, and you seem to think that the former implies the latter. I just make damned sure that everything we do is extremely well-tested, lest we cost the bank millions of dollars with a simple error.
3. You actually think "cool" matters. There are places where this is true, such as perhaps game companies. But my own time in the candyland of the late 90s boom showed me that coolness is not nearly as important as delivery and reliability. You may deliver good, cool code, but as a manager I am not at all sure I can rely on you unless I coddle you and keep you happy.
4.You have disdain for your potential teammates. I will never hire an "A" programmer if that means getting someone with your attitude. Instead I will hire what you call "B" programmers (many of them extremely bright people at the top of their field). I will treat them with respect and empower them to make their own decisions as much as possible. And day to day I will worry much less about them than you because you come off as an arrogant ass who thinks highly of himself and cannot work with others.

Enjoy your work on the "big" apps with the other A programmers. Those of us who build software that keeps the world running have other things to do.

Re:the real reason

[I_Love_Pocky!]

No one has responded to the real problem with this post. You seem to come at this like programming is some kind of difficult feat. I don't care what programming language you use, you are not special because you can program.

The only real interesting problems in software are in the design. A programming language is just a means to an end. I don't care what you program in, all programming is grunt work. It can be fun at times, but it isn't an intellectual challenge.

So, to put it plainly: Get over yourself. If it makes you feel better to produce all your apps in something with a high barrier to entry like assembly, feel free. It doesn't guarantee that they will be better though. If you pick the wrong algorithms/data structures/architecture, even the most bloated high level language could out perform your low level code.

The bottom line is that Java is an excellent language for certain applications. If you are so intelligent that it bruises your pride to use Java, then what the hell are you doing as a grunt programmer anyway?

Re:Maybe because it's slow ?

[sploxx]

First of all, Java!=JVM. Please make this distinction. I won't discuss the pros and cons of Java as a language here, just the JVM. You can use gcj to GNU-compile Java and you'll get very close to the performance of GNU-compiled C++ which is what one would expect. Note that I said GNU-compiled because there still commercial compilers which produce better code, in terms of execution speed. [Of course, I hope GCC will overtake them, but that's an unrelated issue :)]

Mod me troll flamebait, whatever - but the JVM is slow, not only on start up.

The empirical argument
IMHO, todays average real world JVM app *is* slower than the average real world compiled app. And, no, I do not talk about the startup time only. GUI code is slow. Network/File I/O is slow. Show me a JVM app (app, not test case!) with a native compiled equivalent which is slower. You won't find any.

MAYBE there is the *theoretical possibility* of JIT being faster than compiled/hand optimized assembly code. But this is purely theoretical. I have yet to see real world apps and not some made-up testcases with matching peephole optimizations for a particular architecture where this is the case. There are still uneccessary virtual method calls, wasted stack space etc. in JIT code.

The theoretical argument, mixed with personal opinion :)
Doing JIT with JVM code involves steps very similar to decompilation [JVM->IntermediateCode->Target] because in JVM code, no information about higher-level structure is preserved. This reconstruction is computationally very expensive (google: decompilation problems) so only approximative algorithms are used, leading to non-optimal code. There are reasons why e.g. the ANDF format preserves much more information than JVM code.

A possible solution
I think LLVM is a nice project that could bring all the VM hype of Java to C/C++/CommonLisp/Perl/Python/BiglooScheme etc. And Java!
Sure LLVM still lacks many things, the VM code isn't much more descriptive than JVM code etc. But it is independent, and it is growing. An LLVM applet plugin for Mozilla would be nice :)

This is also a partly political thing. Why do FLOSS Java developers accept the fact that Java and JVM are so tightly coupled? Maybe this helps Sun's goals (to spread the platform Java) but technically, it is clearly an inferiour solution.

Re:Depends ...

[Haeleth]

If you want all the nice Java libraries, strong static type-checking, and compilation to JVM bytecode, why not try Nice or Scala? Both provide everything Java has, including the ability just to use arbitrary Java classes and APIs completely transparently - and they add many of the best features of functional programming, and have terser syntaxes than Java too.

Worth considering, anyway.

Site error

[Ifni]

From the article link in question:

Server Error
The server encountered an internal error and was unable to complete your request.
Could not connect to JRun Server.

Obviously, the Slashdot effect has brought pretty much every language to its knees and depends more on the hardware than the language the app is written on, but when the server hosting a page defending a language is itself run on that language and generating errors, it makes me laugh.

In all seriousness, on problem I have with Java as an end user is that many Java apps seem to be coded to a specific version of the JVM such that even subreleases from the same major (or even minor) version of the JVM will cause the app to not run. Ciscoworks is one of these. It drives me nuts havibg to have 2 or 3 versions of the JVM on every computer I use simply because one Java app or another is REALLY finicky. I don't know if this is a problem of Java attracting/creating bad programmers (as posited in the article this story is responding to) or if the JVM developers have no interest in backwards compatibility.

Other than that issue, I, as an end user, think Java is great. But then again, I program mostly in PHP or (*gasp*) Visual Basic (including VBA and VBScript), so I'm not really qualified to discuss what languages are a "real man's" language.

Uncool! I must not have gotten that memo.

[rben]

I guess I'll never make anyones list of greatest programmers, but I think Java is plenty cool, especially with some of the recent changes. Java has gone from being a trivial scripting language that was primarily useful for animating pictures on the web to a very powerful language that can occasionally outperform C++, especially on web appliations.

Java is far easier to learn than C++. While Java does not provide all the flexibility of C++, most of the time I don't need to be able to write code that interacts directly with the hardware.

The days of managing memory by hand should have become a distant memory for all but a handful of programmers long ago. Memory management bugs are among the most common and difficult bugs to fix.

When I first started programming Assembler programmers made all the same comments about us "sissy" C programmers that the C++ programmers make about programmers in Java and other memory managed languages. There aren't so many assembly language programmers around these days...

Java is slow - so what?

[kelleher]

People are slower and more expensive. Hardware gets faster and cheaper every year.

Anyone who has worked with budgets in large corporations can tell you Developer/Tester hours are generally the majority of the budget. Hardware is a drop in the bucket (and you can even capitalize it). On many projects I've worked on, Java has driven the people cost down resultig in a net savings even though we may have had to throw a crap load (official Business terminology) of CPU/memory at the application.

Re:Depends ...

[stormcoder]

Open source cross platform C++ libraries include Boost, ACE, STLSoft, and Loki to name a few.

You should give Python a try as well.

MOD PARENT UP

[rudeboy1]

Nice post. +5 insightful if I had the points to give. I fully agree that Java is a great language if you don't want to put your higher thought processes to work. You can get away with looking at a spec sheet and punching out a "plug in the code to meet the specs" scenario. There is no, "let's Make A and B work, and in doing so, supercede the need to put in C" and make it better, with less code, better reliability, and less common errors.

Re:security

[Fooby]

An optimizing compiler can in many cases figure out the static cases where bound-checking is unnecessary and omit them. If a programmer is intelligent enough to write secure code in C, s/he should be intelligent enough to write fast code in Java. I'm not saying that Java is a perfect hacker language, but I am saying that C is not a modern language and not the best choice for most large applications. There's no reason in this day and age that an applications programmer should have to be constantly piddling over things like memory management in their code when garbage collection can be done by the compiler.

Because Java Programms are lousy C++ Programmers

[deischi]

This is not really about Javas coolness or not (could not even read the article).

To my experience when Java programmers switch to C++ they tend to produce code that is full of memory leaks (new in Java and C++ are VERY different) and have a tendency to write overdesigned and unnecessary complex code.

What you will always see from a person done Java in the past and now doing C++ is things like:

DoSomething() {
C * c = new C();
if( ! C->doSomething() )
return;
C->doMore();
delete c;
}

Harald

Re:Maybe because it's slow ?

[barawn]

There is *no* way that a interpreted or JIT compiled language can be *faster* than native code.

Nope.

There are actually quite a few ways that an interpreted language can be faster than native code.

If you were right, then VLIW processors would've taken over long, long ago.

It's important to realize that the instruction set that any processor uses is not its native instruction set, for a long time now. Ever since the Pentium days, there's a "instruction decode" step in the pipeline, and even PPCs use it to pare down the (comparatively simpler) PPC instruction set to something more RISC-like.

So what does this have to do with programming languages, you might ask?

The point is that the analogy is exactly the same: VLIW processors rely on the instruction stream being very parallel, and well tuned to the architecture so that they can be very simple and very fast. There's only one problem - compilers can't be that smart. You don't have all the information until the program runs - this is very similar to the Halting problem. Until the program runs, you don't know how it will behave.

So what you're saying is "I don't see how an interpreted language can be faster than native code", likely because of the overhead. The answer to your "how" is that the interpreter - like any modern x86 computer - has more information available to it while its running than the compiler had when the program was compiled. Therefore the possibility exists that an interpreted language can outperform native code, because it can optimize for cases that the native code cannot. If that optimization is enough of an improvement over the overhead, you win.

It is for this reason that modern x86 computers perform so well compared to VLIW architectures - it's very difficult to extract parallelism from the code itself, before it's executed. It's actually more efficient to extract the parallelism while the code is actually running.

This is the exact same reason why Java can beat C++, in certain cases. And for benchmarks, http://cpp.student.utwente.nl/benchmark/. Note that this is in fact someone improving upon a C++ vs Java benchmark that showed Java won, so this is C++ striving as hard as it can.

Here you can see that for certain cases, Java can win. The most notable one is the nested-loop benchmark, where the Intel C++ compiler ran in 1.8 seconds, and the Java example ran at 1.05 seconds.

Your next statement might be that "yes, but in assembly..." and I will then say that yes, I highly doubt that you can find a Java program that will beat a hand-assembled piece of code. But it still is *possible*, because the interpreter may be able to perform some optimization during runtime that the person doing the coding can't because it's not strictly correct - this is akin to a branch predictor in hardware. It's allowed to cheat so long as it's later proved that it was right, but then pay a penalty when it's wrong.

Java programmers cool, Java sucks…

[Naum]

... Java is a tool, and in the hands of any gifted programmer, it can be used to craft quality software.

Java, the language, sucks, but yet has made huge inroads into commercial realms, supplanting COBOL and other languages as the language of choice for business applications. And it's a shame, as there are loads of shortcomings, that offset the advantages of Java and the JVM deal:

• Sun's dictatorial control of standards as has been previously detailed. I believe it's the Win/Unix client/server setups that influences decision to develop in Java, both for business software units and third party software vendors selling wares to such customers. In *nix-less shops, .net or whatever the Micro$oft platform dujour is called these days, and Java may not flourish there.
  
  
• Too resource intensive. Running a mini-OS VM on top of another OS is never going to be a performance maven. Java applications on both client and server suck in this regard. Huge memory footprint, excessive startup/load times, and measurable delays in graphic intensive applications plague this beast bad.
  
  
• Serious issues with threading prevent it from serving for any serious server workhorse. No doubt, talented engineers are still trying to crack this nut, but threaded Java applications pushing large chunks of data about are very susceptable to insidious behavoir, depending on the machine architecture and other system software instances mix.
  
  
• The natural handicaps built into the language, that can make for inelegant and unflexible solutions. Say what can be said about Perl, Python, C, Lisp, etc., but those tools are remarkably more expandable and resilient when it comes to possible solution spaces. Also, forcing one to treat everything as an object, as has been written by others, is a limitation, not a benefit.

But the programmer != the tool. It might make it more difficult, or more lines of code, or more kluginess, but a talented codesmith can work with primitive tools too.

Re:Depends ...

[Skjellifetti]

assuming you are doing server programming, you might find ACE helpful.

2nd that. I've used ACE on Winnt, Solaris, HP/UX 10.20 and 11, and Linux. I'd also recommend reading Schmidt's various papers on design patterns. Many of these are implemented in ACE and greatly cut down on design/coding time as well as bugs in the code.

Ever encounter LD_LIBRARY_PATH?

[bharlan]

LD_LIBRARY_PATH isn't any better. Yes, you can specify directories, but you must instead name each shared object when you link.

Yes, you can use /etc/ld.so.conf for common shared objects. You can equivalently use $JAVA_HOME/jre/lib/ext for common jars.

Using a path is the single most common way to find dynamically loaded code.

Top reasons why Java *is* cool...

[eyefish]

OK, so here's my list why Java *is* cool and is used by great programmers:

1. It runs everywhere unmodified. This has got to be the coolest thing of all, and the reason I adopted Java in the first place. At the beginning this was not always true, due in major part to the AWT graphics libraries, but today it is.

2. It's more productive to work with it, leading to fewer bugs. This is very important in business apps. I certainly no longer get C/C++ pointer problems, memory leaks, or perl syntax error problems.

3. It is fast (ok, it loads slow the very first time, but with JDK1.5 this seems to being addressed as well). Somehow Java lends itself so easily for users to write efficient code (i.e.: multithreading is a snap and platform-independent), that somehow the applications we've been replacing with it simply run at least twice as fast as the older C++, VB, and perl apps.

4. It is simple. Sure, some hackers like garbage-looking code because they think the harder to understand their code the cooler it is, but in my book the cleaner and simpler code wins any day, specially when programming in a team environment. I think Java should be given credit as the environment that brough simplicity back to programmers in the internet age (just as VB did in the client-server day).

5. You can use multiple tools to develop the same code base. Heck, and now with ANT (possibly one of the coolest tools in recent times) you can choose your IDE (or command-line if that's your thing) and move the project back-and-forth between IDEs to take advantage of each (GUI design, refactoring, etc). Choice is a good thing.

6. I'll repeat it again: How cool is it to develop in Windows and drop the app unmodified in Linux or OS/X and see it run as expected with NO changes to the code? Or if you prefer, develop in Linux and deploy in Windows. Either way it works.

7. It is standard. Sure, it is not open source but then again not everything has to be. I think the fact that open sourcers advocate freedom should be reason enough to allow other companies to choose if they want to free their software or not. It is their choice. The fact that it is standard means that Java is protected from the "Unix division plage" where now almost no Unix is compatible with any other Unix. Geez, even Linux is starting to become incompatible with all the different versions of itself. Sometimes centralized control is a good thing.

Re:Depends ...

[jarkun]

Java vs C/C++ is the wrong comparison!

C/C++ is great for embedded work, its the perfect abstraction for what you do in assembly, but this isn't what the "cool hackers" are doing these days.

They are doing higher-level applications with more abstraction. At this level Python/Perl/Php are extremely flexible/powerful/easy to use.

Before you drive your camry make sure you check out the saturns :-)

Re:Maybe because it's slow ?

[Hulfs]

But the reason it is uncool is because, outside of stuff written just for Java monkeys, there is no Free software to speak of written in it. Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%). Free Software coders have avoided Java for lots of reasons, including its not-really-portability, its bad performance, its hasty and stupid language and library design, its corporate 0wnedness, and their own resistance to hype and idiotic jargon.

Are you flipping crazy (or trolling)?! Go to freshmeat.net, browse to the projects by programming language, and look at the number of projects writting in java (currently 3257, about what C++ is at). Are you telling me and everyone else that every one of those projects are both non-free and solely written for "Java monkeys"? What a total load (as are your "statisics").

Re:Maybe because it's slow ?

[orangesquid]

Yep. The Cray C compiler is this huge, slow, stinking mass of algorithms designed to figure out what high-level process (sorting, matrix multiplication, etc.) you're trying to write in medium-level C code, and then it drops in fine-tuned assembler code and makes a few substitutions, and, voila, your app runs on a multiprocessor supercomputer.

There's no reason a very well-engineered language aimed at solving the majority of common computer problems very well couldn't have a syntax where the compiler always knew what the programmer was trying to do, and could simply spit out bytecode corresponding to the different abstract steps that the program goes through; the interpreter would execute highly-optimized native routines, and this setup would easily outperform standard compilers for most tasks.

Of course, designing these types of programming systems is very difficult, indeed... but, to some extent, it *has* been done, there just aren't very many options yet...

Damn straight!

[Tony]

Besides, success is its own argument. If you can't understand why Java is so big these days, maybe that's your fault, and not the world's.

How true!

And the same goes for Budweiser, McDonalds, the Ford Escort, and reality TV, as well. Who cares if they are good or anything; they are popular.

State in Functional Programs

[MenTaLguY]

Use e.g. monads or "single-use" values.

Single-use values are used to represent the parts of the outside world that can change -- when, say, inserting a record into the database, you pass a value representing the database to the "insert" function, and it returns a value representing the modified database, and invalidating the previous "database" value.

Arguably the invalidation of the old value is still a side-effect, though, and it's still somewhat awkward to use.

Monads approach things the other way around, permitting you to set up purely functional "pipelines" through which state will be passed at runtime (but the state-passing need never be explicitly exposed, and in the pure sense cannot be).

Monads work very well, and maintain purity (without having to pass extra arguments around everywhere), but they're very, very mind-bending to think about until you get accustomed to them.

There are also other monad-like approaches (e.g. "arrows") which are possibly better, but this is an area that's still being actively researched.

So, it's possible today, but really it's an issue computer scientists have only recently started to experiment with in earnest; I expect we will have even better approaches for managing state in functional programs in the next few decades.

Cool things about Java

[akuzi]

I think Java is most seen as uncool because it's simple (or atleast the complexity is pushed into the APIs) and it's used mostly for enterprise development that traditionally COBOL was used for, and not for desktop apps and systems programming (not that you can't do these in Java).

It does have some redeeming features tho (it certaining is a better COBOL than COBOL!)

1) Java has absolutely the best programming tools out there

There is nothing out there that touches the Java IDEs such as Eclipse and Intellij. Some of the advanced features they provide like intelligent code completion and some of the refactoring support are impossible to do with weakly typed languages such as Perl or Python, and very difficult to do with natively compiled languages such as C/C++.

2) Java seems to becoming popular for a lot of OO and software engineering research. A lot of the originator of ideas such as design patterns (Erick gamma), refactoring (Martin fowler), XP and test-driven development (Kent Beck, Ward cunningham) are Java people.

3) You can do some amazing hacks in Java, using features reflection, dynamic class loading and byte code engineering, etc.

C++ looks like it's more powerful than Java because it supports templates, operator overloading etc, but Java also has some features that let you do some quite advanced things. For example look at the Jakarta Byte code engine library (BCEL) and look how it has been used in AspectJ and Jython. For example in Jython you can run an embedded Python script in your application that can seemlessly call any Java code, catch Java exceptions and so forth - i can't think of any language designed for embedded scripting that is this convenient.

4) Java has a huge open-source development community

The average Linux desktop user probably doesn't realise this, but there is absolutely piles of open-source Java development going on. A lot of this is on libraries useful for server-side enterprise deployment, web frameworks, workflow engines, object-persistence layers etc. but there is no shortage of projects out there.

On the whole i think the Java world is more interesting that people give it credit for.

Re:Maybe because it's slow ?

[chris_mahan]

Yeah, but YOU didn't write bittorent. A python programmer did.

You could write an AI expert system in javascript if you wanted to. I am not saying one language is better than another for this task or that.

All I am saying is that for people who are "hackers", Java is not as "attractive" as python.

This attraction is the "coolness" factor.

I agree that to build an enterprise-wide web-based data-back-end high availability, fast and robust multi-thousand user application, Java is the better tool.

But "hackers" don't want to develop billing software and reporting engine for banking or healthcare. They want to make things like bittorent, for fun.

And it's the "fun" that makes it "cool".

In all my years

[KidSock]

I have never seen so much utter nonesense that what I'm seeing posted in this forum today and my karma has been 5 since 1999. I code more in C now than I ever did in Java but clearly you people have no clue what makes a good programming language or how to program. Java is a great programming language. Most of these posts are downright incorrect. And why the opinionated ones get modded Insightful is beyond me.

The Bell Curve

[macrealist]

thanks for reading my long-ass post
you're welcome, thanks for posting it

However, I think you miss a few important concepts in your post.
1) Not all "A coders" are hackers.
- I've worked with the elite programmers that do believe that requirements and documentation are good and that a process produces better results. It seems that these are usually the elite and experienced, but not always.

2) Not all hackers are "A coders".
- "B coders" are hackers too. Seen it too many times. Just like anything else, there are more "B coders" and "C coders" that are hackers than there are "A coders". It is just a fact of life, that there is always an elite FEW, but and abudance of mediocrity. i.e., just because you are a hacker, doesn't mean you're good.

3) Managers are people too.
- There are many "B managers" and an elite few "A managers". And usually, an "A manager" is worth a team of "A coders" to a company.

4) Teams are usually a cross section of the population.
- Rarely are there teams full of code monkeys, or full of "A coders". Here is where a great manager is important. An "A manager" will allow enough room for each person to do what they need to, but ensure that each is able to work with the other. I've been lucky enough to have "A managers", and they make a world of difference to individuals and to projects.

5) Programming languages are just tools.
- Use the best tool for the job. Saying you choose a language based on your ability to do "neat hacks" is idiocracy. If I see someone putting nails into a wall with a screw driver, I think - "Damn, that guy is good with a screw driver", and "what a friggen' idiot".

Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience. Either way, I hope your next manager is an "A manager", you really need some help.

Re:Depends ...

[killjoe]

Don't forget Groovy

Debunking the debunking

[Ian Bicking]

Well, Graham doesn't really need me to defend him, but I will anyway. This article doesn't really get the point:

Java has considerably fewer surprises: on this one he might have a point. I might say "Java has fewer orthogonal features" instead. For instance, there's little ability to do metaprogramming in Java (unless you use AspectJ). There's just lots of interesting things you can't do -- and interesting things can also be hard to understand or cause surprises. Java's compromise is arguably valid, though not very exciting.

Java has been considered slow: obviously he doesn't understand where Graham is coming from. Many interesting languages are slower than Java, including many of the languages that Graham suggests (Perl, Python, Scheme).

Swing disasters continue: again, he doesn't understand Graham. To address his criticism of Java, you must ask "is Swing fun to program" not "are Swing apps fun to use".

Java is strongly typed: well, sure. ML is a statically typed cool language. And Lisp, Python, and Smalltalk are all strongly typed. (If you don't understand the distinction between strong and static, read this.) The problem is really that Java doesn't trust the programmer, not the specifics of its typing. Though if you trust the programmer, static typing starts seeming a lot less useful. And yes, great hackers don't like languages that don't trust them, for obvious reasons.

Java has a vast library that is available to all Java developers: this is a guy with a Common Lisp background. He certainly has no problem with good libraries, and he never mentions any problem with extensive libraries. Programming in an open field can be fun sometimes, and can help you think about things differently, but libraries are never a detraction (you can always ignore them if you want).

Java did not have a good IDE: I don't think Graham said that great hackers really like Visual Basic, and that's why they don't use Java. I laugh just considering that argument.

Java is popular: if you ever listen to the users of languages like Smalltalk and Lisp, they will bemoan at great length that they are not as popular as they deserve. Though you'd only know this if you ever looked at these communities.

Java is an application programming platform: so are Lisp, Smalltalk, Python, etc. Most of the kinds of languages Graham is talking about are not systems programming languages.

It's nice this guy tried, but he really doesn't understand what Graham is talking about. Which is kind of the point -- to understand Graham's perspective you need to have the intellectual curiosity to do non-work-related projects, using environments that are unfamiliar to you. You need to reflect on those experiences and make judgements about what you like and what you don't like. If you've only used Sun and Microsoft languages, you won't get it. That doesn't mean you can't do good work in Java, but if that's all you do, then you won't be much of a hacker at all.

Re:Maybe because it's slow ?

[Frizzle Fry]

There is *no* way that a interpreted or JIT compiled language can be *faster* than native code.

This is like saying that C can't be fater than the assembly. In theory it's true: whatever assembly is generated by your C compiler could have been written by you by hand. But in practice, you don't write assembly the same way a compiler does and it is much smarted about optimizing it than you are. So we reach a point where good compilers can generate more efficient code than would any actual human would write if they hand-coded in assembly, even though they theoretically could write equivalent code.

Similarly, a good JIT will in practice be faster than running native C code. We haven't reached that point yet, but we will because the JIT and the runtime are free to do things (like reorganizing memory to reduce paging and to put certain things on the same cache line) that your C compiler can't do since it lets you have access to pointers to arbitrary memory (and lets you pass them around and do whatever you want with them), and because your compiler doesn't have the same information at compile time about how you use the program that the JIT and runtime do, since they get to see what happens at runtime.

the problem is...

[bani]

java did promise to fill both embedded hardware and web-app space.

it failed on both counts.

I AM A POINTY HAIRED BOSS, AND....

[Anonymous Coward]

Okay, so I'm a Software Engineering PHB, having decided that 1.5X-3X the salary of an architect is nice to make, particularly when the job comes with arbitrary unearned prestige, the occasionally dishy secretary and the time and comfortable surroundings necessary to play Battlefield Vietnam and snack on occasional porn behind closed doors (use my own box and wrap comms out on 22 to home to avoid the sysadmin). So now that you have the appropriate amount of hate, pity or derision going for me, let me tell you what I see when I watch geeks like you argue for the best language, nerding over data structures, pointer math, two lines of this vs. one line of that and the like.

I see job security.

Because none of you have got an eye for the business imperative behind most language decisions: Make your software assets, your hardware assets and your people interchangeable.

Here's how it works. I'm in a mgmt meeting and the SPHB tells me that he thinks it would be reaaaal cool to put the temperature in Cleveland on the "About Us" page so his granddaughter can see how shriveled old gpa's testicles are. So I mention this change to the appropriate product manager and soon enough, resources are queued for that job and it gets passed out to a SNK (snot-nosed kid) for implementation. SNK immediately whines that we need Perl if we're a Java shop, Java if we're a Perl shop or a combination of struts, EJB's, an EJB-.NET bridge and some back-end VisualHappyHappy(TM) if he's had too many Mountain Dews that day.

Like WTF? "The best tool for the job" means crap to me when our software doesn't have to articulate the friggin Space Shuttle. If SNK goes and builds some monstrosity that only he understands, WhoTF am I gonna get to maintain it? If I let the nerds pick their favorite needle-nose pliers for every job, I'd have a whacko menagerie running on six different platforms in one month flat!

Thank you, I will retreat to my cave.

You want lisp in a box

[alispguru]

If you're looking for a GUI IDE, you'll have to go with one of the commercial Common Lisps, or one of the Scheme variants mentioned in other replies. However, lisp-in-a-box will get you hacking pretty fast - it's Common Lisp + emacs + slime (superior lisp mode for emacs) in one easy-to-unroll ball that should Just Work on the platform of your choice.

This link normally works, but common-lisp.net appears to be offline as I type. Google will show you the sites for various platforms

The big picture

[xoombeeny]

Interesting discussion.

Although this is a site / topic aimed at developers, it seems their are some "big picture" things here being glossed over. IMHO.

For one, someone upstairs said, "different languages for different problems." Hear hear. No one language is great for everything. I can think of three different languages I use for three different problem domains. C for device drivers, perl for system admin functions, (even on Windoze machines), and yes, Java for "big" e-commerce apps.

Java IS an excellent, strongly typed, OO language. When a problem lends itself to a good OO approach, and I'm not required to measure clock ticks for performance, I prefer Java because it makes it easier to do.

On the downside. I've been frustrated in the past with lack of JVM support for various devices. (And too dang busy to write my own!!)

And this brings us to the final "big picture" issue. Have you ever taken a look at Microsoft .NET? The structure and goals of .NET look like the best of Java with other stuff thrown in. The point here? It's the marketing dummy.

We can argue about syntax, tool support, and performance all day. But in the end, one of the key things about Java is, JAVA'S NOT .NET! And why does that matter? Because without competition the MS machine will assimilate us all!!!

MS is rapidly advancing to take over everything from the palmtop to the desktop, the set top box, and even your automobile. We need more alternatives that don't wear an MS brand. I would like to see us break out of some of these old, tired issues, and start focusing on what we can do to advance the state-of-the-art in more competitive ways.

I don't like Java, but...

[tchernobog]

I don't like Java, but it's just because of personal taste (or, better, general personal taste about who usually programs in Java).

Trashing these prejudices (that I read between the lines of many posts above), it remains one consideration to do.

I think that Java works well for server apps. If you've to build a server backend with a commercial JVM, or a framework, it is a really good choice (though not the only one, obviously).

When it comes to GUI / client side application, using Java is synonim of suicide, imho. You can say Java is fast as C/C++ as much as you want. I simply don't believe it. Moreover, using Java for that isn't the most wise thing to do, when there are much faster and easy pls to go with.

There's another thing to say: I hate Java since it is not an open standard.

Ok, I'm a Free Software advocate, I admit it. Having Java as free software would be the best, that's for sure. But not having it open standard is a lot worse... you cannot do your free (as speech) compiler. You're tied to a company (Sun Microsystems). It's a monopoly driven by a single head... that can change its path -- and Sun has demonstrated many times to be as dangerous as Microsoft for the OpenSource/FreeSoftware community.

Let's only hope that gcj/gij will reach an usable status. Maybe then I could start using Java for everyday use. Until then, I'll go on with C,C++,Python,Perl,Scheme... and so on.

As a Language Geek...

[cgreuter]

As the fortune file puts it, "A language that doesn't affect the way you think about programming is not worth knowing."

Learning C was a mind-expanding experience for me because it let me do anything I wanted and because it taught me about self-contained functions. Learning Smalltalk was a mind-expanding experience because it was this giant, full-featured language built out of a few simple principals. Learning Perl was a mind-expanding experience because it was this hideous, misshapen monstrosity of a language where every single wart turned out to make my life easier. Learning Lisp was a mind-expanding experience because you could extend the syntax of the language itself from inside the language.

And Java? It's basically just C++ with some of the better ideas from Smalltalk (or Lisp, Eiffel, Sather, Modula-3 or whatever) grafted onto it. Been there, done that, got the T-shirt.

That's not to say that Java isn't useful--it is. It's just not exciting. There are jobs for which Java is the right tool and some of those are even interesting from a hacker's point of view. It's just that the language itself that isn't interesting.

The only time I consider brushing up on my Java skills again is when I'm looking for a job.

(As an aside, my take on Paul Graham's comments is that if a company is looking for Java programmers, it's a bad sign because it means that the suits are making technical decisions. I'm inclined to agree with that--if the company is run by people who think Java is cool, you have to wonder what other kinds of decisions they are making.)

Disclaimer: I've done very little in the way of Java programming, although I did once write a compiler for it.

Things that suck about Java and things that don't

[cbare]

Things that do suck about Java:

• Difficult to do very simple OS specific stuff, like opening an html doc in the default browser.
• Takes a long time to start up the VM. If your program is trivially simple, the overhead dominates over actaully running the program.
• The Swing and AWT mess. It's gotten better, but I think Sun made some fundamental mistakes right at the beginning and they are unable to acknowledge these mistakes and unwilling to start over and do it right. They're a server and OS company. What do you expect.
• It's a lot harder than it should be to call natively compiled code from a Java program. JNI is a pain in the ass compared to other languages.
• EJBs.

Things that don't suck about Java:

• Ability to cleanly express object oriented software designs.
• Speed. For applications suitable to the language, (for example high througput server-side apps) Java's speed is very good. For tasks not suitable for this kind of language, don't use it. Dont't write the 'ls' command in Java. Most of Java's reputation for slowness is based on people's experience with applets in 1996. Get some updated information.
• Security. Most C programmers think that only crappy C programmers produce code containing buffer-overflow exploits and similar memory allocation bugs. Most C programs do, in fact, contain plenty of these types of bugs. Go figure.
• Maintainability and readability. If that's not something you value, fine.
• Javadoc. Every language should have something like javadoc. A standard something.
• Garbage collection. Run-time optimization. Java's collection classes. Tomcat, Ant, JBoss, log4j, hibernate, JDO, aspectJ, JavaCC, eclipse, IntelliJ, this list could get really long.

What really sucks is senseless language flame wars. If you're smart, (I mean really smart, not just self-agrandizing) it's a matter of choosing a good tool for the job. I would say the right tool, but there's often several good choices, as well as not-so-good choices.

It's interesting to note that Perl and Lisp are a lot alike, not so much in the languages themselves, but in their community. Both feature an intensely loyal following of programmers willing to overlook truely bizarre syntax in exchange for the ability to implement some advanced programming language concepts cleanly and consicely. Both languages are similar in their retention of some very strange artifacts of history: cons, car, and cdr, for example, or the parts of perl adopted from shell scripting languages. Some members of both communities tend to be a little too convinced of their own superiority. But, both languages really do have some cool features.

And remember: If Java is to Cobol what Python is to APL and if Perl is to Linux what Visual Basic is to Windows and James Gosling is to Larry Wall what Elvis is to Hank Williams Jr., can you doubt that we were made for each other?

Java is NOT slow!

[SlashSpam]

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

Fast Interpreted languages/NEW OS

[logicnazi]

While many people on this board seem skeptical of fast interpreted langauages it really can be accomplished. The problem is that most modern interpreted languages don't bother with these optimizations.

I heard of one interpreter designed to emulate another processor architecture which could sometimes run code for the emulated architecture faster. That is sometimes you would get a speed improvement by compiling the software for the secondary architecture and then running it through the interpreter rather than just compiling it and running natively.

How can something like this work you might ask? Well in the following way. At first the instructions would be entierly interpreted (and thus much slower) but during program execution frequently executed chunks of code would be identified and converted to snippets of native code. Henceforth when this code section was encountered rather than emulating it again control was simply transfered to the pre-compiled piece of code.

This might seem like no better than a JIT compiler but the important difference is that these code snippets and various profiling and branching information would be saved between program executions. Thus after a program had been used frequently it would end up being quite fast, sometimes even faster than native code.

How can this code be faster? A couple reasons. First of all since this 'extra information' was just a local cache it could be optimized to the specific architecture/chip without any fear of compatibility issues (if you find your architecture has changed just whip this cache and go back to interpreting). This means that the code snippets it generates can be evaluated on the machine they run on to see what generates the fastest results (so a program might end up running differntly on a system with a fast memory bus than a slow memory bus).

Secondly real profiling information can make a big difference. Not only does this allow the interpreter to make good branch predictions it allows for a whole new kind of optimization. For instance one might have dynamic loop unrolling where the interpreter has saved code fragments corresponding to 10 itterations of the loop and one corresponding to 5 iterations and one corresponding to 1 iteration. When it realizes it is about to enter a loop with 66 iterations it runs the 10 iteration segment 6 times the 5 iteration segment once and the 1 iteration segment once.

As far as I understand it compared to schemes like this Java interpreters/JIT systems are pretty bad. So long as you don't save a cache of compiled program segments and profiling data you are usually going to be slower than compiling.

Personally, I think this would be a wonderfull concept to design an OS around. The operating system would have a standard virtual machine most programs would coded in...or perhaps several VMs one for java another for mono etc.. Each executeable would have two forks, the first would be the actual code in whatever virtual machine the second would contain a cache of code snippets and profiling information on the current machine. It would also have the wonderfull property that new OS updates could actually make your old programs run faster (better optimization algorithms).

Can someone tell me why this sophisticated sort of technology isn't being used for java? Or is it and I am just missing something?

Python/LISP IDE's

[Degobah]

Sorry for the bad formatting, try this one:
Maybe a missing the point, but why do languages like LISP and Python have rather weak IDE's? No disrespect to emacs, but it seems to have stood still in the face of huge leaps in the quality of IDE's for other environments.

I believe Java combined with a next-generation Java IDE (Eclipse or especially IntelliJ) can recapture much of the productivity that's supposedly lost to Python's terse syntax. Intelligent code completion gets around Java's rather wordy way of doing things, and refactoring support makes supporting that verbose code a breeze. IntelliJ is smart enough to figure out if you have a variable, what type it is once you declare it and can offer constructors to instantiate it without you having to do all the typing. IntelliJ can even find redundant bits of code and refactor them into a method for you.

One of Python/LISP's main attractions is the interactive environment. Java's hot swappable classes combined with IntelliJ's debugger allow you to experiment and play around with your classes while your program is running, all the while inspecting your data structures, having conditional breakpoints, evaluating arbitrary expressions on the fly, etc. Really quite amazing how far java debuggers have come in the past few years. Plus java's remote debugger makes attaching to an already running process as easy as debugging locally which is great for debugging complex server side stuff.

Checked exceptions is a big problem for Python0philes. You can get around that in Java by throwing RuntimeExceptions, but some find that sloppy. The right way to avoid having to declare a boatload of exceptions from a method, is to catch low level exceptions and throw a higher level exception (e.g. your library catches IOException, SQLException, throws LibraryException). I've got IntelliJ set up with a template to generate a new Exception with one click and just fill out the name of the exception, and, viola, you've got your higher level LibraryException and you've forever liberated your users from having to worry about an IOException when calling your method and allow them to do more sensible generic error handling.

IntelliJ/Eclipse has tight integration with a number of standard tools like Ant (for builds), JUnit (for unit testing), XDoclet (for code generation), as well as plugins for tons of open source projects (by untalented non-hackers, according to the esteemed Mr. Graham) that make the task of getting work done a little easier by keeping you from inventing the wheel.

So what you're left with is an IDE that can compensate for Java's supposed weaknesses and lets you enjoy Java's strengths, which have been enumerated by numerous prior posts (Robust Libraries, Strong typing, standardized Unit testing, standardized build tools, platform independence, strong documentation, very few nasty surprises).

Which leaves me to wonder why, with all the great productivity and mind expanding power of Python and especially LISP (which had every f*cking feature back in '57 with McCarthy), do we struggle with vi or emacs, several slightly incompatible versions of LISP, shitty IO/concurrency libraries (for LISP), poorly documented libraries that you're not sure will work until runtime and even then may die on you unexpectedly in production when you blindly pass in some unexpected type, with decentralized pockets of apis scattered across the web in various states of disrepair? Java libraries seem to be a more organized affair, certainly from a documentation standpoint (the power of strong typing, checked exceptions and Javadoc are underestimated in my opinion and is one of the unsung features of the Java language) than most Python and certainly LISP libs out there. Why can't there be an IntelliPython, or IntelliLISP.

My point here is not to bash Python or LISP or any language. I have done a bit of work with scripting testing with Python (Jython actually) and am making an effort to learn CLISP (from Paul Graham's ANSI Common

Coolness == Abstraction

[Superfluid Blob]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?

That'd be Erlang.

The FA missed the point rather badly, IMO - what makes Java 'uncool' is its lack of support for abstraction. When a programmer finds himself doing the same thing again and again, his first thought is "can I abstract this pattern?". In Java, the answer is all too frequently "no", and the programmer is forced to type in several lines of code to express one conceptual construct.

Sun's big mistake was in not separating the ideas of Java and the JVM more cleanly when marketing it - there are some very cool, hacker-friendly JVM languages (most notably Scala), all of which share Java's virtue of "compile once, run anywhere", but which have got practically no mindshare.