I think the future here is unordered programming languages, where parallelism isn't something you code in, but, as in Haskell, simply the default, which you must code around in situations where order -is- explicitly relevant (see: monads).
Except in domains that are naturally at that level, the programmer shouldn't have to be thinking of thread management and where and when to thread; instead, they should be able to lay down the logic of a program without imposing order on its operations except where necessary, and let the compiler/interpreter do its own optimizing.
Something of a hybrid here are languages with a lot of matrix calculations and lazy evaluation (as perl 6 has, at least semantically). As long as you don't have a contract saying what order a matrix operator has to process stuff in, and can run lazy evaluations in parallel rather than sequence, you can get a lot of threading in under the hood without having to bother the programmer about it.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2008-07-02 06:39 pm (UTC)Except in domains that are naturally at that level, the programmer shouldn't have to be thinking of thread management and where and when to thread; instead, they should be able to lay down the logic of a program without imposing order on its operations except where necessary, and let the compiler/interpreter do its own optimizing.
Something of a hybrid here are languages with a lot of matrix calculations and lazy evaluation (as perl 6 has, at least semantically). As long as you don't have a contract saying what order a matrix operator has to process stuff in, and can run lazy evaluations in parallel rather than sequence, you can get a lot of threading in under the hood without having to bother the programmer about it.