Pre-West Interview: Robert Krahn
Talk: Programming Clojure, Smalltalk-style
Robert Krahn's talk at Clojure/West is about cloxp, an implementation of some important ideas from Smalltalk in Clojure.
Background
Back in the sixties, some computer researchers were trying to make a system that you could have a conversation with. The user, of course, would be intelligent enough to hold up their end. But the researchers did not know how to make the computer hold up its end. The researchers compromised and decided to expose the entire contents of the system's memory and represent it visually on the screen. Every object would have at least a primitive visual form, while others would be richly interactive elements. That way, the user could at least interpret it for themselves. The end result was the ancestor of the GUIs we use today.
But the GUIs we use don't have that property of exposing the contents of memory to inspection. The objects on the screen are not direct representations of the objects in memory They are separate constructs. Cloxp aims to bring the inspectability and directness from Smalltalk to Clojure. Check out the intro page, which has a nice long explanation and a demo video, with links to more background.
About Robert Krahn
Introduction
Robert Krahn was gracious enough to agree to an interview. He is giving a talk at Clojure/West about building Smalltalk-like features into Clojure. The background to his talk is available, if you like.
Interview with Robert Krahn
PF.tv: How did you get into Clojure?
Robert Krahn: I am interested in Lisp generally because of the inherent simplicity in most Lisps mixed with rich meta-programming facilities. I followed the development of Clojure over the last few years and always felt compelled to do a project in it. For me the most interesting aspect is the clear distinction between identity and state handling and how the core language is designed around it.
In the beginning of this year I finally had the chance to start my first "real" Clojure project --- cloxp. So far it has been a great learning experience and a lot of fun.
PF.tv: What are you bringing from Smalltalk with cloxp and why?
RK: The ideas and concepts behind Smalltalk exceed what is considered to be a programming language in most contexts. Just looking at the syntax tells you very little.
The goals that Alan Kay and his colleagues at Xerox Parc had in mind when creating Smalltalk actually go a lot deeper than just "better programming". Together with the Xerox Alto it was one of the first serious attempts to make "personal computing" real. A lot of it is summarized in "The Early History of Smalltalk".
However, I'm mostly focussed on the programming system aspects. So far the best description I've found that captures how it feels to work in a Smalltalk environment is "Swimming with the fish" by David Buck. The directness and immediacy you experience comes out of several properties: The programming environment can be explored and modified from top to bottom. Your code is not different from library code and "system-level" code. The system and the tools are made to inspect runtime state and processes. A debugger in Smalltalk is not just used for debugging, you actually write code in it (and have access to the runtime state while doing that). The entire system is changed incrementally. Not just as in you evaluate expressions like in a repl. The state of the system can be captured entirely, running processes and all. You literally start in the morning with what you had the day before.
All this makes programming more effective and fun. This is what I'm interested in and what, at least in part, I want to transfer into Clojure with cloxp. I think Clojure can offer a fresh perspective when designing an interactive programming system. I have, for example, David Nolan's om and other approaches to create "functional-style" graphical systems in mind.
PF.tv: What are the main tools you're trying to build for Clojure?
RK: cloxp currently offers tools for exploring and modifying code. The main tool you work with is a system browser that lists namespaces and vars, somewhat similar to a Smalltalk browser that lists classes and methods. You can drill into code, modify individual definitions or the code associated with an entire namespace.
Apart from that, cloxp allows to instrument individual expressions in functions to capture data as it flows through. Captured data can later be viewed and inspected. Additionally to that you can also trace expressions and the subsequent function invocations entirely, similar to what clojure.trace offers but integrated in the tooling. Also, code can be evaluated everywhere you see it. Whether it is in the system browser, an inspector, or a workspace to do scratch programming.
All tools focus on using the Clojure runtime and meta programming facilities as much as possible. You have one or multiple Clojure VMs running most of the time that cloxp will connect to. By making extensive use of runtime data cloxp tries to achieve that "Swimming with the fish" experience.
PF.tv: Do you recommend people learn Smalltalk? Where should they start?
RK: I certainly do. On a personal level, Smalltalk has fundamentally influenced me in how I think about programming and how I approach developing a software system. Both in terms of tools and software design.
There are two open source Smalltalk distributions available, Squeak and Pharo. They both come with "one-click" installers that let you start without much installation hassle. The free books Squeak by Example and Deep into Pharo explain the fundamentals. More documentation, screencasts and example programs are available as well here and here.
PF.tv: Does cloxp have to modify the Clojure compiler? Or is it using already available constructs?
RK: So far all features rely solely on what Clojure has to offer. Non-core projects that proved to be useful are clojure.tools.nrepl, clojure.tools.reader, and clojure.tools.namespace. The abstractions around those are packaged into various sub-projects and can be found on github and clojars 11.
The runtime state of applications developed with cloxp are not saved. In this regard cloxp differs from Smalltalk. There is a clear distinction between tooling level and application, allowing you to load existing projects into the environment and just using it as a normal IDE.
The user interface of cloxp and the networking and persistence middleware are based on the Lively Web construction kit. Lively Web is in itself an interpretation of Smalltalk, mixing programming tools and serializable state with a wiki-like workflow.
The graphics are implemented with a re-implementation of Morphic, the graphics system of Self. For cloxp it provides a simple yet flexible way of implementing tools. And this is a crucial aspect: The implementation of typical IDEs are usually set in stone. They might provide hooks for plugins and extensions, but writing those is usually a major effort. And if there is not the right hook you are out of luck. In cloxp you can literally click on a tool to see and modify its implementation. This allows for the kind of customizability that Emacs users (rightfully) value so much.
And to come back to the first part of your question: Workspaces with the cloxp (and maybe your own) tools can be saved, basically using Smalltalk's image idea.
Now to the "bad" part: Currently, cloxp is a mix of Clojure and JavaScript. Modifying the frontend of the tools means that you have to deal with JS. Going forward I am interested in transitioning to a more "functional-style" implementation of Morphic using ClojureScript. Cloxp actually has just taken a ClojureScript (and cljx) class. So the way should be paved :)
PF.tv: What features are you working on now? Where do you see it going?
RK: Right now I'm preparing a first release to allow everyone who is interested in the project to try it out. There already is an installer available but a few things need to be cleaned up.
Feature-wise I'm currently focusing on ClojureScript and work on getting the existing Clojure tooling to work with it. This will make interactive evaluation, code browsing and writing via the system browser and debugging via captures and traces possible. When this is done I want to figure out if it is feasible to combine the concepts of an interactive graphics system like Morphic with a more functional programming style. This will either bring the best of both worlds together or be a horrible disaster :)
If I'm able to continue with development of cloxp then there are (at least) two other upcoming topics: I'm really interested in a source-level stepping debugger and to bring cloxp and content created with it to a broader audience. The interesting aspect of cloxp and Lively Web is that those systems allow a) to author content and do programm ing at the same time, allowing e.g. the creation of interactive essays and b) are only requiring users to visit a web page. As an example, I've prototyped a "4clojure solver" that pulls down the exercises from 4clojure.com and let's users solve them with the live eval and doc features. If this could be hosted, maybe with some additional content, it would be a start and might form an innovative community resource.
However, to make this happen, help is definitely needed: Dear reader if you are interested in these projects, think that cloxp is a good idea and can help to move it forward, please get in touch!
PF.tv: Where can people follow you and cloxp online?
RK: The cloxp site is at http://cloxp.github.io/. I'm a bit behind with updates but there will be more content documenting cloxp and explaining the ideas behind it. Whenever I feel like boasting about the newest hack I've written I post it on twitter @robertkrahn.
PF.tv: If Clojure were a food, what food would it be?
RK: That one is easy. Chocolate pudding of course. Once you get started you can't stop.
