Shrew is progressing, it now sports an s-expr to XML evaluator; I’m reading RESTful Web Services to gain a better idea of how it should expose resources. And I’m also working through The Seasoned Schemer. And therein lies the most interesting aspect to Shrew. I am a reasonably experienced, quite competent polyglot software engineer, but learning Scheme has forever changed how I think about programming. And through example crystallised the ultimate development environment that I have been drifting towards.

When I’m working on Shrew, my editor looks something like this:

In the top-left is the module I am currently working on: writing, expanding or fixing – as I’ll try to show there isn’t really any difference between those three. In the top-right is a scratch file that contains a bunch of ad-hoc tests for the module I’m working on: nothing structured, just calls of the functions that I’m writing. Across the bottom is the output from a Scheme process running in the background.

Before I go on there’s one detail of Scheme I should explain. To write a new function you call a built-in function called define, passing the name of the new function and its body. define is smart enough to simply replace the body if a function of that name already exists.

It sounds like a pretty simple development environment: a plain text editor with three windows on screen. Why so special?

I write a function – not a test, sample or prototype, but the real code I’m planning to commit – I jump to the end of the define and run a command in my editor to evaluate it. That function is then inserted into the running Scheme process and available to be used by anything else that is run in that Scheme process. Or, I’m immediately informed of a syntax error in my code.

I switch over to the scratch file and write some code to call the function I just implemented: typically just one expression, but it can be as many as I need. I evaluate that new code. And immediately see the output in the window at the bottom; the window reflecting the running state of the background Scheme process.

And of course, there’s a bug in my function. I switch back to the window containing the module, fix the bug and re-evaluate. I switch back to the test code, re-evaluate that, and see that my change has fixed the bug.

Elapsed time from writing the function through debugging and verifying the fix: 45 seconds.

Instead of having to write a complete library, compile it, write a test harness, compile that and link it to the library and only then run the code to see if it works, I have a Scheme process running in the background that I can just keep adding code to. New code, or code to replace existing code. And at any point I can execute any sub-part of that process and immediately see the output. No delays, no pauses, no backtracking to find which line of code is wrong.

Scheme could be regarded as a fairly direct implementation of a theoretical model of computation: the lambda calculus. Most texts that teach Scheme emphasise this; they encourage you to think of your programs in terms of this theory, in quite some detail. That may sound fairly esoteric, but once you’ve spent sometime working in this environment you reach this unique state. You are inside your program, reaching around moving code as fast as you can think. There is essentially nothing between your thought and code: no defining boilerplate, no compiling, no creating test harnesses, no waiting for test runs to complete. Your solution simply unfolds before you.

But that’s not to say your code is of lower quality. In fact, because you’re concentrating more fully, with no distractions and the flexibility to easily push your code in any way you want, the code is of much higher quality. There’s no idle thought ‘I should test that’ which is forgotten in the edit-compile-run-debug cycle: think it, try it. This is flow as Peopleware could only dream.

And once you break out of this magical flow, you’re left with complete code; code you lived and breathed for a few hours, code you understand deeply and will have a hard time forgetting. Plus, a comprehensive set of tests to commit alongside.

In object-oriented languages there are two approaches to dispatching methods.

• Message Passing: Objects are regarded as actors. Method call is treated as sending messages to those actors. Method dispatch is therefore determined solely based upon the type of the receiver of the method, the types of any arguments is immaterial. SmallTalk typifies this style. C++, Java and most other OO languages have adopted this style (badly.) This is also known as single-dispatch.
• Multi-methods: Methods and the objects to which they can be applied are regarded as a cartesian product: objects don’t own methods and methods don’t own objects. Method dispatch is therefore determined from the type of all the arguments equally. CLOS uses this style. I am not aware of any other widely used languages that also use multi-methods.

The book I am currently reading laid out some Scheme code that showed how to implement multi-methods, and then followed it up with some code that implemented message passing. In both cases the code was extremely simple and easy to understand: the basics for two object-oriented approaches were right there on the page.

And most interestingly, there was no reason why both systems couldn’t be used on different objects in the same program.

The book is about general computer science concepts, so it doesn’t actually point out what it has just described, and nor does it provide a complete implementation of an object system (yet…) however it is interesting to see such a fundamental part of a object system in so few lines of code. It is the nature of Scheme that makes it possible to implement things that other languages regard as ‘part of the language’ in your own programs.

It is not possible to do this in Java; it is not possible in C++, not even with template meta-programming; and it isn’t even in possible in Haskell*.

Now, that’s not to say that having both multi-method and message passing dispatch is itself such a killer feature. But it’s going to be kind of hard to beat a language to which both of these things can be added so simply.

* Of course, via differing mechanisms of varying degrees of pain, something like multi-methods could be added to all of these languages. Here I am talking about a simple, transparent at both caller and callee technique for achieving multi-methods and message passing.

I haven’t been at it for long, but here are some random thoughts and comments so far. Much of this will change as I figure out how to use Scheme properly. These comments are also mainly a comparison of the only other functional language I know well: Haskell.

• The syntax is not very clear: everything looks the same. This prevents you from scanning the code to get a feel for what is happening. The indentation helps, but fundamentally every operation is just a parenthesized expression. I am certain that this is just cultural, with more exposure I’ll get better at reading; don’t count this as a negative.
• I really miss pattern matching. How can you program without it? I’m going to have to look into destructuring-bind.
• Dynamic typing is sweet. As well as all the other benefits, dynamic typing + modules = as much encapsulation as classes give you in C++.
• The standard libraries are pretty paltry. The SRFIs add a lot, but it’s still nowhere near as rich as pretty much any other language. Maybe I’ll explore Common Lisp at some point.
• Currying is not just an implementation technicality, it’s useful for designing data structures. I miss currying as well.