Beyond Java - Bruce Tate [32]
Development processes and Java
Java's community and tools provide excellent support for agile development, but there's a catch. Java is not such a good language for agile development. Java is not the simplest of languages. Nor is it friendly to very short iterations. If these two ideas are not clear to you now, they will be clear by the time you finish this book. Other languages let you move from one change to the next without a cumbersome compile/deploy cycle. Other languages have a more expressive syntax, and other frameworks take you to a higher, more productive level of abstraction.
Even as we begin to understand that Java is not the most agile language, those using other dynamic languages are using agile techniques like automated testing to shield them from the problems related to programmer-friendly type and exception strategies. Java's founders believed that it's always better to catch potential bugs at compile time. They did not consider that features like static typing and a heavy emphasis on checked exceptions come at a cost.
If we were to choose a language based on the development methods that we value today, Java would almost certainly not be our language of choice. As the principles promoted by agile developers become prominent, the Java language will experience increasing pressure.
Basic Java Limitations
I've painted a picture of the average project. The average team builds or ports applications that will deliver a web-based frontend on a relational database, potentially with other less meaningful services. The team probably uses increasingly agile principles, and likely wants to do unit testing. The team typically works under short schedules and great pressures. And given more dynamic alternatives, Java is not at all the language that I'd usually choose for such a project, in such an environment:
The many frameworks designed to simplify the Java development experience do make experienced Java developers more productive, but make the learning curve too steep for those new to Java.
Compile-time checking of exception and types adds safety, but comes at a cost of additional time and syntax.
Java's inability to express structured data leads to an over-reliance on XML, with the corresponding additional complexity and bloat.
Java's many compromises, like primitives, make Java harder to learn and more complex to write.
Java is more dynamic than C++, but is nowhere near as dynamic as languages like Smalltalk and Ruby. Java developers are finding metaprogramming, but they're not able to execute on those ideas fast enough.
Java's long compile/deploy cycle is much longer than interpreted, dynamic alternatives.
Taken alone, none of these issues hurts enough to matter. Taken together, Java becomes much less productive for most developers.
Steve Yegge: Java's Limitations
Language expert and creator of Wyvern
Steve Yegge, a graduate of the University of Washington, spent five years as an Assembly-language programmer at Geoworks and more than six years as a software development manager at Amazon.com. Steve somehow managed to find time to design, implement, and maintain a massive multiplayer game called Wyvern (http://www.cabochon.com/), with a half-million lines of Java and Python code.
What is your experience with Java?
SY: I was a card-carrying member of the Java community from late 1996 through mid-2003. I used Java to build a cool, multiplayer, user-extensible online game. Java got me really far, and I loved it for seven years.
Why did you start looking at other languages?
SY: I simply hit a productivity wall. As my code base grew, my innovation slowed, until finally, tasks were taking me an order of magnitude longer than I felt they should. I stopped development for six months and did a deep-dive investigation to figure out what the heck was going wrong. It wasn't what I expected. The problem was Java. I was pretty unhappy about this. I'd invested an awful lot in Java. AOP helped a little (albeit at a high entry cost), but nowhere