Great post--and the plethora of links it led to. I am particularly inclined to agree with this statement: > > If Java is unwilling to break backwards compatibility, > then it is inevitable that it will acquire both > unproductive complexity and incomplete implementation > of new features. > Such was clearly the case with generics. The combination of erasure and the fact that arrays are /not/ type safe leads to some astonishingly abstruse corner-cases, frequently producing error messages that are difficult to comprehend. (The "unchecked type" errors are particularly egregious. They mean exactly what they say: The type can't be checked at compile time, and it /also/ can't be checked at run time!)
To my mind, there is a obvious tension between expressive power and readability. (J)Ruby is a highly expressive language, but it is also difficult to read and to learn. Once you've gotten over the hurdles, you've got to love what you can do with it--but the concise power that makes your program "elegant" will make it more difficult for the next person to understand.
Java was always terrific for reading and learning. There was exactly one way to do anything you wanted to do, with no macros. Not even anonymous inner classes, at first. So you could pick up any program and read it straight away. You had to write a little more, but what you wrote was always clean and easy to understand--very important properties in a production environment.
Then came generics. That they were actually implemented in a backwards-compatible way was an act of genius. And there is no doubt that they make library-use somewhat cleaner. Except for one problem--they're viral.
When you use generic libraries, you need to begin using generic markup yourself, to eliminate warnings. Those generics wind up causing other warnings, so the usage spreads. Pretty soon, you wind up facing one of the dreaded "unchecked type" warnings. And if you use generics, you have to voluntarily remove array syntax from the language, and use ArrayList instead.
At the end of the day, the implementation of generics has improved neither code readability, writability, or reliability. Quite the reverse. All have suffered. (It wasn't even /possible/ to have a completely unchecked type, before.)
So it seems to me that Java should have stabilized as a workhorse, C-style language that focuses on clean, readable, reliable code, and that newer features belong in newer languages like JRuby and Scala. I wouldn't mind seeing a Java-NG, either. Maybe something like that will emerge from the new open source "language kitchen" that Sun has set up.
> Suddenly? Shoehorned? Not exactly. jsr14 was launched in > May 1999, after substantial preliminary work in Pizza and > GJ, and long before C# considered generics. It shipped > more than 5 years later.
Surely it wouldn't have taken 5 years to develop and implement Java generics if they had been a top priority. So, it was the decision to actually implement it that seems sudden and may very well have been triggered by the existance of C#.
As for the shoehorned comment, that's based on the way it was implemented, not on how long that implementation was pondered by Sun.
> Surely it wouldn't have taken 5 years to develop and > implement Java generics if they had been a top priority. > So, it was the decision to actually implement it that > seems sudden and may very well have been triggered by the > existance of C#. That doesn't fit my recollection of the process. What I do remember is that not many people paid much attention until just a couple of months before release. I think the last big change in the generics specification (wild cards) was over a year before Java 5 was released. As for a sudden decision, it could hardly been released as a part work (e.g. over 5.0, 5.1, 5.2, etc).
I seem to remember that some of the white papers on the C# generics design referred to the work on generics for Java.
> > Suddenly? Shoehorned? Not exactly. jsr14 was launched > in > > May 1999, after substantial preliminary work in Pizza > and > > GJ, and long before C# considered generics. It shipped > > more than 5 years later. > > Surely it wouldn't have taken 5 years to develop and > implement Java generics if they had been a top priority. > So, it was the decision to actually implement it that > seems sudden and may very well have been triggered by the > existance of C#. > > As for the shoehorned comment, that's based on the way it > was implemented, not on how long that implementation was > pondered by Sun.
AFAIK Neal Gafter lead the implementation of Generics in Java. He didn't have the final say on what was to be implemented. Given the constraints, I'd say he did a hell of a job (all while humoring pests like me on the Java forums.) I would treat his knowledge of the history on this as authoritative.
If I had to guess, I'd say there were a number of people thinking about and working on adding generics to Java for a long time but that they were stymied by others that didn't want them. When C# added generics, the argument against them was probably weakened a great deal. So why they were added when they were was probably a little of both "they were in the works" and "because C# added them".
> AFAIK Neal Gafter lead the implementation of Generics in > Java. He didn't have the final say on what was to be > implemented. Given the constraints, I'd say he did a hell > of a job (all while humoring pests like me on the Java > forums.)
I think the problem is the constraints. Rather than create the best generics possible and then attempt to maintain backward compatibility as a secondary priority, Sun made backward compatiblity the primary goal and then made the best generics it could under the circumstances.
This was Sun's call but I think many Java users think it was the wrong one. Given the way these decisions are made in large corporations, I wouldn't single out any individual as being responsible for it, however.
> This was Sun's call but I think many Java users think it
I don't think it was just Sun. I suspect others on the JCP committee also placed top priority on backward compatibility. Erasure allows a piecemeal migration to generics and yet that migration has still been slow. If erasure wasn't used would migration to generics have been even slower, perhaps to the point of failure? Also to what extent is erasure responsible for making a tool like RetroWeaver possible at all?
is not very good from a typing theory standpoint. In most, if not all, programming languages that support type inference, it is the type of values that is inferred from the types of expressions, and not vice versa.
I don't understand how expressions are going to be type-inferred if the type is declared in variable declaration, instead of the expression. For example, how is the following going to be inferred without declaring the type of HashMap?
new HashMap().put(new Bar, new Foo);
It could be better, in my opinion, with syntax similar to this:
auto map = new HashMap<Foo, Bar>();
var map = new HashMap<Foo, Bar>();
_ map = new HashMap<Foo, Bar>();
? map = new HashMap<Foo, Bar>();
Most of the current high profile languages do something similar to this, e.g. Ruby, Scala, Fortress, and C++ (proposed to be added). So one of the advantages is that it would be consistent with other languages.
The type of map would be HashMap and if you wanted a Map you would have to write:
declare Map map = HashMap<Foo, Bar>.new();
I think the programming to interfaces advice is primarily related to public signatures, therefore I don't see this as a big issue.
> > AFAIK Neal Gafter lead the implementation of Generics > in > > Java. He didn't have the final say on what was to be > > implemented. Given the constraints, I'd say he did a > hell > > of a job (all while humoring pests like me on the Java > > forums.) > > I think the problem is the constraints. Rather than > create the best generics possible and then attempt to > maintain backward compatibility as a secondary priority, > Sun made backward compatiblity the primary goal and then > made the best generics it could under the circumstances.
Exactly, Neal (and anyone who worked with him) did a great job given the constraints placed upon them.
> This was Sun's call but I think many Java users think it > was the wrong one. Given the way these decisions are made > in large corporations, I wouldn't single out any > individual as being responsible for it, however.
I didn't say he was responsible for the constraints. I said he did well given the constraints.
> > is not very good from a typing theory standpoint. > > But it is good from the "program to interfaces" theory. >
That's why Java is going to be a dead end. Further analysis of why this is bad is not required: those who understand type theory understand the problem with this.
> > > auto map = new HashMap<Foo, Bar>(); > > What type is map? a Map? a HashMap? a Serializable? > > How do the other languages handle this?
> > That's why Java is going to be a dead end. Further > analysis of why this is bad is not required: those who > understand type theory understand the problem with this. >
This looks like a religious impasse. Analysis is futile, and agreement is unlikely.
Language feature accretion ultimately leads to a confused mess (which, btw, is what I think of C++). But it does have the benefit that once people see how to do it badly, they eventually come up with new languages that do it right. Python, ruby, etc, wouldn't be nearly as good as they are without the experience of shoe-horning some of those features into other languages. Or to put it more succinctly, to learn from our mistakes we must first make mistakes.
IMHO one reason Java succeeded is because it learned from C++s mistakes. Now that it's making its own mistakes, it pays a much higher price. That's just how software language evolution works. Innovate, complexify, and eventually die from it, or freeze but be passed and (usually) die from it.
This might sound derogatory, but here's my impression: Java thrives in the land of large systems (predominantly business and web apps?) created and maintained by large teams of (blub?) programmers. And so if Java has reached a language evolution dead end, I have to wonder what can thrive in that large systems/large teams niche. Ruby/JRuby is a way forward in programming languages, but not for use in that niche.
I've been using Ruby off and on for over 3 years, and giving it a lot of pondering for over 3 months. I've come to the conclusion that Ruby/JRuby will never scale to large systems with large development teams, not with its astoundingly open classes and modules. Anyone can come along and (inadvertently) redefine anything at any time, and so-called unit tests will still pass. Meanwhile, because of all that openness--not necessarily because of a lack of explicit typing--I'm not sure any IDE will ever be able to make sense of Ruby.
Flat View: This topic has 92 replies
on 7 pages
[
«
|
234567
|
»
]
Previous Topic
