The Art of Computing

Thoughts on an alternative view on programming

blog

Improving Computer Programming

March 23rd, 2006

The question I'd like to address first is admittedly a rather big one, which is how to make the process of programming computers better. I'm deliberately being vague here because any kind of improvement is welcome and I think it's direly needed. But I also want to avoid making assumptions about the shape such an improvement should take.

I use Common Lisp whenever I have the choice and I prefer it for all kinds of reasons. But most of all I think it's the malleability that makes it superior to other languages, at least for me. In short, the idea is that a good language lets you change the program to suit new needs as easily as possible. This is motivated by the insight that you don't know how things need to be done until you've tried and learnt from the experience. So you then craft the code in short cycles, continuously learning from what you did so far. Back when I used C, Java and Perl (not to mention BASIC) I was appalled by the way I always ended up typing out the same old structures and cutting and pasting my way along as features were added. The basic idea of maintaining flexibility and performing iterative development has been flying around for a while now and the current buzzword seems to be "Agile". Interestingly though, those people seem to maintain political correctness when it comes to language choice.

Here in the Lisp world though, I have the feeling that language design is no longer the limiting factor in flexibility. What hinders me most these days while coding is the way the system at large works, the editing process, interacting with the REPL, analysing the output and so forth. While you can currently build a fairly decent development environment with open source tools and some customization, I think far more is possible. For example, I always end up pasting together a series of expressions evaluated in the REPL into a function once I know how it should be done, just to end up copying individual expressions back into the REPL farther down the road when something goes wrong. I don't think it should take too much to automate this. The important question is the right context for such functionality, such as part of an interactive environment or simply a set of Lisp functions.

But digging to the root of the problem, I realised that the most fundamental assumption in programming today is the textual representation of programs. This is of course the very reason for the focus on language design in the first place. Representing algorithms as sequences of words and symbols seems a natural thing as a matter of custom, but I have the suspicion it might just be one of those historical accidents. I'm currently thinking about other approaches and will post on that soon.

First post

March 21st, 2006

Some kind of feeling of taking sides with the underdog or the coolness of tiny startups made me choose Infogami instead of blogspot or such for my new Art of Computing blog. I'll probably regret this decision if the whole think starts flying to pieces, but I'll keep my fingers crossed and the HTML backed up.

The idea behind this blog is to write down (and hopefully receive some comments on) some of the ideas about computing I've been developing for a while and want to start translating into code. But it's a lot faster to sketch it out in words than s-expressions.