Forth and the Power of Fun

I've written many a blog post discussing my infatuation with the Forth programming language. It's a quirky language that's easy to dismiss, but I'm convinced it's unique design philosophy will one day save the day for one of my projects.

My friend Grant recently published a touching tribute to a friend who was quite productive in the world of Forth (anti-lock break controllers? Awesome!). This inspired me to track down some advice I thought I had picked up from Forth, but couldn't quite be sure.

I've searched for the source of this inspiration advice a number of times, but I could never get Google to cough it up. Motivated by Grant's post, I tried again and today I was successful. Years ago, I read Thinking Forth and this discussion managed to stick with me all that time:

I asked Moore how he would go about developing a particular application, a game for children. As the child presses the digits on the numeric keypad, from zero to nine, that same number of large boxes would appear on the screen.

> Moore: I don’t start at the top and work down. Given that exact problem, I would write a word that draws a box. I’d start at the bottom, and I’d end up with a word called GO, which monitored the keyboard.

How much of that is intuitive?

> Perhaps some degree of it. I know where I’m going so I don’t have to start there. But also it’s more fun to draw boxes than to program a keyboard. I’ll do the thing that’s most fun in order to get into the problem. If I have to clean up all those details later, that’s the price I pay.

Are you advocating a “fun-down” approach?

> Given that you’re doing it in a free-spirit fashion, yes. If we were giving a demonstration to a customer in two days, I’d do it differently . I would start with the most visible thing, not the most fun thing. But still not in that hierarchical sequence, top down. I base my approach on more immediate considerations such as impressing the customer, getting something to work, or showing other people how it’s going to work to get them interested.

So there you have it, Fun-oriented design. This notion of working on the fun part first has stuck with me, and it's an approach I'll opt to take when given the chance. The value it provides is how it helps me get mental traction on a project or component. Heck, if I'm working on a project that seems to have no "fun" part to it, I'll often take a step back and consider how I can correct that. Rather than slog though dozens of boiler plate lines of code, can I can autogenerate the code? Or perhaps rig up some dynamic framework I don't even need to write the code?

It's been years since I've had a discussion/debate about how code should be designed (top down! bottom up! sideways!), but if I had such a discussion I'd have to include the fun-first approach as an option.

Even if you don't become a Forth coder, reading Thinking Forth is definitely worth your time.