States and complexity in programming – why functional programming helps to improve your code

The human brain is very, very bad at keeping track of states. Especially for code maintenance states are hell, in particular if you are not the original author of the code, and even then. Even if there is ample and up to date documentation around, trying to understand states of a program is very difficult. States don’t match well to the way the human brain is thinking. Computers, however, excel at it. On the other hand, humans are quite good at abstracting functionality, finding commonalities and patterns as well as following an explicit program flow, in particular if the code uses telling function and variables names and generally a coherent coding convention. Abstraction and pattern recognition in code is something that computers don’t do really well at all.

A programming language should therefore reflect this observation and provide efficient tools to use this human ability. Functional programming is a thinking tool and programming philosophy that helps the natural tendencies of the brain to abstract. While functional programming can be applied in practically every language that supports functions (essentially every modern programming language), some languages try to provide suitable and expressive syntax that allow to move much further up on the abstraction scale whereas other languages, allow only elementary functional programming and make life for the programmer more difficult than necessary. Continue reading

The essence of (functional) programming

Functional programming seems to be a hotly debated issue among some programmers. On the one side there are the more academic, computer sciency proponents, who claim that all programming should be functional, since it supposedly reduces bugs and you can reason about the program and do all kind of fancy formal proofs. These proponents also created several purely functional languages to show the world how awesome this way of programming is (including Miranda, OCamML and Haskell). On the other side there are the self-proclaimedly more pragmatic  programmers who bash functional programming as being unusable for any kind of reasonable work in the real world – work that is actually ending up being used by real users and not just as unintelligible papers in the ivory tower.

Who is right? I don’t know. I find the whole discussion moot, so I won’t try to take a side, since I both feel firmly grounded in the real programming world and still use concepts from the functional programming world.

For the sake of a better understanding what the whole thing, in my view, is about, I will introduce a different nomenclature for common programming terms. It was first used for APL-like languages and was introduced originally by Kenneth Iverson – a Turing award winner, best known for his contributions to mathematical notation and programming language theory. His paper Notation as a tool of thought  (Comm. ACM 23 (8): 444–465) is worth reading several times. Continue reading