- 18comments
- 45comments
- 27comments
- 580comments
- 135comments
- 223comments
- 82comments
- 170comments
- 4comments
- 70comments
- 39comments
- 234comments
- 1comments
- 16comments
- 155comments
- 11comments
- 104comments
- 24comments
- 59comments
- 27comments
- 57comments
- —discuss
- 44comments
- 370comments
- 12comments
- 108comments
- 39comments
- 49comments
- 44comments
- 39comments
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.
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.
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.
Except the most common criticism of C++ is for being "too complex" or "too clever", so it seems there's nothing inherently wrong in trying to be a "dumbed-down C++, avoiding all the ugliness". You're just saying it made the wrong trade-offs in places.
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'.
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.
"Primitives made sense at the time"
I assume you mean primitive data types not being first-class objects? When Java was born, Smalltalk had a very long history of Ints and Chars being first class objects. The VM/byte-code compiler took care of in-lining values to make their time/space behavior as if they were primitive data types.
Also, Java was originally targeted at very low end machines - think WebTV. IMO, the top things wrong with Java are:
Too many concepts that overlap - containers, arrays, generics, iterators, classes, interfaces, etc. An important factor in whether you want to use a language is "how many concepts am I going to have to understand to read other peoples code ?"
A lot of the library is very poorly designed, probably because they rushed it out the door. Take a look at the GUI inheritance hierarchy for instance. Also, a lot of the code looks like C code IIRC.
Java's original sin is checked exceptions.
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.
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.
Sorry, away for a bit and didn't see your reply.
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.
Why isn't JVM integrated in Intel ICs?