Jonas Bonér, in "Java Killed the Innovation of Computer Languages," comments on a conversation he had with Chris Richardson, saying that "in general nothing has really happened the last 10 years." He then says that AspectJ is innovative, as well as some scripting languages, but in general, things have remained the same.

He then follows that with a set of questions to think about, for future languages. Interesting stuff.

1. give it time. things seem a little static right now, but time marches on and something earthshaking will come along.

2. (a flipside) sagely colleague once told me, "there is nothing new under the sun" when asked about how he had come along over the decades from mainframe assembler to cics to c to java/oo (which he was darn good at). 55yo doug transcended technologies. even java in its infancy did not strike doug as being terribly revolutionary.

Seems to me that as a language (not a platform), Java was mostly a rehash of smalltalk and that was when.... 72 to 80 mostly? Or perhaps we could call it a subset of C++ (but I personally think of C++ more as a retrofit than an innovation). So I think the slowdown in language innovation long preceeds Java

Now If indeed the Comp Sci community has ceased to innovate... what has that to do with Java? I'm baffled by how he makes that connection. Did Sun somehow poison the waters of MIT and Yale and MS and Apple and all of the language platform providers? Was there a bloody coup amongst the thought leaders of lisp and perl and eiffel that I missed? Did the JUGS of the world unite against some shadowy army of innovators?

The only thing that can kill innovation is for smart people to give up. I don't think that's happened. (And so then I think you can hardly blame Java for making it happen.)

If you equate innovation to change, then it's not necessarily a good thing. Some people may love the additions to the Java language made for 1.5, but to me, it's just syntactic pollution that moves it possible for programmers to write code as opaque as they could with C++ templates.

I think there is a tendency (not always bad) for hipsters to denounce whatever happens to be the dominant technology.

Did Sun somehow poison the waters of MIT and Yale and MS and Apple and all of the language platform providers? Was there a bloody coup amongst the thought leaders of lisp and perl and eiffel that I missed? Did the JUGS of the world unite against some shadowy army of innovators?

Was there a bloody coup amongst the thought leaders of lisp and perl and eiffel that I missed? Did the JUGS of the world unite against some shadowy army of innovators?

Natural selection most definitely occurs amongst ISVs and is driven in part by the technologies they chose. JavaScript dominates presentation programing and accounts for most of the code distributed on the Internet. But dynamic languages likely have empirical competitive handicaps which are severe in the theaters of system and business programing. Surely that's why Perl lost market share to static languages for doing CGI, and Smalltalk vanished from the desktop. Static languages might be inherently more amenable to analysis, such as codebase validation and refactoring.

As part of natural maturation, I've seen a scripted program strategically replaced by one compiled from a static language. But except for webification, I've never seen a compiled program later ditched for a scripted one. Some selective pressures regarding pragmatics are inescapable.

If you equate innovation to change, then it's not necessarily a good thing. Some people may love the additions to the Java language made for 1.5, but to me, it's just syntactic pollution that moves it possible for programmers to write code as opaque as they could with C++ templates.

Have you ever used C++ templates beyond leveraging the STL?

C++ templates are a much more efficient means of source code obfuscation than generics.

I don't think anything is killing innovation. The fact that there has been no obvious successor to Java is a testament to the excellence of the Java language for general development.

The purpose of any development system is to let the programmer do what (s)he does best (the high level thinking) easily and efficiently, and let the computer take care of as many of the minor details as possible.

One of the great advantages of Java is its elegance and simplicity. IMHO C++ was a great language (compared to its predecessors) until the language lawyers got at it and introduced all sorts of complexities that programmers didn't want to know about and should have been left to the compiler. So far Java has avoided these problems (although I have some reservations about annotations).

The major innovations, that have been driven largely by Java, have been the massive improvements in libraries, IDE's and debugging tools over the last 10 years.

The Java libraries are, for the most part, easy and intuitive to use. Contrast this with Microsoft's libraries which are a nightmare of non-intuitive design.

Similarly the trend in IDE's (Eclipse, Intellij, NetBeans, etc.) over the past decade has been a steady stream of innovations. Perhaps the fact that innovation happened there, instead of in the language, is due to the fact that these areas were the weakest link in the development chain, in terms of programmer effort that could be streamlined.

Prior to Java, everyone paid lip service to unit testing, but few people actually did it and even fewer did it methodically. Again, by reducing the cost of unit testing with tools such as JUnit, Java has been responsible for a revolution in the way we debug programs.

IMHO C++ was a great language (compared to its predecessors) until the language lawyers got at it and introduced all sorts of complexities that programmers didn't want to know about and should have been left to the compiler. So far Java has avoided these problems (although I have some reservations about annotations).

Do you not think generics fit into this? Whether you love generics or hate them, I think it's hard to argue that they have not increased the complexity of the language greatly, much more than annotations (which I barely consider code.)

Hi James. Yes, I agree that generics increase complexity and can get very obscure. I haven't seen anywhere a good, complete and readable description of the syntax and semantics of generics, which I think would help a lot.

