The Computer Is a Behaving Machine, Not a CalculatorThe idea of a computer as a calculating machine has a long history. Ever since the Persian mathematician Muhammad ibn Mūsā al-Khwārizmī invented the algorithm (the word algorithm derives from 'al-Khwārizmī) in 825 AD as a problem solving method, people have dreamt of creating machines that could perform long and tedious calculation sequences automatically. Charles Babbage was the first to design and build (partially) such a machine. Babbage’s friend and mathematician, Lady Ada Lovelace, became the world’s first programmer for having written the first computer program (table of instructions) for Babbage’s analytical engine. I have nothing against mathematicians wanting to build function calculators. But I do have a problem with mathematicians wanting to force the world to adopt their antiquated concept of what a general purpose computer should be, especially in the 21st century. The computer is not a calculator, for crying out loud. It is a behaving machine. Calculating is just one of the many types of behaviors that computers can perform.
A Computing Model for the 21st Century
The idea of a computer as a machine for calculating sequences of operations (algorithms or threads) is fundamentally wrong. It is the primary reason that the computer industry is in the mess that it is: software is buggy, expensive and hard to develop. The problem with software will disappear only when the computer industry shakes its addiction to the algorithmic software model and wakes up to the fact that a computer is not a calculator. A computer program should be seen as a collection of elementary parallel, synchronous, reactive, behaving entities that use signals to communicate with each other. The algorithmic model has served us well in the last century but now that the industry is transitioning from sequential computing to massive parallelism, it is time to switch to a new model, one that is worthy of the 21st century.
If you think that functional languages like Erlang or Haskell should be used for concurrent programming, you are a thread monkey. You are a hindrance to progress in computer technology. Why? Because you are encouraging multicore CPU manufacturers like Intel, AMD, IBM, Sun Microsystems, Freescale Semiconductor, Tilera and others, to continue to make multicore CPUs that support coarse-grain, thread-based parallelism at a time when they should be trying to build fine-grain, auto-scalable and self-balancing multicore CPUs. You people are promoting what I have been calling, the age of crappy concurrency.
Inadequacy of Functional Programming
The market wants super fast multicore CPUs and operating systems that support fine-grain parallel computing. It wants systems that are bug-free and easy to program. Do functional languages provide what the market wants? Not even close, in my opinion. Sure, they are a better choice for thread-based parallelism than imperative languages but, as I explained in a previous article, they lack something that is essential to reliable software and that is the ability to automatically find and resolve data dependencies, a must for reliability. This feature can only be implemented in a purely reactive, deterministic and synchronous system. And please, don’t give me the crap about Erlang being great for writing reliable concurrent programs. The whole idea behind concurrency in Erlang, as stated by Joe Armstrong himself, is to provide a mechanism for fault tolerance. Fault tolerance assumes unreliability. It does not prevent it. FP is inadequate for safety-critical applications for this reason.
In conclusion, my advice to FP fanatics is to promote functional languages for what they do best, solving math functions. Do not advertise FP as the solution to the parallel programming problem. It is not. Crappy parallelism, yes. But true fine-grain parallelism, I think not.