Critical Programming Language Design

Recently, I've been immersing myself more in design and spending more time working with designers. This week I've been digesting an area called critical design and have attended a few talks from the design community (e.g., a nice lecture by Anthony Dunn of the Royal College of Art). Basically, we (PL designers) typically do affirmative design, which is characterized by the following goals:

  • Answer questions
  • Solve problems according to existing constraints
  • Designs for production and adoption
  • Tends to promote the status quo
  • Taken very seriously

In contrast to affirmative design, critical design works with the following goals:

  • Ask questions
  • Solves problems with unreal constraints
  • Can be a practice in alternate history (e.g., Steampunk)
  • Designs for society
  • Tends to disrupt the status quo
  • Can be seen as dark, sarcastic, funny, controversial, a parody

The only examples of critical design that I can find in PL are esoteric languages like BrainF*ck. Such languages seem like jokes, and maybe they are meant as jokes, but they have some merit.

Opinions on the role of critical design in PL research? Any good examples? I'm particularly interested in using critical design in PL design to break through the rut I think we are in today.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I disagree. I think PL

I disagree. I think PL design routinely encompasses at least points 1-3, if not points 1-5 of affirmative design. If you aren't doing so, then I might posit you're not designing a language but optimizing one. Most of the points of the first list aren't preclusive of the second list, except in the most narrow-minded literalist interpretations.

Disagree with what? I wasn't

Disagree with what? I wasn't making any strong assertions. I guess you are stating that PL design can encompass either, and I will agree with you, in fact, there is no real line in the sand; i.e., there is no "this is affirmative design" and "this is critical design." These are generalizations of design techniques and individual cases will be more blurry.

My mistake. I must have read

My mistake. I must have read too much into your post. But overall I think that PL design does entail critical design often, and if it doesn't, then it probably doesn't really qualify as PL design. After all, aren't we all trying to upset the status quo and point out shortcomings in existing designs?

To some extent, all design

To some extent, all design is trying to upset the status quo and is somewhat critical (no line in the sand). But given the realistic constraints that we usually design against, we tend to support and influence the status quo rather than envision new ones. The point of critical design, at least as I understand, is not to create a design that is successfully adopted, rather it is to spur thought, inspiration, maybe controversy.

Esoteric Languages

I think esoteric languages are exactly the application of critical design to PL design. Consider brainfuck. The original stated goal of the language design was to make a Turing-complete programming language with the smallest possible compiler. That is an unreal constraint - there is no measure of "small enough", there is no target usage. Just as small as possible. It certainly is disruptive of the status-quo in the sense that it doesn't really meet anybody's needs, and thus is unlike mainstream languages. And it clearly is viewed as a parody.

I would even go so far as to say that if you apply these principles of critical design to PL design, everyone in the PL community will consider your work to be esoteric languages, even if that is not your original goal.

I would even go so far as to

I would even go so far as to say that if you apply these principles of critical design to PL design, everyone in the PL community will consider your work to be esoteric languages, even if that is not your original goal.

This would match how critical design is often received in the mainstream. Common misconceptions of critical design is that it is parody, dark, only commentary, jokey, not real, and artistic.

VPRI?

IIRC, Alan Kay's group at VPRI are trying to build a complete system -- language, OS, apps -- on the rough order of 10 KLOC. This is a very strong "artificial" constraint, and a very humane one, as it suggests a good computer system should be the length of a good novel.

yes

of late i've become very depressed over how much damnable code there is, how much ascii must be sacrificed, whenever i try to do an even seemingly simple project.

part of it is the old saw about inessential complexities.

part of it is that actually nailing down precisely what it is you want to do is hard, you end up realizing that there are all sorts of things to specify that are generally hand-waved-over in natural language.

part of it is that trying to be orthogonal or flexible or abstract can end up requiring more boilerplate.

part of it is that i'm probably just not a good enough programmer.

part of it is that i'm probably using the wrong languages, or i should ideally first divine the right dsl to create.

etc.

