A while ago Jeremy Miller posted about C# futures. In response to his own thoughts on what might be required, including mixins for example, he suggested that c# may be approaching the same point, that further changes post C# 3.0 might push it over the point of diminishing returns.
There is an experience of diminishing returns on languages and frameworks. At a certain point adding new ideas to a language increases its complexity so much that the productivity benefits form the new features are outweighed for anyone coming in to the language by the cost of learning its idiosyncrasies. Part of the issue here is boiling frogs problem. Those of us using the language do not notice the complexity burden increasing, because we only have to cope with understanding the additions, but for someone arriving fresh at the language, it’s like jumping into boiling water. It’s much like a long-running TV show, where new audiences cannot grasp all the references to previous shows and so never start watching. In the end the networks cancel the show, because it cannot attract new viewers and the existing ones are not being replaced as they fade away. Our hit show plays out as re-runs. MFC became more and more complex with time, especially after it shifted to include support for OLE, to the point where it became too hard for many people to start developing with it, so now, for application developers at least, it tends to be legacy code.
It looks as though, for Bruce Eckel at least, Java has passed the point of diminishing returns.
What is interesting beyond the realization that the Rubicon may have been crossed is not some kind of CLR vs. JVM triumphalism but the assertion that new features belong in new languages, designed to be that way from the ground up. Bruce notes that for some developers the choice is to leave Java for a new language and interestingly its not Ruby, but Scala. Ignoring the, Ruby is no longer cool, Scala is, message that has somewhat clouded the debate, the interesting part of Scala (which has a .NET implementation) is that it may be an easier transition for Java developers than the switch to Ruby, especially those who may prefer a statically typed language over a dynamic one. Of course what is easy for Java developers is also easy for C# developers.
Maybe it is possible that rather than focusing on changes to C# the C# team should pick up on the goals of Scala, to incorporate functional language features into a new language that is more familiar to C# developers than Ruby, but at the same time is designed from the ground up to incorporate the functional programming features that otherwise might be shoehorned into C#.