The end of Java evolution

reprint needs to declare: original link URL: http://www.artima.com/weblogs/viewpost.jsp?thread=221903

Java:evolutionary Dead End

I just finished a keynote speech at the javapolis conference in Antwerp, Belgium. It was the morning of Friday, the day before Josh Bloch , who spoke about the controversy over the closures ( closures ) proposal. Now he sits right across from me and eats breakfast, and we talk about it further.   

java as a language too complex (). Reading code is much more laborious than writing code, which directly increases the actual cost of software development. The clock cycle of a computer is a very scarce resource, and anything that consumes these resources without benefit - even if it's a seemingly innocuous, redundant System.out.println () - will deprive cycle cycles that may have important uses and reduce the efficiency of the programming language ( Span style= "Font-family:times New Roman" >steve Yegge in recent articles addresses this issue).

In his speech, Josh mentions adding the last wildcard to Java generics can greatly increase language complexity. Neal Gafter suggested that the genericsshould be materialized. These two people were the absolute supporters of Java generics , and their response to my critical article illustrates that. Now there seems to be a change, and I notice some people start to suggest that "generics is really good, but ..." (Although Tim Bray recently called these people a scourge).

The only thing we can control about complexity is abstraction: hiding unimportant parts ("Divide and conquer" is a change). The paradox of Java is that it ignores a key aspect of complexity, which is that the readability of code is not seen as an important issue. It seems that if the IDE writes code for you, it doesn't matter if the code is complicated (it doesn't have to be so complicated).

Josh further elaborated on his view of complexity. This is not the complexity of an isolated trait, he says, because it is often visually visible. This is a synthesis complexity that combines a new feature in a variety of possible ways with other features of the language. When you shove a feature into an existing language rather than starting from scratch, you can't control how this feature blends with other existing features. The complexity of synthesis can lead to surprising problems, especially when you add features and do nothing. At breakfast, Josh says this complexity provides a rich reference for Java puzzles, and makes them much more of an interest, but not a benefit to the community as a whole.

Stability VS feature Addict

I learned from my breakfast with Josh that I was a trait addict (feature Junkie). Features are such fun games: Once you have mastered them, they can be used in fascinating ways. So I'm always thinking about the evolution of language in terms of new features. You may find that you are also a trait addict.

So, when the Java generics class of features were badly (I think) added to the language, I felt very frustrated, and I think they didn't do what they had to do when they added features.

But in my opinion, the thing to do is not to add new features. But if you cannot handle it correctly, then the language may no longer grow and become more stable until it abandons the quest for each of the existing language features.

It is not necessary to prove that one of the best features ofC is that it has not changed for many years. C + + is also very robust. So it's not necessarily bad for Java to stabilize.

This is not to say like Generics and closures have a "bad" feature. Quite the opposite, they can be very clear and powerful when they are carefully designed into a language. However, in retrospect, java There is such an opportunity. bill Joy is strongly required to join before the initial version of the language closures and generics and so on, but nobody ignored it.

For many years people have been tolerant, then suddenly generics must be hard to cram into the language. This is clearly similar to what happened in C # in the generics of the year. The latter also creates several other features in the Java5 . It seems that the urgency of adding these features is not the use of Java to solve real-world problems, but the perception that Sun is trying to keep up with Microsoft's C # . This may not be the case, because Java must first be broken out in a rough way, because it believes there is a market window that must be won. A programming language that relies on the power of the market to design comes to an end in vain.

Compatibility of the Holy Grail

One option is to correctly add new features and break backwards compatibility. As a trait addict I would choose to do this because it would not degrade the integrity of the language. This approach has not been accepted because backwards compatibility is always one of the most powerful language tools. I've noticed that Python has broken backwards compatibility in a small, jittery way in earlier versions. This change actually does not provoke any objection to sound. As a result, Python is planning to expand the range of backwards incompatibilities. Ruby is also considering removing some Perl features to simplify the language. Those who do not want to embrace these changes will not progress, and they are actually conservative rather than progressive. Many companies still use Java1.1for this reason. They will not be affected by the controversy because they are not prepared to accept the changes anyway.

If we can't add new features correctly because of backwards incompatibility, we won't be able to do it when language changes come. Where we are andC + +The same.C + +Often criticized in terms of design. And I've been a member of the standard Committee for eight years, and I've been arguing about every language trait. These traits are not repetitive, but cautious and thoughtful. Cause the language to eventually become complex and difficult is to keep theCBackwards compatibility. Once you plan to stay backwards compatible with anything, you must be prepared to break the language by adding features. IfJavaNot wanting to disrupt backward compatibility, it is inevitable to accept the benefits of new features without the benefit of complexity and the inability to fully implement the characteristics. I'm here"Thinking in Java(fourth edition)"Talked about this problem,Java genericsJust for the realgenericsof a pale imitation, and forclosuresOne of the more valuable suggestions (I think it should be called "CPA", but inJavapolisThe word was not heard in the speech of the General Assembly.-Maybe someone will tell me the right term) is trueclosuresThe incomplete implementation of the. But actually a complete implementation would be better because it would make the code clearer and easier to understand.

Basic-level new features should be reflected in the new language, which is designed as part of the whole language system, rather than being remembered afterwards. In my opinion, the current best exit strategy forJava (exit strategy) is Scala. I even heard some top programmers say they don't care about what happened to Java in this issue because they're going to go to Scala.

If Java is to exist intact, it must be like C : Be a reliable "workhorse". In fact, any language changes in the future must be able to make the language and its use easier and clearer (such as fixing classpath problems), and enrich (for example) the incomplete libraries (like JMF) that are limbo.

However, important and basic-level language features such as closures are extremely appealing in theory, but once they are forcibly added to a language that attaches importance to backward compatibility in abstract clarity, it will cost a great deal of effort in practice. So we have to be unusually conservative on this issue.

(We'll talk about this and other important Java issues in the upcoming Javaposse summary:http://www.mindviewinc.com/Conferences/ javaposseroundup/)

The end of Java evolution