13.09.2010

Interactive Programming for Fun and Profit

This is the blog post version of a talk I gave at the JavaZone 2010 conference.

I’ve had dynamic programming languages (JavaScript, Ruby, Lisp) on the brain lately. A common trait of these languages is the ability to program interactively.

The concept is simple, but I think it’s easier to show rather than tell what interactive programming is. Here’s an example, demonstrated in IRB (Interactive Ruby).

What’s happening here?

Well, I write very basic Ruby code. But watch what happens along the way. Every Ruby statement I write is evaluated and run by the environment. The result is printed back on the command line. The environment remembers my actions. I define variables and functions. I’m able to build new things on the fly, and I get instant feedback for everything I do. No recompilation or restart steps necessary.

Our usual process for software development is like a steel mill. We create a mold (write code in an IDE). Then we stamp out a chunk of steel (compile, deploy, restart). Does the steel chunk (software system) have the wrong shape? Back to the drawing board, then.

This feedback-loop is much shorter than before thanks to faster compilation, incremental compilation, faster computers and unit testing - but we still waste time running back and forth like this.

Interactive programming, on the other hand, is somewhat like working with clay; work on the actual artifact directly. Mold it, add some clay (code), keep working, see what happens. No feedback loop at all.

This isn’t a replacement for our usual tools and workflow - it’s a useful supplement. Yes, you’d better use steel to build a production car. But prototypes are easier to build in clay. Likewise, interactive programming is a useful utility for serious software development.

So interactive programming is useful because you work faster, due to a shorter feedback-loop. You’re able to write less code, because you spend less time building infrastructure and boilerplate.

However, I suspect that the single Ruby example above didn’t full drive home the point. Let’s look at a few other scenarious, all of which I use regularly myself.

I sometimes use interactive programming as an systems interface for running webapps. In the clip below I start up an interactive Rails console on a testserver. This gives me access to the same APIs and data as my server backend - interactively - while the system is still running.

You can use Rails console as a replacement for a heavy web interface. Instead of building functionality you might not need, simply use the console. If you find yourself doing the same task repeatedly, then consider building a web UI for that task.

The console is also useful for small experiments while developing the system - try ideas out before commiting to them with production code.

Now, let’s move on to frontend work. The Firebug plugin provides another useful interactive environment. Watch:

This was a very simple example. I do however use the same techniques when I develop more complex UIs; the Firebug console is useful for testing stuff out “live”.

Unit testing is great for JavaScript development, but I often don’t know exactly what I’m looking for, how I want the final result to look. The Firebug console lets me quickly, iteratively look for a solution.

With me so far? In that case I think I know what you’re thinking. “I don’t want to write code straight to the command line! I like my editor just fine!” Well, you could write code in your IDE and then paste it into the interactive environment. However, it would be nice if the IDE let us send code straight to the console, right? Let’s look at one way of doing this.

Clojure is a young but promising programming language. It’s just a few years old, but it’s built on mature technology. Clojure is a Lisp dialect. What we’ve called interactive consoles so far, Lispers often call REPL (Read Eval Print Loops), and Lisp has a much stronger tradition of using REPL tools.

Let’s look at an example in Clojure. I stay in Emacs during the entire demonstration, marking and sending code to a separate REPL process. In this example I use this workflow to work effectively with 3d graphics (OpenGL is something I know very little about, so an interactive workflow is useful to ensure I get immediate feedback while testin things out).

The clip starts with a demonstration of the basic workflow, then some simple 3d graphics play, and finally I implement the rendering of a simple Tetris game (download src here, if you wish).

What have we seen so far?

Interactive programming gives you fast feedback. You’re able to work faster and write less code. This is useful for learning and exploring, for system administration and testing, and for visual prototyping.

Finally, have a look at the clips below. They are examples of Livecoding, where programmers and artist use interactive programming as a medium for performance art. The code and its output is improvised, sometimes in front of a live audience. Interesting example of skilled interactive programming taken to the extreme!

References:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: ‘Getting started’

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: ‘Getting started’

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos


PreviousNext