Summary
Neal Gafter provides some insight into the distinction between "living" and "legacy" programming languages, and ponders which category Java belongs.
Advertisement
Neal Gafter, main author of the "consensus proposal" to add closures to the Java language, recently contributed a thoughtful piece on the question of Java language evolution, Is the Java Language Dying?:
We tend to think of programming languages in two categories: "living languages" in which we should seriously consider developing new code, and "legacy languages" that we mainly use, if at all, because we have to maintain an existing code base.
The act of classifying a language into one or the other category helps us decide what, if anything, we might consider doing to change the language. If a language is primarily a legacy language, changes should be aimed at making it easier to maintain and modify existing bodies of code. A living language, on the other hand, also benefits from changes that make it easier to design, develop, and maintain new code. Living languages evolve to reduce accidental complexity.
Noting some would prefer to see no major changes made to the Java language, Gafter notes that:
If so, we should place Java on life support and move our development to new languages such as Scala. The fork-join framework itself is an example of higher-order functional programming, which Josh argues is a style that we should neither encourage nor support in Java. Is it really time to move on?
Personally, I believe rumors of Java's demise are greatly exaggerated. We should think of Java as a living language, and strive to eliminate much of the accidental complexity of Java programs. I believe it is worth adding support for closures and control abstraction, to reduce such complexity of both the sequential and concurrent aspects of our programs. At the same time, for completely new code bases, we should also consider (and continue to develop) newer languages such as Scala, which benefit from the lessons of Java.
What do you think about Gafter's thoughts on living vs legacy languages? Do you think the distinction is valid?
You could equally ask "is C dying?". Well, no. C is C and will always be alive and well and used where it's useful. And I'm glad no one messed around with it.
C didn't suffer an identity crises when OOP became popular. It stayed with what it was good at, and let Java etc take the baton for the next generation. I hope Java doesn't start getting an identity crisis now that FP is becoming popular. There's no reason why it shouldn't pass the baton on to Scala etc.
Hmm, if C++ is a legacy language then I guess in what programming language are the AAA games developed in... COBOL? Or is multi-paradigm called legacy now? If we could program drivers in Java (without JNI), then there would be probably no need for using C or C++.
"..."living languages" in which we should seriously consider developing new code, and "legacy languages" that we mainly use, if at all, because we have to maintain an existing code base." (Emphasis mine)
Certainly you'll find disagreement between people over a language's classification, based on the domain they work in, and how they use the language. It hangs on what they mainly use for development.
But observing that people are egotistical, focused on what they themselves are doing (in their domain), I think Neal's opening statement holds true.
"We tend to think of programming languages in two categories:"
@Jiri: Note that Neal doesn't claim that everyone agrees with everyone else. For me, C++ is very much a legacy language. When I have to program a game that requires performance code, I will use C++. And I will grumble loudly about being forced into using a legacy language, because for most of my work, that's exactly what it is.
Of course, what we would all like to see is a detailed statistical breakdown of language classifications covering all languages and all domains and all programmers.
That's a lot of work, so plan B gets implemented: post the topic, start a discussion, and see who wins the argument ;) (I'm sorry, but "Is the Java Language Dying?" was born to be a controversial headline)
So is Java dying? Java is a great utility language. The platform is great. But it's just not as productive as smaller, more dynamic languages. As soon as people can choose to be more productive on the same platform, with the same libraries... It's not a difficult choice.
To me the major arguments I've heard for Java ("It's mature","It has huge developer support","Lots of major projects were successful in Java","Fantastic tool support") have LEGACY written all over them.
The Java Language cannot change drastically precisely because of these reasons. And if it can't change drastically, to me that says, "Legacy".
Why should a language be able to change "drastically"?
Was the introduction of generics in Java 5 a drastic change, in the sense in which you are using the word? If not, can you give an example of a drastic change? How about the changes from Perl 5 to Perl 6 ?
It strikes me that a drastic change produces a new language: C++ is a drastic change from C, Scala an even more (in my view) drastic change from Java. In that sense Java certainly CAN change drastically, but the upshot may be that Java itself does not change at all.
Apologies - the word "drastically" was poorly chosen.
Yes, generics to me would count as a drastic feature addition. You're right, if you change a language drastically, it becomes a different language.
I didn't actually mean to apply the statement generally... just to Java. Going by Neal's definition, a language isn't automatically a legacy language just because it can't reinvent itself. But in my mind Java is.
Why? The important question for me is not whether people *can* program in an extremely productive fashion in Java (or an improved Java). The question is whether or not they *will*. My answer is no, they won't. Perhaps the best programmers will. But the average ones won't, and the bad ones (like me) won't even be able to understand the new features intended to help them.
There's a huge weight of convention, training, thinking and culture built up around Java. Old habits die hard.
That leads me to think about domain specific languages. Even when C, C++ or Java were designed as general purpose languages, you can still feel the distinction when it comes to certain things you want to do in such language. C / C++ domain is drivers or the focus is more on HW and (not only) low level stuff. The problem is multi-paradigm; the more choices you've got, the more unhappy you're, in C++ case. Java is formally object-oriented making you code in OOP way and that's great. The black side is that you barely touches HW directly in Java (even through JNI). Java is dying even if we'll add closures, because as we Czechs say: Stareho psa novym kouskum nenaucis;)
The argument is simply wrong. Dividing languages into legacy and living is a false dilemma. C is a living language, but it changes so slowly and (relatively) insignificantly that it can be relied on to be stable over long periods. What Gafter really seems to be dividing is stable vs. evolving languages.
Put it that way, and you can have a much more sensible discussion.
I think that Java is under transition to see how it will change now that it is the community's hands. I'd rather see more emphasis on fixing/cleaning APIs and simplifying semantic/corner cases than in new features per se. But I do not know if its new status will make changes to the language easier or more complicated. *Most* long-time Java users what to keep the status quo, otherwise they would have moved to the Next Big Thing(tm). Also some of the Java 5 changes (Generics) have pissed some people, at least you can choose not to use them except for simple cases. One of the changes I find refreshing (maybe I look into blogs more now) is that discussions about features, and prototype implementations, are more in the open now. But for some people this may elicit fear thinking that anything that appears in the web will make it into the next revision. One of the ideas that people should ponder now is: what can be done/fixed if we decide to "break" some old code ... Or some APIs rewritten/supplemented ...
> The argument is simply wrong. Dividing languages into > legacy and living is a false dilemma. C is a living > language, but it changes so slowly and (relatively) > insignificantly that it can be relied on to be stable over > long periods. What Gafter really seems to be dividing is > stable vs. evolving languages.
Exactly. Why does it have to be "dying"? C has been stable for a long time, and I personally don't consider it a dying language.
While I was admittedly using a somewhat exciting title when I said that Java should become an "Evolutionary Dead End," I was saying the language should become stable, not that it was dying. Something that fits well within its niche thrives.
Previous Topic
