“Stemming” is a term that I regularly refer to when describing the emergent train of thought one goes through during an exploratory process. Usually, stemming indicates that one’s earlier experiments were not entirely successful. However, we all know that stemming often leads to alternative ways to look at problems, and is fundamental to learning.

“When a child is taught … it’s programmed with simple instructions — and at some point, if its mind develops properly, it exceeds the sum of what it was taught, thinks independently.”

— Dr. Richard Daystrom

I like to think that stemming is fundamental to development, as Dr. Daystrom indicates. The following blogs are the collected results of about a week of stemming on a simple problem: how to visualize graph searches, performed via a functional graph library I wrote in Clojure, efficiently and “prettily”.

There are a couple of purposes for developing some visualization capability. One is for verification and testing. We “know” what a standard graph search should look like (DFS/BFS/Djikstra/BellmanFord/etc.) and can quickly identify odd behavior in a visual representation. Mat Buckland’s “Programming Game AI By Example” is an EXCELLENT book that I drew a lot of inspiration from. In it, he presents a very nice visualization application for examining the character of various search algorithms related to pathfinding. My (continuing) desire is to implement a similar path-finding visualization in Clojure using Swing.

Buckland’s visualization program is really just a static, square nxn grid. The grid has random “obstacles” in the form of filled polygons scattered about. A pathfinding algorithm is given a starting cell, a navigation graph representing the connected cells in the grid, and a destination cell. The pathfinder searches and reports its path(s), which are visualized. This environment clearly exposes the unique characteristic of each search algorithm by exposing the sequence of the search. One could easily have an animated agent meandering about the search path as well.

Given such a conceptually trivial application, I felt it would be an easy entry-point into the unfortunately stateful world of GUI programming, and an opportunity to delve further into the vast ecosystem of Java libraries.

I have a “pretty good” grasp of Clojure and functional programming. I prefer functional programming where possible, but GUIs are typically stateful and full of side-effects. These characteristics are almost like garlic and holy-water to pure functional programmers. Conal Elliot, Paul Hudak, and other functional programming badasses are still actively researching how to “do” GUIs in a purely functional way. Given that 99% of the libraries I’m dealing with will be of the stateful, impure model, I decided to bite the bullet and live with some practical mutation (or at least minimized impurity). So implementing even a simple GUI should also serve as an opportunity to delve into the “dark side” of Clojure, namely its ability to cope with state and mutation elegantly and safely.

In order to do graphics or GUIs in Clojure, you’re likely looking at using what the JVM provides (that’s one of the touted benefits of using Clojure). In this case, there are a couple of bundled toolkits to play with: the Abstract Windowing Toolkit, and Swing. Swing simultaneously extends and subverts most of the functionality of AWT. There are proponents and opponents of Swing (some of which prefer another toolkit called SWT). In the end, Swing is the “good enough” choice for my little app.

In the next blog post, we’ll talk about GUIs and Swing, and begin stemming. Events, Observables, Swing Listeners, F#/Rx.Net, Macros, and threading are all on the horizon!