|
|
|
Sponsored Link •
|
Summary
I just came across Steve Yegge's "Execution in the Kingdom of Nouns," which (might) provide much of the explanation for why Java programs always seem to end up being excessively verbose.
|
Advertisement
|
Here is the article, if you haven't seen it (it's from 2006). His point is that Java has gone so overboard into "everything is an object" that it prevents simple and clear expressions of ideas. His very clever translation of Ben Franklin's poem "For want of a nail" into Java makes the point better than anything.
So here's my question: if closures allow you to be slightly more verby and slightly less nouny (in Yegge's frame of thought), will it allow programmers to create programs that are easier to read?
Or will over 10 years of ingrained culture overwhelm any attempts to solve this problem? Which is to say, will Java programs continue to look pretty much the same regardless of additional language features?
If there isn't a way to turn the ship at this point, then the early decision made by Gosling et. al. (to wit, that it was more important to get Java "to market" than to try to get generics and closures and the like into the language) is not something that can be fixed by later patching.
This is what determines the architecture of any software system: the core decisions that influence everything else in the system. These are decisions that you must get right, while other issues can be resolved at a later time through strategic designs. These decisions must be made by an experienced architect who knows what he or she is doing -- a lot to ask, but that's what "architect" is supposed to mean.
At the Java Posse Roundup '08, in the last technical session, we once again discussed the future of Java. We might have come to the conclusion that backward compatibility is being maintained primarily to serve companies that have no intention of upgrading to newer versions of Java anyway.
The most successful languages have been easy transitions from existing languages, so that the knowledge of programmers does not have to be discarded. C++ was extremely successful because it allowed C programmers an easy transition. Java has been equally successful because it provided a transition from C++.
Would it make sense to create a "Java 3K" (playing off of Python 3000, the name given by Guido Van Rossum to the once far-off, backwards-incompatible, fixed-up version of Python which is now going to appear sometime later this year)? A new version of Java that still runs on the JVM and has syntactic similarity with old Java, but is not hobbled with any kind of backward compatibility issues, so it can have real generics, closures, get rid of primitives, etc. If a company didn't want to move to Java 3K -- the same company that probably hasn't upgraded to Java 5 -- then it continues working with what it already has. But programmers who are being held back by the old issues and old bad decisions made in old Java can easily move forward into Java 3K, with only a small learning curve and virtually no productivity shortfall.
What do you think?
Have an opinion? Readers have already posted 70 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.
 | Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit