« March 2005 | Main | May 2005 »


Programming as a craft

People tend to have differing views about programming as to the nature of this endeavor. Many of us involved with creating software are employed by organizations that regard programming as a form of engineering - a methodical, almost robotic activity of taking a specification and turning it into error-free code (hence, perhaps, the terms software production and software factory). These organizations naturally shun the idea of programmers as artists, although many programmers may consider themselves as such. In an essay titled "Great Hackers", Paul Graham points out that a programming language is a medium of expression, and that the choice of a language (or more generally, the infrastructure for a software project) is not only a matter of adhering to a standard or selecting something that's popular (and thus, as the thinking goes, guaranteeing or at least maximizing the likelihood of, say, finding competent programmers) but an important social decision as well.

Personally, the way I perceive art and artistic expression makes me think of programming not exactly as art per se, but more of programmers as craftsmen. This would make programming, as a practice, a craft; it turns out that this metaphor is not terribly off the mark, since in many ways programming is an activity that benefits from being practiced (as in getting more and more competent and proficient in it). Indeed, despite part of programming being engineering, it also involves "skills of the hand" of sorts, as many of the tools programmers use (say, Emacs) and languages (say, Common Lisp and its 600+ standard functions) can require lots of rehearsing in order to be mastered.

The notion of programmers as craftsmen is also heart-warming to a perfectionist; one could visualize the image of highly skilled carpenters, stone cutters, etc. of bygone ages. In our age of instant gratification and end-justifies-means -style of corner-cutting, a proficient programmer, practicing his craft, is a pleasant thought. I wonder if this approach would have anything to do with the quality of the end result itself? Modern approaches to software creation (such as extreme programming) tend to emphasize the speed of production over careful planning (the latter is seen as a waste of resources). Without taking sides, the actual execution of the act of writing code surely benefits from an approach that is based on experience and proficiency, inasmuch as being a means of maximizing the chance of attaining error-free code, balanced against the time spent writing it.

All of this, no surprise, is compatible with my own desire to write my code just so, that is, exhibiting certain perfectionistic traits when it comes to how my source code looks, how it is organized, and what idioms it uses. A consistent, clear style also leads to maintainable code (as a personal note, this is particularly good for someone like myself who forgets the details of the code about 24 hours after it was written).

In his recent monograph "On Bullshit" (yes, this actually is a serious book), Harry G. Frankfurt discusses corner-cutting as a form of bullshit and points out that craftsmen of the past would even pay attention to details that would not be seen in the end result, since the idea of having done a sloppy job would bother their conscience. In the software business, does such professional pride exist, does it perhaps take other forms, or has it simply been dispensed with because of the inevitable pressures of deadlines and "time-to-market"?

And as to art, sometimes I feel like printing out some of my source code, framing it, and hanging it on the wall. In these cases, people worrying about deadlines might feel that I have spent too much time polishing the code. I wonder. Graham points out that a great programmer can be 100 times more productive than a mediocre one; without making any claims about being a great programmer myself, I cannot help thinking that these great programmers must be the master craftsmen of our craft. Thus, I wonder if the notion of "apprenticeship" would make sense in our business as well?

Posted by ora at 19:20 | Comments (2)


A long time ago in a galaxy far, far away...

Nowadays, whenever I program in Common Lisp, I tend to think of the quote by Obi-Wan (Alec Guinness) from Star Wars:

"This is the weapon of a Jedi Knight. Not as clumsy or as random as a blaster, but an elegant weapon for a more civilized age."

I have to keep a positive mind and believe -- now that most of the limitations of computers that people used as arguments against this elegant language have gone away -- that there will be a real revival. There are some signs...

Posted by ora at 13:09 | Comments (3)


Wilbur2 or "did I mention I am not sure I like CVS very much"

So I have been working on a rather substantial code-overhaul of Wilbur, now dubbed "Wilbur2". Many things have changed (or will, as soon as I get to them); backward compatibility is guaranteed not to be there (although I will write a section in the new manual about migrating code that uses Wilbur).

Since I want everything to be just perfect (yes, I know, it is a disease but I cannot help it), including how the source code is broken into various files, I am now struggling with CVS. Some of the old files will "go away", I will introduce new ones, etc. What is the proper way to do this in CVS? There does not seem to be any elegant way (or is it just that sometimes Sourceforge works in a rather sluggish manner).

Perhaps I will just start a completely new module (right now it is just a branch in the version tree). I don't want to start a completely new project...

Posted by ora at 20:43 | Comments (2)

April 1st: Functional vs. imperative style - confusion prevails?

I noticed this post on gmane.comp.lang.lightweight (note: on April 1st), titled "Lambda the Ultimate Design Flaw", written by Shriram Krishnamurthi. The article discusses the future of the PLT Scheme. Here's an excerpt:

We think dropping FILTER and MAP is pretty uncontroversial; (filter P S) is almost always written clearer as a DO loop (plus the LAMBDA is slower than the loop). Even more so for (map F S). In all cases, writing the equivalent imperative program is clearly beneficial.

There's actually a serious point buried here. Generally, when most programmers only know Java etc., functional style might be undesirable (as a knee-jerk reaction). But I think this is more a problem with all the imperative languages that dominate the software business rather than with functional style per se.

The post continues:

Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church (indeed, they don't even know that he was related to Guy Steele), so the name is confusing; also, there is a widespread misunderstanding that LAMBDA can do things that a nested function can't -- we still recall Dan Friedman's Aha! after we showed him that there was no difference! (However, he appears to have since lapsed in his ways.) Even with a better name, we think having the two choices side-by-side just requires programmers to think about their program; not having the choice streamlines the thought process, and Scheme is designed from the ground up to, as much as possible, keep programmers from thinking at all.

The idea of non-thinking programmers is truly frightening. :-)

Posted by ora at 09:33 | Comments (0)