Functional Loop Hole

All functional languages in order to be useful in the real world on real computers, need a loop hole.

It's called side effects, baby! Side effects are wonderful things, despite what the pure functional wheenies would have you believe.

Side effects get things done. Print stuff to your screen, print stuff to your printer, draw graphics, write to a hard disk, write to the memory.

Without state, computers would be useless and pointless devices. State is king. I love state! I love SideEffects!

All functional languages have a loop hole so that you can produce SideEffects

Some supposedly pure functional languages are really strict and manage the side effects in special ways, like with monads.. But the bottom line is that side effects are mandatory for the computer to do anything useful, and state is also mandatory.

A quote that sums up this pattern is from NiklausWirth:

"Functional languages had their origin in Lisp. They have undergone a significant amount of development and change, and they have been used to implement small and large software systems. This author has always maintained a critical attitude towards such efforts. Why?" ...

"What is, or what characterizes a functional language? It has always appeared that it was their form, the fact that the entire program consists of function evaluations, nested, recursive, parametric, etc. Hence the term functional. However, the core of the idea is that functions inherently have no state. This implies that there are no variables and no assignments. The place of variables is taken by immutable function parameters, variables in the sense of mathematics. As a consequence, freshly computed values cannot be reassigned to the same variable, overwriting its old value." ...

"To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge. No hardware support feature can wash this fact aside: It remains a bad idea for practice. This has in due time also been recognized by the protagonists of functional languages. They have introduced state (and variables) in various tricky ways. The purely functional character has thereby been compromised and sacrificed. The old terminology has become deceiving."

{I'd argue that state better models the "real world". The real world has state and the "same" object can change its state. At least this is the way most humans perceive it, and the better a language/design fits WetWare, the easier it is for the WetWare to communicate with it. If it was merely about the machinery of the computer, then we'd find ways to work around them and improve them for FP if there were other clear benefits. We live with computationally "wasteful" GUI's for example, because the benefits of interaction are perceived to be worth it. -t }

[Functional programming languages are an embodiment of the recognition that every program represents a mapping, i.e., a function, from input to output. (In a typical application, input is often the combination of user-input devices like keyboards, storage devices like disks, and time; output is usually display devices, audio output devices, and storage devices like disks.) Unnecessary state, and uncontrolled state, only adds needless complication to effectively expressing the relationship between input and output. Functional programming attempts to avoid that needless complication, by strictly focusing on that representation of state that is absolutely necessary in a fashion that reduces its potential harm.]

How does one objectively measure "unnecessary complication"?
[There are various SoftwareEngineering metrics, such as McCabe's Cyclomatic Complexity metric. Such metrics would have to be applied comparatively, say to an application written in a procedural language vs a functional one. Of course, the results are unlikely to convince either camp in the eternal battle between the Concreteists who believe better languages are those that best leverage the computational machine vs the Abstractionists who believe better languages are those that offer higher levels of abstraction. The former favour imperative programming, the latter favour functional programming.]

Adding state in the form of e.g. monads to a functional languages is the reverse of adding a 'strict' or 'total' keyword to an ImperativeLanguage. Adding monads to a functional languages allows all their advantages like their clean semantics and tools to reason about correctness be applied. Adding a strict key-word to an imperative language is easy (just allow but ignore it), but actually enforcing it is a bit more tricky and actually deriving anything useful from it is futile without a suite of tools. And then getting the users to actually use the flag which gains them nothing is bound to be futile. So adding monads to a functional language seems to be the better way to go. Or else invent a better hybrid language from the beginning.

As a side note about the non-match of functional to biological reality: Some problems cannot be tackled by intuition alone and hoping so is simple minded. Good engineers always have to apply formal methods to be on the leading edge (until that reasoning has been automated).

And for the non-match of functional to physical reality: Even the cornerstone of state - file systems - is beginning to be built on functional approaches: btrfs uses a functional data structure to guarantee consistency (albeit implemented in an imperative language (C). I have no doubt that the advantages for consistency provided by STM (SoftwareTransactionalMemory) will earlier or later leak into hardware until hardware will be better suited to functional than imperative programming. -- GunnarZarncke

The development of FunctionalReactiveProgramming c. 1997 with several significant advances over the last fifteen years, has allowed functional programming to "bridge the gap" between stateless functions and pure, stateful programs - without compromising functional composition the way monads seem to. State is modeled with change over logical time. FRP is still inconvenient if you need open or extensible systems - i.e. if you don't know who all will be modifying state in advance, or don't know what state you'll need in advance, or if you need persistence across updates of the FRP code.

Consequently, I am trying to "invent a better hybrid language from the beginning" - by allowing `declarative` (commutative, idempotent) SideEffects, and using ObjectCapabilityModel for isolation, I can retain most benefits of functional reasoning while also supporting open systems and persistence.

Hi David. -- .gz

RE: the better a language/design fits WetWare, the easier it is for the WetWare to communicate with it. - t

Maybe so. But don't forget there is also a scalability issue for what will `fit` WetWare. Pervasive use of state seems to have a high complexity curve that can outgrow our WetWare even for small applications unless we apply a lot of careful patterns and self-discipline.

If it doesn't fit WetWare well, you have very similar issues. If the "managers" of a software system cannot grok and relate to it, it will become a boondoggle. And I am skeptical that a non-state model will usually be measurably and clearly less complex. Usually WaterbedTheory applies when comparing paradigms.

{Instead of merely noting that you are sceptical -- which is an opinion worth far less to the reader than what she paid for it -- you could offer something of value by providing evidence for your view. Ideally, it would be in the form of citations of peer-reviewed research or case studies, but any evidence would be preferable to a knee-jerk comment.}