Dysfunctional Programming 101

BY ALEX TATIYANTS

March 5th, 2012

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:

That’s why it is said that laughing is effective to cialis discount online improve one’s cardiovascular health and erection issues. Benefits of Xanogen Increases your sex desire and drive. cialis canada generic In addition to its extreme antioxidant properties, Organic Acai also contains substances beneficial to human health and looks: amino acids, healthy fats, anthocyanins and 26 different vitamins and minerals. brand cialis australia In the event you expertise different prescription canada de cialis because of your current hair.
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 immidiately 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:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 8 comments so far. Care to add yours?

  1. Prison of Mirrors says:
    March 6, 2012 at 2:20 pm

    Haha nice post, very well written.

  2. martani says:
    March 12, 2012 at 12:23 pm

    Hahaa, aweseome 😀

  3. Sebbert says:
    March 24, 2012 at 5:59 pm

    Hahaha, this inspires me to write a dysfunctional compiler 😛

  4. Robert McCall says:
    July 30, 2012 at 9:06 pm

    [This plagarizes my own post from some time ago for http://skipoleschris.blogspot.com/2012/04/life-without-objects.html where it addressed the author’s point that ‘Mutable State Causes Pain’ which is, at its heart, the same pure-functional perspective being espoused here.]

    Good Afternoon, Alex,

    I apologize in advance for the super silly sarcasm but I’ve got to get this off my chest:

    Correctly dealing with mutable state *is* painful exactly because coordinating sets of mutable state *is* difficult to perform correctly, but that’s OK because that’s what we do! We’re programmers and the machines our programs run on are stateful layer upon beautiful stateful layer of mutable state including (but probably not limited to): disk sectors, banks of RAM, microprocessor registers, stacks and i/o ports (those evil b4stards at Intel, how dare they!), database object definitions and their accursed rows and columns, screen pixels, keyboard and mouse key/button state, mouse location and wheel state, a certain percentage of disk media, external port connector plug state, amplitude per time slice of both speaker and microphone volume, and, horror of bloody horrors: even our beloved programs have had this unholy SDLC abomination foisted upon its precious construction, deforming with wave after wave of corruption until it is unrecognizable even to its own maker.

    Actually, upon further review, I’m tempted to believe that maybe the reason no one appears to be anywhere near solving the “software is just fscking *AWFUL* crisis” is that the best and brightest — err, well, at least the most tenured and endowed (with *grants*, people!) — have decided that Earth’s best hope lies in a model of computation that prescribes the implementation of a function that modifies a single array element’s value to be by basically cloning the array, element-by-element, in such a way that the element to be modified is carefully substituted for the element it is to replace after which the new, cloned array is returned which will be used to create a new let-binding with the same name as the original array’s let-binding thereby reducing the ref-count of the original array whose unattached value will, at some future time, be detected by the background garbage collector process that will recursively (and most carefully in our multi-core world) traverse the old array’s elements trying to free any individual elements (which as a first approximation seems to be exactly 1) that have no references save the soon-to-be wiped array head itself.

    If ever a concept deserved a stupid-ugly super run-on-sentence, it’s that big ball of steaming mud that can be quite simply and effectively be implemented via this time-tested algorithm:

    1. copy the new value’s memory bytes over top of the memory bytes of
    the ith element of the array
    2. optionally reduce the array’s allocated size (b/c we’re fancy)

    May the record show that the least of a C programmer’s problems are related to their use of constants; as a result, the petitioning citizen is requesting a permanent injunction on further mention of ‘immutability’ in any discussion about how to attack the problem that the ‘percentage of programs that are crap’ is clearly outpacing Sturgeon’s Law by at least 9%.

    And let it also be said that having immutable objects *is* surely a nice way to ease the pain of designing concurrent systems; however, it’s also kind of a cop-out ultimately because all (?) of the fundamental concurrency primitives (semaphores, cmp-n-xchg, monitors, locks, …) are *defined* by how they rigidly control their mutability or prevention thereof. One must ask if the final system cost won’t be far greater after paying the final bill that includes all the deferred costs from using immutable objs.

    And because the horse is not dead enough: If it ain’t changing, it ain’t living.

    Peace,
    Robert McCall
    “Lasting peace & happiness for *ALL* human beings.”