Weblogs Forum - Java: Evolutionary Dead End

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Java: Evolutionary Dead End

92 replies on 7 pages. Most recent reply: Jan 3, 2008 9:06 AM by Bruce Eckel

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 92 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]

Gili T.

Posts: 6
Nickname: cowwoc
Registered: Jul, 2007

Re: Java: Evolutionary Dead End

Posted: Jan 6, 2008 7:19 AM

Reply

Advertisement

> That's what I am talking about. Introducing serious
> backward incompatibilities for the sake of "elegance" and
> "cleanup" will increase the cost of the project, and it is
> really hard (impossible?) to quantify the long term
> savings that the new/revised features will bring in.

But it *is* possible to quantify what will happen if we don't. What's the cost of everyone eventually having to migrate to a different language? A lot. A heck of a lot.

Coming back to the RetroWeaver argument, there are two options:

1) You provide bytecode-level backwards compatibility by providing a tool for converting newer bytecode to an older version. I personally don't think providing source-level compatibility is worth the effort. At least not yet. Let's try the bytecode-level compatibility first and if it works well we can take it a level further at a later time.

2) We don't provide backwards compatibility, rather we use something like a Retroweaver classloader which automatically migrate bytecode from an older version to newer at runtime.

I personally prefer #2.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Java: Evolutionary Dead End

Posted: Jan 6, 2008 8:29 AM

Reply

>
> But it *is* possible to quantify what will happen if we
> don't. What's the cost of everyone eventually having to
> migrate to a different language? A lot. A heck of a lot.
>

We are talking about two different things here. I say it is hard/impossible to quantify the savings the "clean" version of the language would bring compared to the case it wasn't cleaned up in the first place.

What I am arguing here is that preserving backward compatibility is more important than "cleaning up" a language. Or to be blunt, I am thankful Bjarne Stroustrup is not doing to his language what Guido van Rossum is doing to his.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Java: Evolutionary Dead End

Posted: Jan 6, 2008 8:50 AM

Reply

Perhaps not everyone remembers, but the early years of C++ saw substantial change. Subsequently it took a very long time for some vendors to converge on a reasonable approximation to the standard. So even though the standard wasn't changing, the parts that could be relied upon have changed. I had to change some (old) code last year so that it would compile with the current compiler.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Java: Evolutionary Dead End

Posted: Jan 6, 2008 2:44 PM

Reply

> That's what I am talking about. Introducing serious
> backward incompatibilities for the sake of "elegance" and
> "cleanup" will increase the cost of the project, and it is
> really hard (impossible?) to quantify the long term
> savings that the new/revised features will bring in. And
> many times sticking to the old version is simply not an
> option - especially if we are talking about a long-term
> "flagship" project rather than a "legacy" one.

There's a difference between introducing incompatibilities for the sake of "elegance" and introducing them to add an important language feature that is well designed.

I think it might have been worth it to introduce an excellent implementation of generics into Java, but probably not worth it in order to "fix" the compromised implementation that already exists.

Will McQueen

Posts: 3
Nickname: will608
Registered: Jul, 2006

Re: Java: Evolutionary Dead End

Posted: Jan 6, 2008 7:00 PM

Reply

Hi Bruce,

