It never ceases to amaze me how effective education can be at brainwashing people. Skinner was right about conditioning. Not that this is necessarily bad, mind you (that’s what religion, which includes scientism, is all about), but there is good brainwashing and bad brainwashing. Here is a case in point. Brainwashed functional programming fanatic namekuseijn (also calls himself Piccolo Daimao) claims that a computer is fundamentally a mathematical machine and that everything that a computer does can be seen as a function that returns a value. In response to a comment Daimao posted on my blog recently, I wrote the following:
Truth is, computing is about behavior. And behavior is about sensing, acting and timing. This means that a computer program is a collection of elementary sensors comparators), effectors (operators), environment (variable data) and a timing mechanism. That is all.Daimao replies:
Anthropomorphizing the Computer
-elementary sensors (comparators)
that seems to me like a function taking 2 or more arguments and producing as result one of them. Or a multiplexer.
it's a function which takes arguments and returns results. In low level Von Neumann machine, this may mean the result of the computation is put into a register or a set of registers.
-environment (variable data)
flow of control: you start with a function and goes evaluating it step-by-step.
What Daimao will probably never grasp (brainwashed people rarely change their minds) is that what he’s doing is anthropomorphizing the computer. In his view, the computer doesn’t just do math, it becomes a mathematician: it takes mathematical arguments, performs calculations and returns mathematical results. Never mind that a computer is merely reacting to changes by effecting new changes. And, when you think about it, effecting changes is nothing but flipping bits (electric potentials). The math stuff is all in Daimao’s mind but don’t tell him that. He’s liable to go into an apoplectic fit.
Of course, it will never occur to Daimao that what he refers to as “taking arguments” is not a mathematical operation at all but effects carried out by the computer: some bits are flipped in a memory area that we call the stack and in a special register that we call the stack pointer. Likewise, returning a result is another stack effect carried out by the computer. Daimao comes close to seeing the truth (“the result of the computation is put into a register or a set of registers”) but he dismisses it as “low level”. Again, putting something in a register has nothing to do with math. It is just another effect carried out by the computer.
Forget about Daimao’s notion that data variables (changeable environment) constitute “function scope” (it’s just more silly anthropomorphizing). Right now, I want to address Daimao’s assertion that timing is just flow of control. This is something that is close to my heart because I have been saying for a long, long time that timing is the most important thing in computing. My primary claim that computing is strictly about behaving and that an elementary behavior is a precisely timed sensorimotor phenomenon. Timing is to computing what distance is to architecture. At least, it should be.
How does flow of control (another term that stands for algorithm) guarantee action timing in functional (math-based) programs since math is timeless to begin with. There is nothing in a math operation (taking arguments and returning results) that specifies its temporal order relative to other operations. Of course, one can argue that the algorithm itself is a mathematical timing concept but I beg to differ. People have been performing step by step procedures long before mathematicians thought about them as being part of math. Note that executing an algorithmic program consists of performing all sorts of sensorimotor behaviors such as incrementing a pointer, copying data to registers, performing an operation, copying data to memory, sensing a clock pulse, etc… In reality, everything in a computer is already signal-based (change-based) but the ubiquitous math metaphors make it hard to see. Every behaving entity (operation) sends a signal (clock pulse and index counter) to the next operation in a sequence meaning, now it’s your turn to execute. The problem is that signal flow (communication) within a function follows a single thread and cannot split into multiple threads. This is a big problem if you want fast, fine-grain parallelism, which is the future of computing.
Implicit vs. Explicit Temporal Order
The point that I am driving at is that there is nothing in functional programming that allows a program to make decisions pertaining to the relative temporal order (concurrent or sequential) of elementary operations. Temporal order is not explicit in a function; it is both implicit and inherently sequential. Explicit temporal order is a must for reliable software systems because it makes it possible to build deterministic parallel systems. Explicit temporal order simply means that a system is reactive, that is, actions (operations) are based on change (timed signals). A purely reactive system is one where every action occurs instantaneously upon receiving a signal, that is, it executes itself within a single system cycle. Since there should not be any changes in the temporal behavior of a deterministic system, timing watchdogs can be inserted in the system to alert the designer of any change (could be due to hardware failure or a modification to the system software). Deterministic timing makes for super fast, fine-grain parallelism because it gives small parallel processes access to shared memory without having to worry about contentions.
Reactive Behavior and Data Dependencies
The future of computing is not thread-based parallelism but fine-grain, self-balancing, parallel, multicore CPUs using an MIMD execution model. Other than the fact that functional programming encourages the continued manufacture and use of coarse-grain parallel computers (see The Age of Crappy Concurrency), the biggest problem I see with functional programming is that it makes it impossible to implement a mechanism that automatically discovers and resolves data dependencies, an absolute must for reliability. This is only possible in a purely reactive system. I will not go into it here but suffice it to say that functional languages should not be seen as general purpose computer languages and FP must not be promoted as a software model. The lack of timing control and reactivity makes FP inadequate for safety-critical systems where software failure is not an option.
In conclusion, I'll just reiterate my point. Everything in computing is not a function. Everything is behavior.