Is Programming more like ‘art’ then ‘science’? A debate that is continuous, but I know where Richard P. Gabriel stands. In 2003 he wrote the forward to “Successful Lisp: How to Understand and Use Common Lisp,” by David B. Lamkins titled “The Art of Lisp and Writing”. Recently it got shared at “Hacker News”.

I admit to knowing enough about Lisp to be intrigued (inspired by it even) but have never used it at work or in a personal project. His essay while touching on some differences between Java and Lisp (and he would know – he worked at Sun), talks more of the act of writing and creation and how programming is akin to that. It was a good read.

Taught that programming–or the worse “developing software”–is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn’t a science and unlike science and engineering, it isn’t a serious activity. Judgments like this, though, are easiest made by people who don’t seriously engage in making both science and art. Art, engineering, and science are–in that order–part of a continuum of finding truth in the world and about ourselves.

…The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you’re inadvertently making.

There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus–when we are in flow–we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.

Read the whole piece.

Share this:

• Mastodon
• Reddit
• Pocket
• Facebook
• LinkedIn
• Email
• Print