
Evolving Java Without Changing the Language 	 - fogus
http://www.infoq.com/articles/evolving-java-no-lang-change
======
10ren
The article links to this example of support for XML literals:
[https://rapt.dev.java.net/nonav/docs/api/index.html?net/java...](https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/proposed/generators/DomLiteral.html)

It's in the spirit of machine code in REM statements. A ghastly, reanimated
spirit.

    
    
      /**
      <commands>
          <command name="SOD" order="NEW">
              <parameter slot="P2" name="N" value="4811980" />
              <parameter slot="P2" name="N" value="4811980" />
          </command>
      </commands>
      */
      @DomLiteral static Document testCommands = DomLiterals.testCommands();

------
mdemare
I found the part about IDEs fascinating: IntelliJ will recognize those ugly
anonymous classes, and show them to you as closures.

I wonder how far you could take this. A language like Duby gives you Ruby
syntax, while producing identical bytecode as Java. If you could translate
Duby into Java source code, and parse and show it as Duby, your IDE could let
you program in Duby _without anyone else on your project even noticing_.

Then you're in effect relegating Java to object code.

~~~
axod
I think it's a pretty bad idea. The more IDEs hide code from people, the more
verbose code will be produced.

Much easier to just setup a simple macro system to run over source files and
replace things before compilation.

~~~
eru
Where's the difference?

------
wingo
The initial Gosling quote gives me shivers of revulsion.

~~~
jrockway
Me too. I had a hard time reading on after that.

Java is absolutely chock-full of "things that sounded like a good idea" --
unboxed types, single inheritance, interfaces without the possibility of
shared implementation (or state), public / private / protected / default,
positional constructor arguments, "Type foo = new Type", etc. Actually, none
of those even _sound_ like good ideas. (But I guess after the brain damage
that was C++, it was inevitable that The Industry would overcorrect. Hopefully
we've learned one important lesson from Java -- making the language "simple"
won't stop people from writing bad code, but it will stop people from writing
good code.)

Java also popularized some very very experimental ideas, like virtual machines
and automatic garbage collection. (And I am very thankful for both.)

So now that I think about it, I don't get that quote at all.

~~~
axod
I'll have to disagree with you there.

Type foo = new Type() is a bad idea? why?

Shape myShape = new Rectangle(); seems pretty logical to me. If you want to
use static types, you can't really argue against that syntax.

single inheritance sidesteps lots of potential issues, and interfaces are
cleaner IMHO

>> "but it will stop people from writing good code."

I'd also strongly disagree with that. Arguing that Java prevents you from
writing good code is nonsense. As much sense as saying using French prevents
you from writing a good story. I've seen some brilliant code written in Java
(If you steer well clear of 'enterprise' etc).

~~~
jerf
Because "Type foo = new SubType()" comes up approximately never.

Note, I did _not_ say never. But don't give me a line about how you use it all
the time. You don't. If you think you do, go grep over your code; you may
think you do but I still bet you don't, it's probably a perceptual bias where
you notice the exceptions out of proportion to their actual occurance. If you
still pass that test, congratulations, I was wrong, you're one of the five
people who do it all the time. You should probably stop, as something is
probably very wrong with your design.

Meanwhile, optimizing the syntax for this case is a terrible optimization
decision. That's the real problem, forcing literally millions (conservatively)
of type annotations that are totally redundant.

"I've seen some brilliant code written in Java (If you steer well clear of
'enterprise' etc)."

You don't see the brilliant code that was never written because Java doesn't
offer you the ability.

I also point to the "brilliant code" that isn't Java code at all, but compiler
and bytecode hacks, which I suspect had you taken the time to mention some
examples of "brilliant code" would have been in the list. That's not
brilliance you can credit to Java, it's simply stuff that was so desirable it
had to be done despite the fact Java didn't permit it.

~~~
axod
I do use it every now and then, but personally even when types are the same, I
don't really have issue with it. Makes it easy to see which type something is,
and keeps things uniform and sane.

