Well, largely because it's difficult/impossible to do automatically in traditional languages, and people are used to traditional languages
This is kind of why I brought up the GC example. When I was first taught programming, "automatic" garbage collection was some sort of weird voodoo that no one quite believed in, and you had to be very careful to make sure you free()d things, and such.
Wind forward some years, and Java's GC (while slow and inefficient) is essentially foolproof, barring a few memory leaks over the years (like Strings). And I'm hoping there's another 15 years of progress since then that have improved this situation.
Parallelically, I'm hoping that there's something we're all missing about multithreading along the same lines -- that some minor change in programming, possibly involving an extra layer of abstraction (by analogy with the functional -> OOP shift), will mean that we get multithreading for free. And no one will have to write locks or monitors or whatever, ever again, because they're just too easy to get horribly wrong.
Re: That was my first thought....
This is kind of why I brought up the GC example. When I was first taught programming, "automatic" garbage collection was some sort of weird voodoo that no one quite believed in, and you had to be very careful to make sure you free()d things, and such.
Wind forward some years, and Java's GC (while slow and inefficient) is essentially foolproof, barring a few memory leaks over the years (like Strings). And I'm hoping there's another 15 years of progress since then that have improved this situation.
Parallelically, I'm hoping that there's something we're all missing about multithreading along the same lines -- that some minor change in programming, possibly involving an extra layer of abstraction (by analogy with the functional -> OOP shift), will mean that we get multithreading for free. And no one will have to write locks or monitors or whatever, ever again, because they're just too easy to get horribly wrong.
And a pony!