Beyond Java - Bruce Tate [28]
In fact, Microsoft's .NET environment threatens Java now. Some emerging programming languages draw the attention of some of Java's brightest independent consultants, and frustrating limitations drive away others. All other programming languages have had a limited period of leadership. In the end, this will be true of Java as well.
Myth 2: Java Is a Great Applications Language
Java didn't succeed because it was the best application programming language. It's not even a particularly good application programming language. Smalltalk and Python are certainly more productive. Visual Basic is simpler. Java succeeded because it was able to grab the existing C++ community, and enable them for the Internet. The community, not the language, represents the most important aspect of Java. Some of the very forces that ushered in the Java revolution may well help lead to its ultimate demise. The C++ legacy, necessary to attract the vast existing community, also limits Java in many ways that we'll explore in Chapter 4.
Beyond the syntax of Java, its explosive success forces Sun to make conservative decisions at the language level. It's doubtful, for example, that we'll see aspect-oriented programming baked into the language, as many think it should be. These decisions, designed to maintain backward compatibility, mean Java simply can't evolve as quickly as its competition. All of this means that Java's evolution is limited, when you compare it to its competition.
Myth 3: Java Is the Most Productive Language
When you compare it to C++, Java is indeed quite productive. That's the cloudy window through which we view Java. But Java's not an application language, any more than C++ was. Anyone who's ever used Basic or Smalltalk can tell you about the importance of a rapid feedback loop. Java's compilation requirements and static typing blow away any ability of real-time interpretation or a rapid feedback loop. Static typing is good for preventing some runtime errors, but it's hard on productivity. Java's string handling is limited. Java's syntax lacks features like closures and code blocks (which let you pass a block of code as an argument). Again, Java won because it was more productive than the language that most of us were using at the time. It was productive enough. It won't always be.
Corollary 3a: All languages are about the same
Java was able to displace C++ because it offered significant improvements, like garbage collection, a virtual machine, and better OOP. You can often express more with Java in fewer lines of code than you can in C++. The same holds true when you compare Java to some other languages. Languages like Lisp and Haskell offer a higher level of abstraction and a radically different paradigm. Languages like Ruby are far more dynamic, and offer much better access to the building blocks of the language through metaprogramming. Features like code blocks and continuations impact the way you organize and use your libraries, and Java doesn't support either one. In Java, you often have to work much harder to achieve the same result.
Myth 4: Commercial Interests Drive Most Java Innovation
While industry is driving some significant innovation, you could well argue that the most important innovations, like lightweight containers (Spring), web-based application models (Struts and Tapestry), and transparent persistence (Hibernate), are all happening in the open source community right now. These are the ideas that push Java beyond its intended boundaries. In fact, industry goals often hamper rapid innovation:
It takes time to synchronize massive integrated suites of products. That's why you have to wait so long between releases of WebSphere.
It takes time to build and test on the scale that's necessary to make big money, in the face of open source competition.
It takes time to create standards, and more time to adopt them.
The JCP tries to use the knowledge of experts to invent standards, instead of standardizing inventions born out of experience from successful implementations.