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?"
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.
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.
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.
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
Want to learn about race cars? Read my Book
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.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
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.
"Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive" -- hey, that's me!
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.
Please correct me if I got my facts wrong.
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.
Lost at C:>. Found at C.
Conversely, if you program a web-based app in C, you're a fucking moron.
Please break it gently to Google!
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.
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
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.
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.
All's true that is mistrusted
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.
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.