it is something i wish i could (a) meditate on to the point where i could more explicitly tear apart things and categorize how chunks of ascii are being evil and (b) know what options there are both existing and under research that could deal with it.

in other words, more power to the VPRI folks.

examples of critical design

If BrainF*ck is an example of critical design its not a very successful one because it didn't disrupt much of anything.

Taking steampunk as a field of critical design, its disruptions have been potent. The asthetic it created helped to influence art communities like the Black Rock Foundation crowd (associated with Burning Man). Steampunk design conveyed and promoted a cynical mistrust of the reliability and virtue of the established economic order. It offered a positive vision of a technology less reliant on systems of global trade and massive infrastructure. The iconic image of a steampunk inventor might be a kind of mad scientist with welding goggles on his head working in a dark, greasy, workshop under the glow of hand-blown lightbulbs powered by homemade lead acid batteries kept charged by wind generators built from old car radiator fans and alternators and by a generator powered by biodiesel distilled on site from used fry oil collected from the dockworkers' tavern in the rough part of town.

Only, then that vision started to come true. As a side effect of these images taking off in political commentary art, at least around here, there is now a growing community of young (and older) new artists and organizers teaching and taking courses in glass blowing, welding, cutting and shaping metal, casting, improvisational mechanical engineering, leather work, and so on. The skills now (once again) starting to proliferate are being deployed to solve real world problems of how people cloth, shelter, and transport themselves. There are extreme examples like the local artist group that built themselves a colony out of shipping containers (and provoked a showdown over how building code regulations react to this new mode). There are less extreme examples like the significant number of contented bike riders I see who will probably never actually buy a bike rather than weld together an original design from scrap parts. Or the food resiliency activists building urban fish farm / hydroponic growing cycles out of low tech parts assembled in bespoke designs. Steampunk helped to make new ways to live and new kinds of career.

Brainf*ck never had quite that level of punch.

Some languages that might be better examples:

Unix itself and the "tiny languages" from Bell Labs were notoriously the product of something like critical design. A bit like Steampunk they originated as a critical questioning of conventional design efforts (mainly Multics) using all-but-discarded out of date computers. They rejected the heavy baggage of mainstream computing system design and looked for radical simplifications, specifically to empower very small numbers of programmers to be able to do what others were trying to do with very large teams. With C, the question posed was in some sense not "what is the ideal of a modern language" (you knew knew where to find PL/1 if you wanted it) but rather "what is a good language that the few of us can quickly implement on our own and that can run comfortably on these tiny machines?". In a way sort of like the way Steampunk gave rise to a virtuous cycle of skill development and a possible disruptive shift to real world ways of solving problems, C and the new unix created an energized group of programmers who then went out in search of problems they could solve cheaply and well, and that everyone else was neglecting. From that literal wandering around Bell Labs looking for researchers in other areas to help came the tiny languages movement with languages like sed, AWK, troff, grap, chem, m4, make, and quite a few others that didn't get as wide a circulation. So here was the unusual practice for its time (and to some extent still) of making language design one of the tools in the toolbox for solving real world problems (as with chem being designed to aid the typesetting of diagrams of molecules).

The individualist, mad-scientist language-happy approach the Lab demonstrated went on to inspire Perl. After a little time, the unix approach was mainstream and increasingly applied in affirmative design contexts.

The new mainstream was again disrupted in the 1990s with a new generation of languages, perhaps the most famous and successful being Python. Again, it was an individual mad-scientist aesthetic at first, and a reaction against the unwieldy heft of what the more traditional unix tools had become. It (and a few others) proliferated wildly over the net and again, changed economies and ways of life.

Other older examples: Smalltalk and Scheme.

Scheme did not start with a well defined problem to solve, as nearly as I can tell. It started as an attempt to critically examine the essence of lisp in the context of then new programming language theory and compiler and interpreter writing practice. It may not have had the same kind of global adoption as the unix tools but it did bring about significant shifts in computer science pedagogy as well as intellectual and economic shifts (e.g. the PLT team).

