Functional programming has been all the rage lately. It seems like everywhere you look, someone is going on and on about how wonderful Clojure is, or how much they love Erlang, or that there is such a thing as F#. Yet surprisingly few have heard about an intriguing alternative known as Dysfunctional (or FUctional) programming.
Dysfunctions
At the heart of Dysfunctional programming are, of course, Dysfunctions. These little nuggets of code have a bunch of fun properties that collectively put the “FU” into dysfunctional*. Let’s take a closer look.
1. Mutate Me, Please
One of the core concepts in Functional programming is state immutability. This principle demands that functions avoid side effects by not changing (mutating) state.
Dysfunctional programming takes a very different approach to managing state. It highly encourages (even forces) you to mutate state as frequently and as violently as possible.
Every Dysfunction gets a special hidden property called State. This property gets instantiated for all Dysfunctions in the application (whether they’re called or not) and is kept alive for at least two years.
Whenever a Dysfunction executes, the runtime automatically updates the State with a random value. That value could be the duration of the execution, current temperature in Dubai, or even a playful “Runtime was here” message.
The State can also be explicitly mutated by the user. Below is a small sampling of over 200 methods one can call on the State object:
Grope()GentlyMassage()RoughlyMassage() // should only be used on rare occasionsWreck()
The runtime also maintains a special global property called SuperState which is updated constantly, at random intervals.
2. Dysfunctions Are Last-Class Citizens
Functions in functional programming are first-class citizens. They can be passed around, returned as a result of another function, etc.
Well, Dysfunctions have none of these properties. Not only that, they’re not even allowed to take inputs unless suffixed by the keyword please:
dysfunction sum(a please, b please)
An important thing to note here is that the runtime can arbitrarily decide to grant or deny the request. In the case of denial, an error code of DONTTHINKSO_ERR is returned. Needless to say, this error code must be handled properly by the Dysfunction or else the program will crash.
3. No Recursion, Ever
Unlike functional programming, dysfunctional programming strictly forbids recursion. In fact, if the compiler ever sees a reference inside a Dysfunction to itself, the entire offending file is immediately blanked out and the computer is forced to reboot.
Origins of Dysfunctional Programming
Dysfunctional programming was originally developed in the early 60s by the Special Activities Division of the CIA’s National Clandestine Service. The military was looking for a programming language that could be used as a weapon in psychological warfare (The prevailing wisdom at the time was that most people in the future would be programmers and could therefore be targeted.)
After seriously considering (and ultimately rejecting) FORTRAN and Lisp, CIA decided to develop a new language based on the Dysfunctional Programming paradigm. This new language (code named SnuggleBunny) was specifically designed to subject the developer to extreme mental anguish.
Early tests on unsuspecting subjects proved extremely successful. The combination of nearly impossible to track down bugs and a highly capricious runtime drove a number of participants to a complete nervous breakdown. A small group of the few remaining survivors went on to develop other languages.
The CIA eventually gave up on the project once they realized that most people could barely use a computer, much less program one. Dysfunctional programming fell out of vogue until the late 90s, when it was rediscovered by hipster devs looking for a way to program ironically.
* Incidentally, probably the most popular language that implements dysfunctional programming concepts is called FU.
You May Also Like
