Am 28.10.2016 um 02:49 schrieb Richard A. O'Keefe:
Nobody ever said Java (or any other language) can't ADD things. The problem is that Java can't REMOVE the things that get in the way without ceasing to be Java.
Sure. (Minor nitpick: Languages can change their nature by adding things, too.)
It's just like the way you can ADD things (complex arithmetic in C99, threads in C11) to C, but you can't REMOVE the things that make C horribly dangerous without it ceasing to be C (and thereby ceasing to be useful in its admitted niche).
Sure, but still, it's a lot more grey area than you say - the dangerous things in C++ are still there but the language became much less dangerous because more modern versions come with other constructs so you are not forced to use the horribly dangerous stuff anymore.
The fundamental operation in Java is the assignment statement. It is fundamental to the Java Memory Model that when optimising memory references the compiler is explicitly allowed to pretend that threading doesn't exist.
If you fix those issues, you don't have Java any more.
Value types would fix those issues without making it non-Java. There have been multiple projects to get them into the language, so the knowledge and interest is there, multicore is just not prevalent enough to make Oracle recognize their relevance and putting their inclusion high on the to-do list for the next language version. Aliasing cannot be fixed in C++ because its constness annotations are too weakly enforced to be useful to an optimizer. In Java, this could be pretty different because you can't reinterpret_cast things unless you copy them to a byte buffer before, so the compiler does have all the guarantees.
Haskell can claim to be already there, but wrt. how many issues have been staying unaddressed, it's no better than Java, it's just different issues. IOW this is not a predetermined race.
Nobody ever said it was.
A certain smugness in a previous post implied something in that direction. At least there's the idea that Haskell is in a better position than most languages to adapt to that situation; I am sceptical, not because Haskell is a bad language (I'd LOVE to code in Haskell) but because it is missing some key elements to make it production-read for general use, so it's not even going to enter the race. (Some people are happy with that situation, which I think is pretty selfish.)
To be honest, I don't think ANY existing language will survive unscathed. I really wasn't talking about a race, simply making the point that we need new ideas, not just a rehash of the old ones.
New ideas and testbeds to see which of them hold up in practice.
A very simple point: the more cores are running at once, the sooner your program will run into trouble, if it runs into trouble at all. And the more cores are running at once, the nastier it gets for a human being trying to debug the code.
Actually imperative languages are slowly coming to grips with that. E.g. updatable data structures have generally fallen out of favor for interthread communication, which has removed 90% of race conditions. The rest is more on the level of specification problems. However, I am not aware of Haskell helping with multithreading once IO comes into play - does it?
So we're looking for a language that can give us strong guarantees that certain kinds of mistakes either CAN'T happen because the language cannot express them or WON'T happen because it can verify that your particular program doesn't do those bad things.
I do have some ideas, but not even a proof of concept so it's much too early to talk much about that.