|
|
Re: Seeking the Joy in Java
|
Posted: Aug 23, 2006 3:18 PM
|
|
> Bill Joy was right, it's worth the extra time to do things
> well rather than rush them out because it seems expedient
> at the time. And the argument that Java is successful
> weakens over time, as the initial flaws are added to and
> you end up with complexity accretion increasing over
> time.
>
That problem of flaws adding up over time is the natural law problem I wrote about. It is true of any language. The more you maintain backwards compatibility with each release, the more klunky the language becomes over time. As far as the state of Java when it was released, I think Naughton and Gosling were right. There was a tiny market window and they needed to hit it. Applets were to Java what Rails has been lately to Ruby, something that generated a lot of hype and excitement, which propelled the langauge ahead of alternatives. If they had waited to release until they had added generics, they surely would have missed that window.
> But the inability to fix the language, and the staunch
> declarations that it was all done right in the first place
> so it doesn't need fixing, is what will eventually
> cause Java to diminish. Not disappear -- C++ hasn't
> disappeared either, but both languages will move towards
> niches: C++ is a more powerful C, and Java has captured a
> great deal of knowledge in its libraries.
>
What "staunch declarations that it was all done right in the first place?" Doesn't all the features that have been added to the Java language over the years contradict that? Inner classes, enums, auto-boxing, annotations, generics, and now the closures proposal--all these features seem to indicate that someone somewhere thinks that Java wasn't "all done right in the first place."
> Whatever the justification, saying that you can't fix a
> language because of backwards compatibility is effectively
> the same as saying that you can know all the requirements
> for a project up front.
>
I think it is the same as saying that although it is frustrating to pay the cost of added complexity in the programmer's face, this is the tradeoff we have to pay to minimize the costs of breaking compatibility. Breaking compatibility is very costly to the existing users, and I agree with how Java has tried very very hard to avoid it. It has done it some times. Just last week, for example, I needed to compile some JSPs for the first time on Artima's new server. These were Jive Software's admin JSPs from an old Jive release that I'm still using, and in the version they were written enum wasn't a Java keyword. Now it is, and it turns out they used enum as a variable name in several places (a variable of type Enumeration). So I spent time to fix this problem. The incompatible afterthought of elevating enum to a keyword in Java 1.5 cost me money just last week.
> Gosling and Naughton thought that
> Java would never need such esoteric features as
> parameterized types (what generics should have been), so
> they didn't have to be put in at the beginning. If they
> had, C#'s generics mechanism would have paled in
> comparison, but because they've had to be retrofitted, the
> so-called "generics" in Java are really just syntactic
> sugar for autocasting, and the really useful features of a
> true parameterized type mechanism are missing.
>
I don't think Gosling and Naughton thought Java would never need parameterized types, just that they didn't have time to put it in and still meet the market window opening up for applets. Also, I think it is better get something simple out the door that is usable, and get experience with it. Find out what features users really want before you add them.
> Now they're talking about adding closures, another feature
> that they were sure they didn't need when the language was
> originally being designed. Based on the generics
> experience, I shudder to imagine what new Frankenstein
> will come out of this effort. If it's anything like
> generics, it will end up being something that vaguely
> seems like a closure mechanism, but will be loudly
> declared to be closures. And perhaps enough people will be
> fooled by this (again) that it will get by (although I
> wonder about that, since there will be enough Ruby
> programmers who know what they really are to raise a
> ruckus about it).
>
Have you read the closures proposal? It is very short. It didn't remind me of Frankenstein, and what they suggested did indeed seem to be what I understand closures to be. Most significantly, variables in the enclosing scope seem to be available in the closure. I'm curious how they will implement this under the covers, but it was nice to see that inner classes get the same thing. Inner classes will be able to access variables in the enclosing scope, even if they are not final.
> If they're not going to fix the language, I have to agree
> with you that a new JVM language should be created rather
> than these exhausting attempts to add such fundamental
> features while retaining backwards compatibility.
>
These two are not mutually exclusive, and I didn't intend to imply that the are. I believe we should continue to improve Java, because I and many many others will continue to use it. My point is that Java has come to a level of maturity that another language for the JVM could take the lessons learned from Java over the years, and provide a non-source compatible alternative to Java that is still binary compatible with it. These two things (continuing to improve Java plus making a new language) can both happen at the same time.
It reminds me a bit of Python 3000. I saw Guido give his Python 3000 talk, and he pointed out that Python 3000 will not be source compatible with previous versions of Python. This allows him to clean up things that time has shown him were a mistake, or at least not as desireable as some alternative. But in the meantime, Python 2 will continue to be improved.
> One of the most powerful ideas that I've seen in both
> Python and Ruby is the willingness to fix things in the
> language even if it breaks backwards compatibility. Python
> has done it when fundamental problems were discovered, and
> has improved the language and kept it growing in good
> directions. Apparently Matz is really planning on removing
> many of the Perlisms in Ruby -- the aesthetics of those
> Perlisms are primarily what has given me a bad taste about
> the language, so I'm really impressed by this.
>
Yes, but you don't have huge investments in code that costs you money to fix when those breaking changes are made and you want to use the latest release. Besides, Guido told me in his interview that he tries very very hard to maintain compatibility in new versions of Python (Python 3000 is a notable exception), and Java has made breaking changes. Does it all the time. Assert was another. I complained about the assert keyword to James Gosling in one of my interviews with him, and he said it didn't break much code to elevate assert to keyword status. Only problem with that theory is that every JUnit test case at that point likely was using assert as a method. JUnit's assertTrue method used to be called assert, and had to be changed when Java made that breaking change.
Note to language designers: always reserve more keywords than you actually are using in release 1, especially keywords like assert or enum that you might someday conceivable add as features.
|
|
Previous Topic
