Month: January 2008
Creative constraints
Here’s an interesting response to my earlier post about how test driven development does not necessarily apply to all problem domains. Ocean has some insightful things to say about creativity, but mischaracterises me as seeing constraints as undesirable.
In fact I agree that constraints are essential to creativity. Constraints form the walls of the creative space that a creative agent (here, the programmer) searches within and pushes against. My complaint was not against constraints in general, but in the assumption that when we’re talking about development, we’re talking in the context of writing quality assured business software.
Lets take livecoding as a example. A programmer stands on stage, and has to write some software to generate some music so that the people waiting in front of them has something to dance to. Imagine looking up from your code editor to see the expectant faces above. This particular problem domain is one I have found myself in as a member of slub, and already has plenty of constraints to guide my creativity without adding the extra artificial constraints of starting with some unit tests.
[edit: see comments for fine counter-example from dave (a fellow slub member)]
Following your imagination
This entertaining article supporting test-first development has been playing on my mind. The article is beautifully written so it is easy to see the assumed context of working to deadline on well specified problems, most probably in a commercial environment. It saddens me though that we accept this implicit context across all discussion of software development practice all too easily.
Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.
Diagram © lispcast, some rights reserved
So there is a fairly clear reason not to write any tests for your code — you will take in more of the problem domain without such directive constraints. What you are left with will be the result of many varied transformations, and be richer as a result. You might argue that this is undesirable if you are coding a stock control system to a tight deadline. If you instead take the example of writing some code to generate a piece of music, then you should see my point. The implicit commercial context does not apply when you are representing artistic rather than business processes as code.
In fact this notional straight line is impossible in many creative tasks — there is no definable end goal to head towards. A musician is often compelled to begin composing by the spark of a musical idea, but after many iterations that idea may be absent from the end result. If they are scoring their piece using a programming language, then there would be no use in formalising this inspirational spark in the form of a test, even if it were even possible to do so.
What this boils down to is the difference between programming to a design, and design while programming. Code is a creative medium for me, and the code is where I want my hands to be while I am making the hundreds of creative decisions that go into making something new. That is, I want to define the problem while I am working on it.
While “end user programming” in artistic domains such as video and music becomes more commonplace and widely understood, then perhaps we will see more discussion about non-goal driven development. After all artist-programmers are to some extent forced to reflect upon their creative processes, in order to externalise them as computer programs. Perhaps this gives a rare opportunity for the magic of creative processes to be gazed upon and shared, rather than jealously guarded for fear that it may escape.
This post is distributed under the attribution share-alike cc license.
Livecoding at V2
A nice video of the livecoding sessions at v2 last month. Florian Cramer starts with an interesting take on livecoding, and it’s an honour to be mentioned in the same breath as Click Nilson. I should admit though that I was far from being the first livecoder as Florian suggests. SuperCollider server and Chuck were existed way ahead of my lowly feedback.pl, and in slub, my collaborator Adrian Ward was livecoding at least a year before me. In fact powerbooks unplugged who present and perform with their beautiful conversational code system later in that video were doing this stuff long before I livecoded my first gabba kick.
Textual patching
I wrote a perl script that allows you to compose puredata patches in a text editor. You define the patch using ASCII art like this:
*------------------------*
| .--------. \
.-x--------. | osc~ 5 | *
| osc~ 500 | `-x------' |
`-x--------' | |
| .-x------. |
| | *~ 300 | |
| `-x------' |
*---* | |
| *------------*
.-x------.
| *~ 0.2 |
`-x------'
|
*
|\
| *
| |
.-x-x--.
| dac~ |
`------'Then run the Perl script over it to produce a .pd file, that you can then load into puredata to get this:
The ASCII syntax basically allows you to define pd objects and connect them together. Layout is preserved. Much like in ghostbusters, you can’t cross the lines, and there isn’t syntax for different box types (messages and numbers). Fixing this would be short work, but I ran out of train journey 🙂
There is a particular syntax for drawing the lines. You use – for going left and right, | for going up and down and \ and / for going diagonally. To change direction or fork a wire you have to place a * . Mark inlets and outlets with x .
I think this shows nicely how there is no real difference between patching and coding. Shades of pixels are an alphabet, anything can be a program if you define a suitable interpreter to go with it.
Sadly you can’t do live patching with this, but perhaps this could be a starting point for thinking about more interesting ways of programming with text.
If you are curious you can download the script (and patch) here.