What Problems Can Be Solved by Programming?

Programming – the profession, or even the social phenomenon, since much programming is done non-professionally by open source volunteers – has stabilized into a certain relationship between human programmers exercising expertise and creativity, and programming constructs which automate certain aspects of machine instruction. The most important question in programming right now is why this relationship has stabilized in this particular place, and how it might be moved to a new equilibrium.

To begin with I would like to back up my claim that the relationship has stabilized. Any comment on the programming phenomenon as a whole must of course be somewhat guarded. It is too large an arena to comprehend entirely. However, a certain level of confidence in its basic status can be achieved, based on the following observations:

1) Productive or useful innovations in programming can be and are disseminated quickly, often through open-source. Distributed version control is one recent innovation which has become significantly used within a short time of first being well implemented. This pattern can also be discerned in the rapid spread of programming languages, or programming paradigms such as “design patterns.” Programming is a field in which genuine innovations rapidly become available to all.

2) The problems which programmers face are persistent. Whereas a book outlining specific technological tools is quickly outdated in programming, a book outlining broad technical challenges, such as algorithms, data representation, security, or programmer collaboration, never seems to become obsolete. This phenomenon has been made a slogan within programming commentary – “there is no silver bullet.” In other words, no matter what technologies are used, certain problems can not be solved without serious application of human energy.

Between these two points, a picture of programming emerges of whose broad outlines we can be fairly confident: programmers eagerly take up new tools to help them in their task of instructing machines; but the state of available tools today can not be utilized by any programmer whatsoever to achieve qualitatively superior results to any other programmer who is competent in the field. In other words, the present relationship between programmer and programmable machine is in fact stable, and is dictated by the nature of programmatic constructs rather than individual programmer skill.

This second point above may at first seem like an eternal truth or truism, because it is such a commonplace within modern thought about programming, and because in any other industry it would be obvious (e.g., an artist’s tools can not make an artwork by themselves). But it is anything but a truism. Even the existence of any problem which is intractably difficult for programmatic automation, but yields to persistent human creative thought, was not obvious to early AI theorists. We presently seem to have settled upon a certain border beyond which computation can not pass – but our own existence demonstrates that there is some way past that border. Therefore we can reject immediately the attitude that this border is the obvious or natural sticking point for our relationship to programmable machines.

A second attitude is to suppose that there is some silver bullet, but it is out of our reach as programmers. That is, humans can think because they have something which can only be granted by computation many orders of magnitude greater than what we have access to – namely, the computational power of evolution. This explanation has the flavor of a post-hoc justification for our present status. There is no specific reason to believe that fundamentally new programmatic constructs require new kinds of computation. A serious inquiry into the problem might conceivably turn up such an impasse, but the possibility of failure is never an excuse not to move ahead.

The shape of our inquiry must therefore be guided by this question: What causes the current boundaries of our relationship to programmable machines, and how can those causes be addressed? This question will be taken up in my next post on the topic.

Post-Programming

In common parlance, “post-” is a prefix used to denote that a structure that had formally held a position of cultural legitimacy has been deconstructed and that its skeleton, its syntactic structure, has been appropriated, given new meaning. To create a structure which is “post-X” the development of X as a system must cease, its elements used as the foundation of a new structure which is in some sense “deeper.” The concept of “post” is a very subtle one. I hope I don’t make too many mistakes in trying to describe my thoughts on the matter.

The standard example is Post-Modernism. As a cultural critical form, Po-Mo is built on the grave of modernism, the movement whose central tenet was that “we,” the western world, had reached the pinnacle of our cultural ascent. The claims, cultural criticisms, and theory composing the content of that movement crumbled, but its skeleton remained, to be re-cast in a new context of moral relativism and value subjectivity.

Post-rock, as a musical movement, uses the motifs of rock without any sort of nod to their foundations. Think about the motifs as the “notes” of Post-rock. Post-rock’s contribution is in creating structures and theory to allow one to move around in the linguistic/deductive framework that these motifs generate.

The recurring theme is that the semantic content of a deductive or abstraction-based system is left in the dust, but the syntactic and symbolic content remain to be used as a springboard for new and hopefully more powerful abstractions.

From a broader perspective, the “post” phenomenon (though it often goes unnamed as such) is part of the evolutionary progress of culture. Every generation is presented with a new set of challenges, new complexity which is, for them, difficult to deal with. We have spent time figuring out, for instance, how to use cell phones – what is the proper etiquette, when is it safe to use a cellphone, etc. Though these questions aren’t difficult, for our generation, a generation which has “grown up beside cell phones,” it is impossible to forget the essential semantic content of our moral assertions. One should not use a cell phone during a meeting because it is rude. Our knowledge of an abstract cultural/ethical decree such as “put your cell phone in silent mode during a meeting” exists along side the experience that generated the requirement for such. We can recall times when cell phones were used during meetings, lectures, etc. and how annoying the phenomenon was. For us, the abstraction has content that is non-hypothetical. It is the difference between knowing that murder is wrong because mother and society tell you, and knowing that murder is wrong because you have murdered.

