page updated on August 24, 2017

Theme, Pragmatics, and Purpose in Programming Language Implementation

The first season of Heroes is an example of strong storytelling and high-quality genre television. (Some combination of the writer's strike shortening season two and the network attempting to milk the magic of the first season for more commercial appeal made the subsequent product less appealing.) Heroes's first season motto of "Save the cheerleader, save the world" was charmingly direct and it made the stakes both human (protect a young woman's life) and expansive (avert a global catastrophe).

Superheroes and Purpose

A villain like Sylar may not need a single mustache-twirling reason to nefarious schemes, but a realistic hero needs an obvious motivation. Without the desire to use his great power responsibly (and the shame of disappointing the memory of his Uncle Ben), Spider-Man is just another selfish teenager with super powers. He's only interesting and believable in the context of the story because his reason for trying to be a hero propel him into heroic circumstances.

Superman may serve as another example. A nigh-indestructible alien who can fly, leap over tall buildings, laugh as bullets bounce off of his chest, and smack bank robbers with cars is in no physical danger. Unless the Superman story went into emotional danger (the juxtaposition of his secret identity being an average human being, the conflict between a farmboy from Smallville, Kansas in the big city, the need to protect those he loves who are physically vulnerable), the story has a purpose. More than that, Superman/Clark Kent must justify his existence as the sole survivor of a dying alien world by using his powers to improve the peace of his adopted world.

Superman has a reason to be Clark Kent. Peter Parker has a reason to be Spider-Man. Without those reasons, the characters have no dramatic agencies, and any stories about them would jerk around the characters for the sole purpose of plot, and the stories would be unsatisfying. They wouldn't resonate with the audience, because we couldn't relate to them.

Software and Purpose

Any software project without users—without a specific reason to exist—is in danger of becoming a perpetual research project.

There's nothing wrong with programming language research. If anything, the world needs more of it. Yet the world needs more programming language research to improve existing and future programming languages which will be used to create real software for real users.

A superhero is only interesting when he or she is relatable (a teenaged outcast, a person caught in a moral quandary, an average person expected to make extraordinary decisions) and when he or she has a purpose (the source of verisimilitude of action).

A programming language is interesting in practice only when you can do things with it. JavaScript would be a dead end as an extension language except for the fact that it's installed on more devices than anyone can count. PHP would be a has-been templating system except for the fact that it's still the simplest way to do server-side programming. JavaScript and PHP didn't win on their technical merits. They won because they were good at their intended purposes.

Theme, Counterpoint, and Reference

If a work is to stand as a coherent artistic whole, its themes, points, counterpoints, and any extratextual references need to resonate with an intended harmony. This helps to establish a sense of place and the verisimilitude that distinguishes between an effective story and the clunky, plot-fisted meandering mess that is most superhero stories (or political writing or Internet video comments or political commentary).

A reference may refer extratextually for purposes other than making a postmodern extratextual reference. Even though irony is the death of all things sincere and critical, a true artist may weave a rich tapestry of common and uncommon culture to allow the viewers of an artistic work to find deeper meaning, not just in the work's connection to a cultural milieu or school of expression, but in the unique personal viewpoint a viewer may bring to the work.

A superhero needs a purpose, but a regular hero (or non-hero, or anti-hero, or a villain such as Sylar) also needs something deeper than the desire to collect the magical frozzles to take over the world or to get through the day. The bigger the story, the more characterization you need to justify the existence and actions of the characters. (Yes, the length of the story matters. Only the most hard-boiled deconstructionist would bring the weapons of extratextual criticism to bear on a single-sentence story "The dog played with the ball.")

For example, the dark anti-natalism of True Detective's Rusty Cohle refers to the work of Thomas Ligotti (see especially The Conspiracy Against the Human Race. A handful of Ligotti and Lovecraft fans raced to their keyboards to praise what they considered to be the show's obvious paean to a dark and supernatural mythos, eagerly awaiting a revelation of elder gods and bloody sacrifices at the heart of the show's mystery. They were, perhaps understandably, disappointed by the ending of the series which proved that it was always about the characters and interactions between the two lead characters, as the show revealed little about the beliefs of the secondary characters involved in the murders.

The show was always about the characters of Cohle and Hart.

Cohle's Ligotti references serve two primary purposes. One, to express the anti-natalist theme of this character and his worldview. Two, to establish a sense of place in the real world where Ligotti and his perspective exists within the realm of the show. That secondary purpose is minor but important. For the same reason the show is set in Louisiana; it would make less sense if it were set on Wall Street, because there's no sex-and-religion haunted bayou full of poverty and broken families and a syncretic history of familial sins.

The Ligotti reference could have been any bleak anti-natalist. It could have been unique anhedony written fresh from whole cloth. It was a Ligotti reference because Ligotti expresses himself so effectively—yet the purpose is always (eventually) to demonstrate how Cohle is both haunted and motivated by the death of his daughter. Consciousness serves no other purpose than the human race bleakly mocking himself, as he sees it. The destiny of a child is suffering. What has happened before will happen again. He sees no exit from time's flat circle.

It's not important that Cohle paraphrase and then directly quote Ligotti. What's important is that viewers learn something of his character—who is is, what he wants, what he fears, how he feels—from his words. "My daughter died and I am sad and there is no point" is ineffective writing. Similarly "I have found a friendship and feel hope" would have been a terrible ending line. It tells us nothing about who the character is. It tells us exactly what the author wants us to feel. It leaves no room for interpretation or nuance. Similarly, a series devoted to anhedony or the conspiracy of human consciousness or a nihilistic universe of malevolent gnostic hauntings cannot succeed artistically if it's merely a series of in-jokes designed to praise the crowds at Comicon. That's not art; it's propaganda.

The success of an artistic work is thus both parts quality of execution and clarity of purpose.

Perl 6, Superhero Without Purpose

One might argue that the Perl 6 programming languages aspires to be a superhero. It has a multi-paradigm design that allows procedural programmers to practice safe programming. It offers the laziness and composition capabilities that make functional programming useful. It promises a gradual typing system to allow programs to evolve and to become more correct (and to become more amenable to compiler optimizations) as the experiment in a problem space narrows down solutions. It integrates object orientation to provide customization possibilities of the language. It intends to make parallelism and concurrency safe and reasonable (in multiple senses of the word). If there's a Superman of programming languages, maybe Perl 6 is a visitor from another planet that has to grow up in an obscure corner of American farmland for a while, learning how to be itself, before it can fly off to Metropolis and save the world.

The problem is, Perl 6 is (as of this writing) almost 14 years old. It may have been the indestructible child of promise in 2000, but no one knows when it'll learn to fly or if it even wants to go to Metropolis (or Gotham City or even Oa) because no one knows why it exists. No one knows if its superpower is flight, or a magic ring which controls the color green, or an unmatched detective mind coupled with the resources of a billionaire orphan obsessed which chiropterae.

This is different from the complaint that "Perl 6 doesn't have users"; it's the complaint that the reason given for its existence is incomplete. "Perl 6 should be better than Perl 5" is incomplete. Who decides what better means? In what fashion do you measure this? In which contexts does the question apply? Along which axes can you plot both languages? What is the surface area under the curve on these graphs?

Few people sit down to write real programs for real users and choose their tools based solely on the theoretical purity and adherence to a single-criterion design principle embodied by the tools. For every example of a language designer such as Chuck Moore writing his entire operating system and every tool he used by hand (graphic editor, text editor, device driver) in Forth because the language so appealed to him, you have millions of counter examples of people adopting various languages because they're there, because they're easy to deploy, because their friends already knew them, because no single specific technical reason other than that seemed like the easiest way to solve a problem.

One can make the argument that a superhero needs no singular purpose if the purpose of the superhero's story is primarily a character sketch or other artistic statement.

One can make that argument. It translates poorly to programming languages, because one can never quite separate the nature of craft from the art of programming. Someday perhaps programming will produce its Andy Warhol who can craft a program which serves solely as art, divorced from any practical aspects, but so far the closest the industry has come are people like Andrew Plotkin and Urban Müller.

There's nothing wrong with programming language research. There's nothing wrong with exploring what a programming language can do. The problem that plagues Perl 6 is that, as free software, it is both a political and a practical statement.

Politics and Pragmatics of Free Software

Free software exists (and is licensed under free licenses) to be used—to enable the freedom of users by replacing proprietary software or to forestall the popularity of competing proprietary software. Without utility, there's no political point. Without utility, there's no practical point.

(One may claim that a project such as GNU Hello is purely a political statement with no redeeming pragmatic qualities other than to allow Richard Stallman to replace yet another piece of proprietary software with a free alternative, but even this modest code serves as an example of GNU coding standards—a pragmatic reason for existence which only works because the code is available for inspection and modification.)

Free software is and simultaneously is not subject to market pressures. To the extent which free software is efficacious to a purpose existing in the market, it will be used. To the extent which a software project may prove profitable (or at least, not sufficiently unprofitable) that it may be cancelled, a volunteer may maintain a project as long as he or she maintains interest.

In other words, users will use free software if it's pragmatically advantageous, but developers may develop regardless of any practical use. Indeed, developers may develop even if doing so is actively harmful to practical use. (Programmers with long memories may remember archives of very insecure scripts distributed further than their secure counterparts despite the maintainers of these archives knowing the degree to which they put their users in danger.)

The Flat Circle of Perl 6

How, then, does one interpret Perl 6? From the perspective of purpose, it flails. It is not clearly better than other extant languages for any practical purpose. Indeed, it's still attempting to find such practical purpose. The party line, one might surmise, is that the designers and implementors intend to put the language in the position to succeed as the language of choice for the Next Big Thing, though that rather raises the question as to how they might tune the language for that Next Big Thing without knowing what that Big Thing might be, nor when Next may happen.

One might appreciate the ironic postmodernism of expressly disclaiming a Known Purpose to guide development, hoping that the purpose will make itself visible post-hoc. One might appreciate that as an artistic statement.

One might appreciate that lack of explicit purpose as an artistic statement while lamenting its impracticality from a project management perspective. There may be a deeper philosophical truth at work, namely that any artistic statement will go beyond the author's intent as the art is experienced and interpreted by others—and in similar fashion, the JavaScript inventor may not have imagined Google Maps and the PHP inventor may not have imagined Facebook and the Smalltalk and C developers neither imagined Objective-C nor iOS, but the consequents exist, and the world must cope with their existence.

The market of programming languages has only grown since the announcement of Perl 6 in 2000. There are more potential users. There are also more languages for them to use, including several languages which did not exist in 2000. To the extent that Perl is attractive to these people, it is attractive because of its pragmatic qualities: does it allow them to accomplish something productive? What is it for?

PHP is for making websites. JavaScript is for making web widgets. Objective-C is for programming the iPhone. Ruby is for Rails and Python is for Django. These are stereotypes. These are bland statements of facts which condense larger truths into single sentences. These are Rusty Colhe saying "I am sad" and Superman saying "I deflect bullets". There's no story there; there's neither nuance nor artistry.

Yet the difference between a hero and a programming language inverts the need for that nuance. No one cares that Ruby makes you feel elegant when you program if you can't use Ruby for client side widget manipulation in a web page. No one cares that JavaScript steals a little bit of your soul every time you forget the binding of this because that's your only option.

Artistic expression in a programming language is a luxury you get when you have satisfied all of your pragmatic constraints. It's not a question of the singular right tool for a job. The real question is one of which of many tools is good enough for the job.

Having a tool in your toolkit with no defined purpose is dangerous. It takes up space. At some point you might use it. You might not. (Better to have any hammer, a couple of screwdrivers, a crescent wrench, a tape measure, and a good socket set than to have a very specialized plumbing wrench and nothing else. Sure, you can eventually hammer in a nail with the plumbing wrench, but if you just need to hammer in a nail once every couple of years, it doesn't matter if you have a framing hammer or a claw hammer, as long as you have something sufficiently hammery.) You may hope that someday you'll use it, but if you don't know what it's for, why are you keeping it around?

"We can't tell you what it's for, but you'll know when you need it" is a terrible slogan. It's not a design principle. It's a half-hearted apology for a lack of pragmatic design principle. It's the reason a cardboard comic book villain wants to blow up the moon: simply to spur on the story so that the equally-cardboard hero can demonstrate heroics. The result is bland and unsatisfying. Spoiler alert: crimefighter defeats criminal. Save your $4 and spend it on something better.

This wouldn't be a problem if all language designers had the clarity to position their experiments as experiments from the start, or the courage to classify an attempt at building a new language as an experiment when it became clear that the pragmatics were still a long ways off. Neither science nor art is predictable according to a project management schedule, at least not when it attempts to do something unique and interesting. Indeed, free software serves a legitimate purpose as the research arm of the software industry by allowing experimentation with new ideas and refinements to existing ideas without having to demonstrate financial benefit on a quarterly schedule.

If your comic book's sales are failing and you think killing off Superman or Captain America or Batman will solve the problem, you'd better have the replacement character's purpose well established when you launch. (In programming terms, claiming that "Perl 6 will be better than Perl 5" and then spending almost 14 years not demonstrating how that is the case, at least for potential users interested in the pragmatics of programming language adoption, you will have succeeded in killing off your hero and driving off your readers and you will leave yourself only with the hope that they'll come back when you figure out how to tell satisfying stories about your new hero.)