One of the things I like about Java generics is that they are processed completely at compile-time, which means there is interoperability between code using generics and code that chooses to ignore them. It also means that errors are caught at compile time. On the other hand, it creates several obscure problems.

Another thing I like is that, once you have your generic classes written, using them is a definite improvement on non-generic code in that your code is strongly type checked and the old-style casts are no longer needed. I.e. you can't add an Integer to a List<String> and you don't need to cast to String when you extract an object from the list. And all these things are checked at compile time.

Using generics is much easier than writing generics, and the benefits of the new generic Lists, Maps, etc. in Java 5 are hard to argue with.

On the other hand, writing generics is much more complex that I would like and can get very convoluted. I can attest to that, having just converted quite a large body of code to Java 5! I don't know how much simpler generics could be made without losing essential capabilities. It's clear that the guys who designed generics put a lot of thought into the design, so I suspect the answer is 'not very much'.

If the question is: 'are generics useful?', I guess I would say yes, on balance. However, I'm saying that AFTER going through the learning curve! I certainly used up my share of expletives while I was trying to figure out why some of my generic code didn't compile!

I agree with your comment about annotations. My problem with them is that I distrust anything that modifies my code behind my back, especially if it affects the way I can debug the code. While the Java compiler itself is well tested and trusted, I'm not sure the same will be true of third party annotation implementations. I guess their usefulness will depend on the use to which they are put and whether and how they modify the code I write. I haven't seen a convincing example yet.

Basically, I'm not convinced that the same functionality can't be implemented with equally succinct Java code that is more open to inspection and debuggable when it goes wrong.

Another problem I have with annotations is that they are so unconstrained. I can see the possibility of severe incompatibilities between annotations created by different vendors.

<blockquoteAnother thing I like is that, once you have your generic classes written, using them is a definite improvement on non-generic code in that your code is strongly type checked and the old-style casts are no longer needed. I.e. you can't add an Integer to a List<String> and you don't need to cast to String when you extract an object from the list. And all these things are checked at compile time.Using generics is much easier than writing generics, and the benefits of the new generic Lists, Maps, etc. in Java 5 are hard to argue with.On the other hand, writing generics is much more complex that I would like and can get very convoluted. My take on generics is that a little goes a long way. Declaring a List<String> is much better than inserting casts in places and comments explaining what types are allowed. It's awesome. Going back the old way of looping over an iterator is painful after using them. But once you start getting into variance, things go downhill fast.

I almost think that they should have stopped and left out the variance. It's powerful but it' also esoteric. The biggest problem is that I think a lot of developers ae going to be seduced by the power and get in way over their heads.

It's amazing how many posts there are on the Java forums looking for solutions to gaps in generics and how many people recommend writing new classes to work around these issues. What's so crazy about this is that before generics these weren't problems. It's created issues where there were none.

An example is that Map.get is not parameterized. People bitch and bitch about this and think that it's all about old code and what not. A lot of them have written their own classes to 'fix' this problem. What they don't realize is that making get() parameterized breaks the Map inteface with respect to variance i.e. you can't call get on a Map<? extends Object, Foo> if get requires type K.

Generics hold lots of surprises and gotchas that are going to become clear as time goes on. I wish there was a little restraint in people's enthusiasm for writing generic classes.

My take on generics is that a little goes a long way. Declaring a List<String> is much better than inserting casts in places and comments explaining what types are allowed. It's awesome. Going back the old way of looping over an iterator is painful after using them. But once you start getting into variance, things go downhill fast.I almost think that they should have stopped and left out the variance. It's powerful but it' also esoteric. The biggest problem is that I think a lot of developers ae going to be seduced by the power and get in way over their heads.

I think you've hit the generic nail right on the head, James! This is the feature of generics that causes massive problems. I haven't thought too much about the implications of dropping variance and how many problems that would cause, but I suspect there would be a few problems there too.

I guess it comes down to philosophy. I always thought that Pascal (remember Pascal) had a philosophy of 'do it my way or get lost', whereas C and its successors had the philosophy 'here's the gun; it's very powerful, but be careful you don't shoot yourself'.

The Java philosophy has been somewhere in the middle, which I think is a good idea. However, generics are pushing it more towards the C philosophy.

Blaming Java for a lack of innovation in computer languages is perhaps not fair. I don't see a great value in having a brand new language emerging every year.

Once you have a set of languages that might cover most of the IT domains, you might start to be proficient in a number of them. Now you find yourself in this stage and look around and say "OK, now I have to do my programming work in a more efficient way". At this point you start developing new programming methodologies, new concepts of sharing information and new ways to collaborate with other developers.

This is how a bunch of great minds have "invented" methodologies like XProgramming or Open Source licenses or collaboration platforms for Open Source developers like Source Forge.

I know, there is nothing new in that. But consider the ages when one of the most popular tools for developers was "make". I would simply not go back there just for the sake of some programming languages that were not invented (or were invented but didn’t have a great impact).

In my opinion this is where the innovation was focused in the last decade.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.