Scott- it was difficult (for me) to tell from the reading provided whether functional programming would require a different hardware configuration. Whether it does or not, why do you think it is that thirty years later we are still using the "von Neumann" style in both hardware and software when people such as the author of the linked article and, (I believe) yourself feel that the functional programming model is far superior?
No, it doesn’t require different hardware. There are a number of functional programming languages out there that compile to ordinary machine code – my drug of choice is Haskell, but OCaml is another popular choice. They might benefit from different hardware, though. There’ve been some research projects into the matter, with mixed results.
The von Neumann model is prevalent, I think, for two main reasons. First, it’s readily evident how to realize it in actual hardware – much of physics is about understanding states and how they evolve over time, so building a machine that encodes a programmatic state and evolves it in a controlled way is something of a "no brainer".
Second, since it’s easier to make von Neumann machines, they came first – and the earliest programming languages were basically von Neumann-style assembler languages. The evolution of the modern procedural programming language develops in an obvious way from there – someone got smart about translating algebraic formulae directly from algebraic notation into the corresponding machine code, which ultimately led to FORTRAN (Backus led the team that originally developed FORTRAN).
Then Dijkstra’s famous "GoTo Statement Considered Harmful" paper paved the way for the "structured programming" revolution, which gave a more sane shape to the way programmers control state manipulation. The next major revolution in programming was the OO-paradigm, which pretty much enshrines the von Neuman separation of state and control as religious doctrine.
So the combination of direct hardware support, and the relatively slow growth of compiler technology for functional languages are largely responsible.
In today’s world, where hardware costs have shrunk so small that some are talking about desktop computers going the way of cell phones – free with a two year subscription to an ISP – there’s much less need for programming languages to closely parallel hardware architectures. In fact, the dominant theme in most of the programming literature these days is about how we make our programming languages more "expressive".
Programs are a way of expressing ideas. Through most of the history of computing, our languages have been primarily ways to express those ideas in ways that are simple enough for computers to understand. We’ve always looked for ways to express more sophisticated ideas – but the more complicated an idea is, the harder it is to express in those simple terms. So another approach is to make the compiler smart enough to translate ideas expressed in sophisticated ways down into those simple hardware terms.
Of course, the main language we humans have developed in which to express our most sophisticated ideas is mathematics. The procedural languages that have dominated programming are only weakly connected to mathematical expression – little more than simple algebraic expressions. Functional languages bridge that gap.
I think the down side is that functional languages have a rather formidable learning curve. Maybe even more so for someone who’s very comfortable with the procedural paradigm.
Software tool makers work hard to propagate a myth that, if you have the right tools, almost anybody can program. As we move toward the future, we face more and more complicated programming problems, and that myth becomes less and less credible. A game like Halo 3 represents incredible cutting edge engineering work. Managing complexity is the single most fundamental problem in software engineering, and we’re rapidly reaching the limits of how well the OO-paradigm can cope with it. It’s not a problem of tools, it’s a problem with how we’re able to express problems and solutions.
Hm. Like some of my posts tend to do, this is getting long. :)
I have in mind an article on this very subject – what functional programmin is all about (Backus’ paper is 30 years old – things have changed a bit), why functional programming models are superior, why we haven’t adopted them, and why I think we will be adopting them in the not too distant future. I hope what I’ve said here touches on some of the main points, and whets your appetite for more. :)
Welcome! OmniNerd's content is generated by nerds like you. Learn more.