For example, Paul Buchheit recently posted some insights into API design, referring to poor examples that happen to be written in Java. He immediately states he doesn't hate Java. The post is about APIs, not the language. Even so, he still had to update his post saying "It's not about Java, really", presumably because of some polarized reactions. This is unfortunate because it distracts us from Paul's excellent commentary.
I suspect the polarization starts from a trap I have fallen into myself. Like many involved in language discussions, I use Java professionally and other languages at night, so I run into examples analogous to the one described by Paul Buchheit. I sometimes get frustrated with poor APIs, and also with the Java language -- either directly or by association with poor APIs. I wonder, couldn't it use powerful constructs I use in other languages, or could the APIs just plain be simpler?
The problem is my frustration may linger when I discuss programming languages, and (knowingly or unknowingly) be reflected in my tone when discussing Java. The resulting post is more acidic, and less level handed than I would like. Those who disagree with my arguments are likely to pick up on that tone and may respond in kind. Before long we've spiraled into isolated camps, and meaningful discussion is hard to achieve. My last post had signs of this.
So, where did I go wrong? When discussing constructive criticism of Java and its APIs, we need to view Java with some perspective. We need to remember its history. So my first point is:
A key goal for Java was to replace C++, and this goal led to design decisions that are often targets for criticism today. In 1996 it wasn't clear we could create a sufficiently fast language without primitive types and arrays. It wasn't clear how much boilerplate code would be required by anonymous callback classes or checked exceptions. It wasn't clear that since the new syntax exactly specifies implementation, factory patterns would proliferate, and so on. So my second point:We are critical of Java in a context different from the one in which it was designed.
Criticisms of Java should not imply any negatives about the designers of Java. Critics of Java are likely working in a problem space that differs from Java's original design goals, or incorporating new knowledge from the past decade.
The key is we need to keep this background in mind whenever discussing Java. We can criticize Java and its APIs without insulting anyone. When being critical of Java, any frustrations should be tempered by knowing the landscape has changed. Similarly, apologists should recognize that criticism need not be viewed as an attack; it might be an attempt to make things better.
6 comments:
Hi,
Ryan i completly agree with you.No language is 100% correct by any means.So need to stick with java at least professionaly.
Thanks
Prashant
Programmers are polarized about Java because is a language that has been forced on them.
Either you adopted Java to get a fat pay check in entreprise development or you did not.
In the former case, telling the truth about Java would ruin your reputation and you are at risk of loosing the trust of your customers/employers. So, you'll have to side with whatever marketing crap Sun comes up.
In the later case, if you disregarded Java as the next COBOL, you might get jalous of the good money other people make at the expense of gullible customers/employers.
Also, the nerve and stupidity with which members of the Java sect maintain plain lies about it (like J2EE beeing fast or scalable) can make some people quite angry.
I'm a paradoxal late adopter: Java makes my days now but I will never hide the facts from people who invested in it.
It sometimes difficult, but it is possible to say that Java sucks without insulting everybody that depends on the plateform.
I think it can end up being a case of doth protest too much, as well. The ostensible Java faithful actually hurt their cause when they react to criticism of bad Java code as if it were criticism of Java itself, and it comes off as a veiled admission that most Java code is bad. Which may or may not be the case. Certainly there is going to be a lot of bad Java code in the world, merely by virtue of the fact that there is a lot of Java code period. Java folks, like many of us in this industry, just need to learn not to be such hotheads.
I honestly believe that Java is cencerely hated by all software engineers who bothered to look around and *fully* learn at least another serious language. Laurent (see comments above) was absolutely right about the language being forced down programmers throats.
Sun managed to get everyone (universities) excited about this "assembly line" riding the wave of everybody's obsession with hating Microsoft and because "everything is an object" idiom was considered extremely cool back in early 90s.
Java was created with a very specific commercial purpose in mind: to have enterprise software projects done cheaply. This implies that language should be simple enough (cheap training, armies of dispensable coders) and restrictive enough (cheap QA) to cheaply build systems that transfer data from one database to another. Sun, do not forget, is a hardware company. And what many hardware companies want, is to turn software into irrelevant commodity.
This Wall-Mart approach apparent everywhere in Java's design. Java takes a shot at turning chaotic process of software development into an assembly line. And this is why it fails to be general purpose. It is the most rigid and inflexible commercial language today. Java forcefully divides the world into classes (even things that are *not* classes) and implies that they shall communicate between themselves with pre-defined sets interfaces based on static types. WTF? OOP is meant to model real world. Is our world really looks like that to you? Moreover, Java classes can share very limited implementation between themselves (limited inheritance, no mix-ins) and therefore behaviors of Java object models are very tedious to extend.
This is why Java never replaced C++ and this is why it will always be Wall-Mart engineering for the enterprise. look at all Linux projects, they are still going ./configure ./make route. And this is why no commercial software company (not enterprise, but consumer) has never adopted Java. Because they do not believe that their products are commodity.
I don't agree. Java is an object-oriented language and is statically typed. It seems to me that the point of various comments here is that they don't like static typing and/or oop. Try to really understand what oop, typing, patterns mean. There is no 'truth' that Java is bad. I'm not forced to use it, and I choose to do so, because it offers a strong language (yes!) and platform and a big community.
In addition, I'd say the arguments here don't seem to talk about design patterns, structured programming, ... Don't you like some structure? Static typing force you to have one, which some script programmers don't like. Java programs have to be structured, that's the only 'hard' part. I don't know of any other platform which offers so much *specification-based* possibilities and so much *different implementations* (application servers and the j2ee specs, jpa persistence, jsf, ...). When you say there are "better" languages/platforms, could you name them?
Post a Comment