Shape foo = new Shape();

is often written separately:

Shape foo;

// Further down

foo = new Shape();

So in that instance it's easy to see in both places what foo is.

If you do have issues with the duplication, it wouldn't be crazy hard to just
write a pre-processor to insert the Types on the left if you haven't specified
them, before compilation.

I simply don't buy the notion that you can't write great code in language X.
Language is largely irrelevant to how great the code is or isn't. Also
irrelevant to how well you can scale, how successful your startup will be, etc
etc

Great coders write great code. Languages are just ways of communicating that
great code with machines, and other people.

~~~
jerf
Actually, it isn't that great coders can't write great code in Java, it's that
great coders, having virtually by definition a certain amount of experience in
a wide variety of languages, require a lot of incentive before they'll choose
to write their great code in Java, where the language is fighting them every
step of the way.

Some people have managed to put out the necessary incentives, so such code
does exist, but seeing a putatively great coder reach for Java as their first
choice without such incentives is like seeing a putatively great coder reach
first for Cobol... it pretty much proves they aren't a great programmer. Even
if you want the JVM libraries, there are better ways.

Yeah, it's an opinion, but it's one from someone with the aforesaid experience
in a lot of languages. It's like saying a great marathon runner can run a
marathon in concrete shoes. Yeah, maybe they can, but seeing them choose it of
their own free will would say an awful lot about their wisdom in shoe choice.
Java is a language that simply loathes great code.

Besides, you seem to have missed the core point that optimizing the language
for a case that doesn't come up often is a misfeature, no matter how you slice
it. Optimize the language for the case that occurs most. "var X"-type syntaxes
cover that. "var X" still works in your example, too; there's no reason that a
smart compiler can't deal with that sort of separation between declaration and
initialization.

~~~
axod
Well, agree to disagree :) I've used a fair number of languages, and don't
really understand the java hate. There's far uglier languages to look at. But
then I love writing in assembly - which some feel overwhelmed with.

Personally it seems like some programmers at some point dislike being
restrained by anything and become slightly high and mighty about the whole
subject - the whole "Unless you use lisp, you can't understand why lisp is the
best language" BS.

Why is "var X"-type syntax better? Why does that create better code :/ Sorry,
I don't buy it. "var X" would be less precise, and less useful than specifying
the explicit type you want.

FWIW, I just checked for fun my own comet server written in Java against
tornado (Python). Very similar functionality, except the Java one is a smaller
codebase. It's as verbose as you want it to be.

~~~
eru
> "Unless you use lisp, you can't understand why lisp is the best language"

Of course we all know that Lisp is just a semi-imperative hack. Real
programmers use something more pure like Clean or Haskell nowadays.

Anyway, I just wanted to applaud you two for the civility ouf your discourse.
It was an informative read.

------
ivenkys
At what point does managing the complexity of all the "add-on" pieces of
software - APT, Meta-model generators, IDE magic, the interconnecting build
tools et all - become too high ?

Why not strengthen the core language ?

~~~
bad_user
Because that was the philosophy from the beginning ... don't change the
language until it's too late, make sure to cripple all new features to
maintain backwards compatibility, leave the problems to the tool-vendors to
solve.

Actually this philosophy worked better for future-proofing the platform in a
weird way. God knows how they would've crippled the JVM if their generics
support wasn't made through type-erasure for example.

And so the JVM bytecode is pretty light, now only if they added tail-calls and
continuations. But I don't think that will happen too soon.

~~~
ivenkys
I understand the philosophy and yes that has in a way future-proofed the JVM.
The question is "Does it make sense to try and include advanced language
features in a round-about manner into Java ?" Surely this approach only leads
to additional complexity and broken features.

Why not put that effort into a newer language running on the JVM ?

------
nickyp
You mean without rewriting it so it is not an ad hoc informally-specified bug-
ridden slow implementation of half of Common Lisp? ;-)

~~~
ZitchDog
I would say it's more of a formally-specified mature pretty-fast
implementation of half of Common Lisp.

