|
|
|
Back to newsletter 122 contents
Josh Bloch usually has interesting things to say, and Ryan Slobojan's interview with Josh Bloch gave me a couple of things to think about, particularly about language development. Slobojan suggests that one major reason Java became popular was that it addressed "many major pain points in C++", which I believe is quite true. When you are considering programming productivity in a major third generation language, Java stands head and shoulders above all the others because they did indeed address the "major pain points" of the existing ones, while retaining all that was useful (hence why C# is so similar to Java, Microsoft recognized those language advantages and ran with it). Is there a new language on the horizon that can take over? I'm in agreement with Bloch here that it probably hasn't been written yet, but that there is very likely to be one.
Although Bloch points to his "Java Puzzlers" book as showing the pain points in Java that need fixing in whatever the new language will be, I think most of those are minor niggles. No, for me, the major improvement in a new language would be some of what is being addressed in the JDK 7 language changes - fewer lines of code to do the same things we do now. Not radically different stuff, we've had 25 years of fourth generation languages (4GLs) each trying to do things in radically different ways to improve productivity, and none have stayed around - they always have the same problem, easy things are very quick to do, but as soon as you stray from the easy end, the 4GL becomes a hindrance rather than a help. Dynamic languages, though useful and with limited success, haven't really taken over as primary development languages because they become unmaintainable too easily.
What we need is something that uses fewer lines of code to do the same things we commonly do in Java, but is still strongly maintainable and doesn't make difficult things even more difficult. Oh, and automatically thread-safely runs the code on multiple cores without you needing to do very much different from the serial coding that you are quite used to doing. And also easily and quickly runs the presentation layer in a browser or standalone (and with not much effort to switch between those). Not an easy task, which is probably why it isn't available yet.
Now on with this month's newsletter. As usual we have all our usual Java performance tools, news, and article links. Javva The Hutt tells us his advice for dealing with obscure bugs; and, as usual, we have extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 122 contents