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