I've recently started looking into Scala this weekend. But I see another language on the horizon from Sun's Programming Language Research Group [Ref: http://research.sun.com/projects/plrg/Publications/index.html].

The language is called "Fortress", and the beta spec is at:

http://research.sun.com/projects/plrg/Publications/fortress1.0beta.pdf

I'm curious what your thoughts are on this language... do you think this language holds promise in its current form, and how would you compare its future with that of Scala and Java?

Great article, thanks!

Cheers,
Will

andries spies

Posts: 3
Nickname: wildfirexy
Registered: Nov, 2007

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 12:17 AM

Reply

I also started being a fan of generics, but now I have to aggree with Bruce. Not because I think generics per se has no place in Java, but because the implementers of generics ignored the basic practical fact: Code get's typed, and read by developers. Adding anything which increases verbosity is a bad idea. There are so many better alternatives for the current syntax:

Map<String,Integer> m = new HashMap(); 
/* Type is bound to variable m, even in my code: */
m.put("andy",1);

I'm not an langauge designer, but I it seems to to me Sun did not want to make the compiler more complex, so they conveluted the syntax rather.

My practical experience with generics can only be summarized by stating that it seems using generics is constant tug of war between me the developer with a desire to express a certain logical structure, and the compiler trying to force me to add more illogical statements: Sometimes I win, most of the times the compiler wins; And I end up with verbose high maintenance garbage with me wanting to shout: What the �@ck!

Maybe now that java is opensource, someone may just invent a better lanfgauge called it PAVA, or something.

I mean there is a reason why C++ is such a maintenance nightmare compared to C.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 6:33 AM

Reply

> I also started being a fan of generics, but now I have to
> aggree with Bruce. Not because I think generics per se has
> no place in Java, but because the implementers of generics
> ignored the basic practical fact: Code get's typed, and
> read by developers. Adding anything which increases
> verbosity is a bad idea. There are so many better
> alternatives for the current syntax:
>
>

> Map<String,Integer> m = new HashMap(); 
> /* Type is bound to variable m, even in my code: */
> m.put("andy",1);
>

>
> I'm not an langauge designer, but I it seems to to me Sun
> did not want to make the compiler more complex, so they
> conveluted the syntax rather.

I've discussed this at length with Peter von Ahe. I can't recall the exact explanation (it's pretty arcane, IMO) but there is a specific reason why type inference cannot be implemented in constructors. The syntax you would use for a method to allow for type inference already means something else when applied to a constructor.

My understanding is that they don't want to add a shortcut for that specific case you mention because the above allows for reification if it is added.

Neal Gafter

Posts: 12
Nickname: gafter
Registered: Oct, 2003

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 9:08 AM

Reply

> There are so many better
> alternatives for the current syntax:
>
>

> Map<String,Integer> m = new HashMap(); 
> /* Type is bound to variable m, even in my code: */
> m.put("andy",1);
>

>
> I'm not an langauge designer, but I it seems to to me Sun
> did not want to make the compiler more complex, so they
> conveluted the syntax rather.

The problem is not the complexity of the compiler, rather the problem is the complexity of the language. "new HashMap()" already means something, so your suggestion overloads an existing language construct. However, I'll be doing something quite close to it for JDK7. See http://gafter.blogspot.com/2007/07/constructor-type-inference.html

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 9:45 AM

Reply

Java 1.5 added too much to the language. Fixing the memory model was superb. Syntactic sugar and generics were a bad idea.

I am reminded of the discomfort I felt in the late 80s as the Fortran 9X fiasco rolled on. I was embarrassed to see classes jammed into Fortran because they just didn't belong. I understand the reasons, but hey are emotional reasons and it is time for Java to be mature, and let the newer kids on the block have their day in the sun.

Closures in Java is like training a pig to do ballroom dancing.

In case it isn't clear I am a Java fan-boy, but Java should stay Java.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 1:05 PM

Reply

> There are so many better
> alternatives for the current syntax:
>
>

> Map<String,Integer> m = new HashMap(); 
> /* Type is bound to variable m, even in my code: */
> m.put("andy",1);
>

As other have said, the problem is that new HashMap() means something similar to HashMap<Object, Object>, in particular it means a pre-generics hash map.

If a source statement (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519124) were added to Java then new HashMap() could mean infer generic types and new HashMap<>() could mean pre-generics (for backwards compatibility).

There is currently a proposal to make new HashMap<>() mean infer types (the opposite of what I have suggested above and already reference by Neal). But this is confusing because if you want a method to infer generic types you say methodName( ... ), not methodName<>( ... ).

Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 1:31 PM

Reply

> <p>Fundamental new features should be expressed in new
> languages, carefully designed as part of the ecosystem of
> a language, rather than being inserted as an afterthought.
> On my radar, the current best exit strategy for Java is
> Scala. I have even heard some fairly leading-edge
> programmers say that at this point they didn't care what
> happens to Java because they were just going to move on to
> Scala.</p>

I have tried Scala, and I think the language has some problems of its own:

1. No metaprogramming facilities. This comes from ML, I suppose. But Ruby has it and many "old school" elegant languages have it (Lisp, Prolog). It is possible to be elegant (in fact I would contend that in many settings it is a requirement) with metaprogramming.

2. There seems to be some difference in the semantics between compiled and interpreted. I only compiled, but the interpreter could add new variables to its local scope (as it really needs it) but the compiler couldn't. While one might argue that that is excessive flexibility coming from the scripting languages camp, but I actually had to, on a compiled program, to create new classes which would include traits that would be dependent of need of the user, and this cannot be done. If one has many traits, it has to compile a priori all the trait mixins desired, they cannot be defined at run-time in a compiled environment (contrast this to JRuby or even JPython). This is actually metaprogramming lacking part 2.

3. Type inference: Scala type inference might seem clever, but, compared to CAML it is not. Sometimes the compiler is not able to infer the types and the user has to explicitly declare them. CAML was always capable (at least in my cases) of complete type inference.

4. Information sources are scarce. The mailing list is reasonable, but sometimes questions get unanswered and there is no other source (other than inspecting the source code). This will sort out if there are more people using it - and more books like the Artima ebook.

I think JRuby is actually a contender (JPython is not because it is too much behind CPython in implementation). I would prefer to have strong typing (and type inference is sweet), but, all in all, I am leaning towards JRuby. Decent metaprogramming in a compiled setting would be my main requirement, but in the current Scala status, one can only have it though the typical Java way: execute the compiler, link a jar, not elegant...

Daesung Park

Posts: 10
Nickname: grayger
Registered: Apr, 2006

Re: Java: Evolutionary Dead End

Posted: Jan 7, 2008 10:24 PM

Reply

Does Java generics really break backward compatibility? Old source code may produce generics-related warnings but there is no problem to compile and execute it. Of course, it breaks forward compatibility.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Java: Evolutionary Dead End

Posted: Jan 8, 2008 12:43 AM

Reply

> Does Java generics really break backward compatibility?
As it is, no, because that was a design objective. The type of generics many would have preferred (i.e. without erasure) might well have required breaking backward compatibility.

Neal Gafter

Posts: 12
Nickname: gafter
Registered: Oct, 2003

Re: Java: Evolutionary Dead End

Posted: Jan 8, 2008 7:52 PM

Reply

"People lived tolerably for many years, then suddenly it became essential that generics be shoehorned into the language."

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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Java: Evolutionary Dead End

Posted: Jan 9, 2008 7:21 AM

Reply

> I think JRuby is actually a contender (JPython is not
> because it is too much behind CPython in implementation).

Jython (JPython is the old name) has started moving again. It was sitting idle for a long time and looked like it was abandoned but there was a release as recent as October. There's a lot of lost time to make up for, to be sure, but I wouldn't count it out.

Flat View: This topic has 92 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use