But what of the next generation?

The next generation will take our ethics of cellphone usage at face value, as primitives. They will not know in an essential, human, experiential sense “why” it is wrong to use cellphones in groups because they simply will not have come face-to-face with the phenomenon. For them, the abstract content of the moral code will be preserved – they will have a skeleton on which to base future ethical decisions, theory, etc. This is the nature of cultural abstraction.

The example of the ethics of cellphone usage is intentionally prosaic. I want to convey the commonness of the “post” phenomenon as a primary method by which our society deals with complexity. Once all memory of rude cellphone hijinx is gone forever, we will have progressed into a “post-cellphone” age, an age where we no longer need think at any great length about why we know what we know.

Of course, I could go into the frailty of these abstractions and tie that in to, for instance, the frailty of our current economic/political systems. But I won’t. Not now, anyway.

The point of this post is to start detailing the nature of “post-programming” which is a term that hopefully I (Chris) and my two buds (Emma and Jason) will explore through descriptions of our exploits in a new world of programming – a world wherein knowledge of the fundament of modern computing (compilers, assembly, C, the lambda calculus) is becoming increasingly sparce – a world wherein more “abstract” knowledge (Java, Ruby, .NET, Frameworks) is becoming increasingly commonplace.

The danger of such a description is that it will be based on over-simplification and stereotypes. Portraying Java as an abstract phoenix risen from the ashes of nitty-gritty C/C++ does a great deal to occlude the nuance of both languages. Therefore, I will resort to a description of one of my personal experiences in the world of post-programming.

I started an internship at a company (SECOM) in Japan this year. My group programs in C#. Here’s how I write a program in C#:

design design design…

Start programming…

Oh, I need to store some data. I have vague knowledge of this thing called XML, it seems like it’ll be useful. Maybe?

Google “XML” – read wikipedia page, read thescripts.com and various tutorials to get an idea of what tools to use, best practices w/ C#, etc.

Oh good. That was easy. IMPLEMENT. Oh, now I have to print to .pdf.

Google “print to pdf C#” – find iTextMate. Download package, read quick tutorial, write wrapper library, print to .pdf.

Oh good. That was easy. Oh, I need to do event handling.

Google “C# event handling.”

I need to make a resizable text-box – Google “C# resizable textbox” – I need to use XPath – Google “XPath C#.”

Etc. You get the idea. There’s no thinking here. I’m just putting together extremely high-level pieces. No knowledge is required. Point-and-click.

The idea that I would even begin to dive into the depths of any of these topics scares and bores the junk out of me. I don’t want to learn about the XML specification. That’s boring as hell. I just want to use the damn thing.

I can hardly expect that this is an uncommon sentiment.

At my job, when I am using C#/.NET, I am a post-programmer in the flesh. I am working completely within the framework (read: confines) of the C# .NET framework. Thinking about the deeper issues at hand can only bring grief and boredom, so I keep my eye on the prize (successful implementation) and try to deal with these high-level concepts as primitives. If something goes wrong, well, shit.

As with any cultural label, “post-programming” is a vast generalization and over-simplification. There are, of course, real “hackers” out there who have been down in the shit, who continue to write good code, who are brilliant. Yada yada. Even they are “post-programmers” in the sense that they don’t write assembler code. They don’t write in C most of the time. Even they are sitting on nice, inherited frameworks. They just aren’t as high up in the clouds as others.

As with any cultural phenomenon, post-programming can manifest as either friend and foe. I didn’t have to learn XML, which is good, because frankly I don’t give a damn – but even without learning its inner workings I was able to derive a great deal of utility from the power of its innate structure. On the other hand, the question arises if the skills that I learn from performing this sort of programming are useful in a general sense – will the structures on which “general” frameworks like .NET are based stand the tests of time? The post-programmer thrives on information which is easy to access and necessarily shallow, but the structures he derives in terms of this shallow language of (high-level) primitives are bound to be as deep as the structures behind the primitives he/she uses. That is, of course, accepting that his primitives were good enough and the whole thing doesn’t collapse under its own heavy restrictions (e.g. Java code bloat).

It is my goal as a post-programmer to detail and create these structures – to give rigorous definitions to terms such as “abstraction,” “meta,” “framework,” “DSL,” etc. (definitions which have been, historically speaking, lacking). It is my goal to create publicly available utilities for working within the vast sea of information and complexity that we are now swimming in. It is my goal to become the post-post-post-programmer.

—

As a closing note, I hope I haven’t portrayed myself as a “blub” programmer. There is a distinct difference between “blub” and “post” although it is somewhat subtle. I further hope that I will not color my co-bloggers’ future posts with this taint. We all get down in the dirty. I study programming languages, compilers, theory of computation, blah blah. I am a math guy before I am a programmer. I am a dreamer before I am a programmer. I am a meat-stick before I am a programmer. That being said, I realize the utility of working within the system, even if I hate it. So the system it is.

Do you think post-modernism ever made anyone smile?