Parallelically, I'm hoping that there's something we're all missing about multithreading along the same lines
Honestly, my suspicion is not. Consider: people have been working on the parallelism problem a lot longer than the GC one. When I mentioned the current push towards multi-core architectures to my father a few months back, and the challenges it posed for programmers, he pointed out that sure, he was working on projects for that -- back in the 1960s. Everyone's known for many years that this day was coming: they've just pushed it off for longer than anyone originally thought possible through clever hardware wizardry.
My suspicion is that it *will* become automatic in the not terribly distant future -- but doing so will require a somewhat more major change to programming than that. Specifically, every promising-looking approach I've seen requires you to think about problems a little differently: tackling problems by decomposition, rather than as a sequence of instructions. The nature of those decompositions varies -- sometimes using an ecology of inter-communicating objects (as in Erlang), sometimes using a descriptive approach to programming (as in Haskell). But it's always about breaking the problem down into little pieces, and letting the recomposition happen automatically.
I don't know that that's really any harder in an absolute sense. But I'd bet it will leave some programmers who can't make the leap behind, the same way OOP did...
Re: That was my first thought....
Honestly, my suspicion is not. Consider: people have been working on the parallelism problem a lot longer than the GC one. When I mentioned the current push towards multi-core architectures to my father a few months back, and the challenges it posed for programmers, he pointed out that sure, he was working on projects for that -- back in the 1960s. Everyone's known for many years that this day was coming: they've just pushed it off for longer than anyone originally thought possible through clever hardware wizardry.
My suspicion is that it *will* become automatic in the not terribly distant future -- but doing so will require a somewhat more major change to programming than that. Specifically, every promising-looking approach I've seen requires you to think about problems a little differently: tackling problems by decomposition, rather than as a sequence of instructions. The nature of those decompositions varies -- sometimes using an ecology of inter-communicating objects (as in Erlang), sometimes using a descriptive approach to programming (as in Haskell). But it's always about breaking the problem down into little pieces, and letting the recomposition happen automatically.
I don't know that that's really any harder in an absolute sense. But I'd bet it will leave some programmers who can't make the leap behind, the same way OOP did...