
Java's Original Sin - ksvs
http://gbracha.blogspot.com/2009/05/original-sin.html
======
russell
I think the real original sin was the decision to be a dumbed-down C++,
avoiding all the ugliness and hard to get right parts, in particular
eliminating operator overloading. With operator overloading supporting the
normal meanings of the operators (== means equals, not identical to). Integer
would then work the same as int and auto-unblocking would have been there from
the beginning. Remember Java overloads '+' for strings, so it isnt consistent.

Primitives made sense at the time, but with operator overloading we wouldnt be
stuck with the mess we have now.

And methods should have been first-class objects. More messes that could have
been avoided.

~~~
blasdel
Not just methods -- _classes_ should have been first-class objects!

Unfortunately, vocational Java programmers are _terrified_ of anything that
resembles metacircularity. There's a depressing tendency to just label
anything mildly functional as 'closures'.

~~~
chromatic
You've noticed that too? I spent six months confused, wondering why most of
the so-called closures in Java examples were merely first-class functions.

------
larryfreeman
Great blog post. Especially for those interested in scala and the future of
Java.

The comments below, in my view, are just as interesting as the post.

~~~
Retric
You can do most of this stuff at compile time and not mess with the JVM. Just
add auto boxing to the next version of Java and nothing need change.

As to the 16 byte char just do what most languages do when they get a basic
feature down and add a Byte32 or whatever.

PS: I tend to think of Java as a slightly more friendly version of C rather
than a high level language. It's fairly easy in Java to open a socket and
decode a bit stream, where most high level lanugaes make that far more
difficult.

------
jimfl
Java's original sin is checked exceptions.

~~~
zmimon
I don't think checked exceptions are so important. They might make things a
little more verbose and painful, but they don't impose fundamental constraints
and backwards compatibility nightmares the way other things do. After all, you
can always just choose not to use them - just convert everything to runtime
exceptions and your own code will be only impacted at the edges.

~~~
jdale27
_After all, you can always just choose not to use [checked exceptions] - just
convert everything to runtime exceptions and your own code will be only
impacted at the edges._

Forgive me if I'm being dense -- I haven't done much Java programming lately
-- but what do mean by "convert everything to runtime exceptions"? Sure, you
can define all your own exception classes as runtime exceptions. But checked
exceptions seem unavoidable, as you can't (practically) avoid calling all the
Java API methods that throw them.

~~~
zmimon
Sorry, away for a bit and didn't see your reply.

> But checked exceptions seem unavoidable, as you can't (practically) avoid
> calling all the Java API methods that throw them.

Yes, that's what I mean by "at the edges". You can't avoid hitting the ones
built into Java but you can stop them penetrating into your own code with a
simple try / catch that wraps them with RuntimeException.

------
known
Why isn't JVM integrated in Intel ICs?

