May 2, 2010

Postmodern programming

Before the idea of postmodern programming can begin to be investigated, the question of whether anything like modernist and classical programming even exists needs to be asked.

It's not surprising that the question of how to define postmodern programming is reframed by the OO contingent (reflecting their ignorance as much as their immature self-obsession) as literally "what comes after object-orientation?" That is a silly question to ask when you don't know what object-oriented means or what came before.

James Noble and Robert Biddle attempted to address the issue in their Notes on Postmodern Programming, but focused on the act of writing programs and left the question of programming paradigms unexamined.

One possible interpretation gives surprisingly straightforward definitions: the development of the idea of algorithms constitutes the age of classical programming, while procedural and data abstraction, being the rationalization of the construction and application of algorithms, constitute modern programming.

What then is the narrative of a modern program? The evaluation strategy. Algorithms are executed in steps. Modernist programming promotes rationalization in laying out these steps. Postmodern programming rejects the linear evaluation strategy.

Curiously, we can arrive at the same conclusion by framing the relationship between procedural and functional programming in terms of a dialectic:

The thesis of procedural programming is the description of programs in terms of time (sequential execution of instructions, or branching) and behavior (the semantics of instructions), as entities operating on data - object identity, and state of addressable (nameable) places (registers, variables, arrays, etc.).

Functional programming presents a (quite literal) antithesis: programs are described in terms of data - identity (named functions) and state (first-class functions) - and operate on time (persistent/immutable data structures) and behavior (monads).

The synthesis is a nondeterministic, reified (homoiconic), first-class program. The program exists for the sake of itself, becomes the object of study and center of efforts. The computational narrative of the evaluation strategy escapes control, and so from the point of view of the programmer becomes irrelevant.

How, when, and why certain parts of the program are evaluated becomes subjective.

Perl wasn't the first postmodern programming language; Prolog was.

Non-determinism as the rejection of computational narrative and the reification of time arise naturally from physical constraints when attempting to reason about concurrency. Most of the modernist concurrency techniques concern themselves with maintaining what I call the global state illusion, or quite literally forcing a single narrative on a distributed system. Not only does the current state of the system remain unknown and unknowable, but its past history permits an exponential number of equally valid, relative interpretations.

Rich Hickey's 2009 JVM summit presentation explores these concepts of concurrency and time in a thought-provoking manner.


Anonymous said...

A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''

The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''

Andy Wingo said...

Amusing post; fun, but shaky at times (Prolog?).

Unfortunately I come not to heap on praise for the post, but to react to the smarmiest "parable" I have heard in a long time. Way to go, Anonymous.