Quoted by the article: Computers function by executing a series of instructions, at the level of machine language, which perform calculations and manipulate mem

Quoted by the article: Computers function by executing a series of instructions, at the level of machine language, which perform calculations and manipulate memory and I/O. Today, our computers increasingly have many cores, and many threads. On top of that, we often have to co-ordinate between dozens of separate servers, each with their own memory and I/O. In this environment, manipulating memory becomes tricky, because you must co-ordinate among anything from 2 to 2,000 simultaneous processes. This raises a whole host of issues: (a) direct interaction using locks and semaphores is hard to get right, (b) the memory in question may be located on separate machines, and (c) if you're running at a billion instructions per second with a 0.1 second lag between machines, simply defining "simultaneous" can give you a headache. And with the rise of GPUs for blazingly fast general-purpose computation, even the hardware itself is becoming deeply functional. We've come up with a whole host of strategies for tackling this problem: Worker queues, MapReduce, Erlang-style message passing, shared-nothing architectures backed by databases, and even eventually-consistent NoSQL systems. Each of these, in some fashion, represents a retreat from the old-school model of a single process manipulating global memory. In this world, functional programming adds one more tool to our kit. It treats mutation and global memory as a special case, and gives us a new vocabulary for working in this world: map, reduce, transactional memory, monads, and local state (via Haskell's ST monad, for example). Even if you work in traditional OO languages, this functional vocabulary will give you new ways to tackle hard problems.