Smalltalk has not fared terribly well in terms of direct adoption either but it again started as a small team asking critical questions and starting with a blank sheet of paper to see what they could build rather than starting with a few well known questions to answer.

I concur, plus speculation

That is an excellent presentation of "critical design" in the PL space. So much of what you talked about eventually went mainstream that I think many forget how subversive and counter-cultural the initial processes were.

One pattern that seemed to come up in both contexts (PLs and steampunk) is subversive re-use. Each time, people took a problem that is already well-known, grabbed materials and techniques already established, and used them in a way people weren't expecting. Also, they seemed to be solving meaty problems they had real-life familiarity with. Steampunk/maker-style provision of food, clothing, shelter. Unix-style provision of text manipulation, system access and manipulation. Smalltalk aimed at separation of concerns and children's education; Scheme was originally just a platform to play with the Actor model. The constraints were often arbitrary or accidental (Unix on a PDP-7, Smalltalk's "page of code" implementation on a bet). Each revolution made subversive use of materials at hand to solve problems in a new way.

As mentioned, the academic world has plenty of disincentives towards this kind of experimentation. Most of these are overt, such as the publication-counting measure that obviously encourages incrementalism. I think there are also subtler influences. For example, reserch that "merely" recombines previous approaches to solve known problems don't get huge kudos, especially when their value takes time to realize or is realized simply through diffusion of a cognitive shift.

To connect this back to the original post: academic focus and the "slow burn" likely informed the generalization that "we (PL designers) typically do affirmative design". That is plenty true under those restrictions. The examples above came from industrial labs or academics "just getting something done". A focus on rapidly publishable academic results all but eliminates time for subversion and practicality. Even Scheme was published in memos and tech reports-- it was just a cut-down blend of Lisp and Algol features.

So, what about seeing more of this "critical design"? One answer is to change academics. Another is to reconnect with the industrial space. Small industrial groups can more easily surmount the political hurdles of "weird" solutions. There's no larger community to please-- all you need is to convince them of an idea's usefulness.

This was something I hadn't

This was something I hadn't thought about: back in the 60s, 70s, and even much of the 80s, computers were not yet mainstream, tools and languages were still immature, perhaps PL designers had much more freedom back then, but they were still working to satisfy immediate needs.

At first glance, I wouldn't think that Perl, Unix, Python, Smalltalk, Scheme, would be classified as critical design because they were designed first and foremost to be useful and functional. Critical design is more about designing to inspire more thought: intent is important. But then I'm lacking in historical context; I'm only seeing the result of those languages and I don't know what the intent of the designers were.

Speaking about Smalltalk, Jonathan Edwards has a nice parody of a PC evaluating Smalltalk today at What if Smalltalk were invented today?.

Scheme was not designed to be immediately useful

It was designed to explore the Actors model by writing a tiny Lispish interpreter that would include actors. Its expansion into a full Lisp dialect was based on the post hoc discovery that actors and procedures had the same implementation, and therefore were the same thing.

Scheme was specifically designed to be not "too useful"

Kent Pitman:

I certainly sat in lots of Scheme design
meetings where I pushed for obvious things like branch cuts, error
handling, and other "useful" things and was told that such things
would either (a) increase the size [i.e., page count] of the spec
[something some authors absolutely were not prepared to do] or (b)
make the language "too useful" [thus meaning too many people would
flock to it and it would be the end of the designers' ability to do
the things to the language that _they_ wanted to do].

Great link, thanks!

Great link, thanks!

both affirmative and critical design seem necessary

Most programming language design evolves from some existing language; perhaps not directly but at least conceptually. Java was very much derivative of what preceded it. Few languages are actually revolutionary and those that are often only plant the seeds of revolution so subsequent language design is once again seen as evolution rather than revolution.

As a consequence I think the majority of language design is going to be affirmative. But, critical design would still play an important role. Any time you need to explore the design space, critical design seems unavoidable to me. So it seems to me that the distinction is perhaps not as useful in understanding programming language design since I doubt you can find examples where a language took a pure design approach (either affirmative or critical). So I find the distinction interesting but perhaps not real useful (to me).