You really don't think there's been any progress in programming languages in the last 30 years?
I think there has, and I think there will continue to be progress. The area that seems most likely and is getting the most attention right now is concurrency, an area that many existing mainstays handle fairly poorly. We may not need a whole new language to address these deficiencies, but certainly different language design concepts, principles and frameworks may need to be incorporated into future versions of languages to provide their continued usage in the new manycore environment we seem to be kicking and screaming our way into.
Certainly I can and have written multithreaded code in C, C++ and many existing languages, yet I can see the value in exploring ways to make that easier.
I don't think there's been much to speak of no. Probably the most useful work has gone into runtime optimizations, JIT etc
I heartily strongly disagree about concurrency. Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU. But I won't start another rant on that.
>> " the new manycore environment we seem to be kicking and screaming our way into."
Again, I don't buy the koolaid. We were using multi cores 10 years ago and warning that we'd all have hundred core CPUs.
I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
> Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU.
I'm not sure that's a viable position anymore.
> Again, I don't buy the koolaid.
Yeah I know it seems like trendy nonsense but the power-wall is real and every chip designer I know has given up on improving single-thread performance anywhere near the same rate we used to. (And yes, I've listened to one of IBM's research scientists discuss this and when asked explicitly what they were up to with POWER6 and he basically they did it because they could, but they didn't see any future beyond that and overall they were going back to focus on parallelism like the POWER architecture had in the previous designs.)
> I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
Amen.
But again, I don't think that's viable. We need some way to use multi-threads somehow to get the performance we need in future programs. It could be full multiple processes maybe instead, but we'll need something.
I think we can both agree that it certainly shouldn't be like it is now.
> I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
Not too long ago on some thread here I said I thought that writing solid multi threaded code was hard and I got reamed for it.
I think I have above average experience in C and writing an operating system kernel has given me a good amount of insight in to how difficult it really is.
Anybody that thinks writing a multi-threaded program is a walk in the park hasn't done enough of it yet (or at least, not enough debugging, especially under high load you can have the weirdest problems if you aren't very very careful).
Writing multithreaded code on a single core is like saying to the OS:
"I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
> "I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
Writing like that makes me jealous.
There is so much insight in that one line, it shows how much you've done better than any long exposition ever could.
That level of brevity is something to aspire to, maybe one day...
Multithreaded code can be useful on a single core when you have blocking syscalls. Non-blocking I/O can help but doesn't eliminate this. Further, non-blocking I/O carries its own complexities.
Though I have to say, your characterization of the issues with multi-threading is nothing short of hilarious.
Well I know you're not mentally challenged, or crazy, so I'm going to guess that you're in one of those "everyone-is-wrong-no-one-can-change-my-opinion" mindsets.
I think there has, and I think there will continue to be progress. The area that seems most likely and is getting the most attention right now is concurrency, an area that many existing mainstays handle fairly poorly. We may not need a whole new language to address these deficiencies, but certainly different language design concepts, principles and frameworks may need to be incorporated into future versions of languages to provide their continued usage in the new manycore environment we seem to be kicking and screaming our way into.
Certainly I can and have written multithreaded code in C, C++ and many existing languages, yet I can see the value in exploring ways to make that easier.
Can't you?