Recently, we've been told over and over how the world of programming is changing due to the slow but significant change in the CPU and hardware trends of the industry. We have people like
HerbSutter telling us that CPUs will not become faster in clockspeed or larger in cache size, but rather they will become more multithreaded and offer more specific performance boosts.
The
CellProcessor is a glimpse into this future, as are the
DualCore systems that are hitting the market.
Lots of people complain that
MultiThreadedProgramming is very hard, but it's really only much harder from an
ObjectOriented standpoint. OO makes an assumpted that all messages happen in a sort of faux-asynchronus fashion, and in practical experience, I find it harder to map threads onto this context.
FunctionalProgramming, at least in my head, seems like an easier paradigm to map onto
MultiThreaded programming because it encourages a lack of state.
As we are required to adapt to new hardware and care more and more about threading and data-prefetching ourselves,
IsFunctionalProgrammingBecomingMoreImportant? As in, appraching mainstream and as the "next OO"?
ActorOrientedLanguages are the multithreaded version of the more mainstream OOP languages.
I don't really get the above. True,
FunctionalProgramming of the side-effect-free kind potentially makes
MultiThreadedProgramming actually trivial, but I and others have been doing OO
MultiThreadedProgramming for decades, including in apps with GUIs, and in fact I find that judicious addition of threads actually makes it easier to get apps to behave correctly, whether OO or not. I think
MultiThreadedProgramming is indeed considered difficult, but the tie-in to OO is new to me.
The "appearance" of method calls being async isn't real, after all, unless you mean GUI callbacks in particular.
And indeed, note that the original OO language, Simula-67, was inherently multithreaded (to support simulations), and they seemed to do ok. :-) Smalltalk was going in the same direction early on, and shifted to map async thread messages into synchronous function calls only later (due to influence on
AlanKay from Sussman's research on continuations at MIT). --
DougMerritt
See
FreeRideArticle,
FlowBasedProgramming