Pre-conj: Scheme Workshop

Introduction

Well, just at the last minute, this interview was finished. Jason Hemann is the organizer of this year's Scheme and Functional Programming Workshop that is happening just before the Conj. Tickets are very affordable and still available.

The schemers are inviting everyone to attend Programming Enthusiasts Unite for Great Justice, an after-hours event at 8:30 on Wednesday, November 19 at the Mezzanine Lounge, Capitol City Brewing Company, 1100 New York Ave. I'm going to be there, so say hi!

On with the interview!

Interview

LispCast: Tell me a bit about the Scheme Workshop.

Jason Hemann: The Scheme Workshop (or Scheme and Functional Programming Workshop, to use the full title) is an annual meeting for the community of folk interested in Scheme and functional programming generally. The purpose is to report recent developments in the language, to foster collaboration among the members of the community, and for researchers, implementers, and users to present recent work.

The first workshop was held in 2000, making this the Scheme Workshop's 15th anniversary. In previous years we've hosted it with PLI, ICFP, and SPLASH, among other venues. We're excited this year to again be co-located with Clojure/conj.

LC: What is something that Clojure (as a language or as a community) can learn from Scheme?

JH: I think the Schemer's view of the world offers an interesting comparison for Clojurers. To me, Scheme is a tiny extensible core, one basic data structure (the cons pair), tail recursion, and the ability to redefine almost everything in the language. It is amazing how few primitives you can get away with using in practice. To quote from a recent standard document,

"Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language...."

From this vantage point, Clojure feels like an extremely large and complex language (this is not to say it's the correct or only point of view, of course).

Historically, the design of Scheme has had relatively few compromises----some might say because there wasn't much language to begin with. This feels very different than Clojure, which readily compromises in order to interact with Java seamlessly. For example, Scheme implementations must handle tail calls properly. This isn't to say that Clojure makes the wrong decision---Clojure has different design goals, and unoptimized tail calls makes sense when interacting with Java. But by comparison Scheme feels very uncompromised, and it's fun to play around in such a minimal language with relatively few corner cases.

That design fits well with the Scheme workflow for writing small programs. Many Schemes exist as single standalone executables; you simply run it, and the REPL starts instantly. And then you're programming. There aren't any toolchains to build, projects to setup, or package dependencies to fight with. Compared with other languages' toolchains and workflows, there is very little to get in the way of thinking about a problem, and Scheme feels lightweight and nimble by comparison.

There are obviously tradeoffs to this design, and there can be a strain when trying to move to medium to large scale projects. Scheme has no large standard library, or standard build and versioning tools, or canonical directory layout, or anything like that. When creating large- or even medium-sized applications, the support you get in the Clojure world can be very useful. But when trying to quickly experiment with a new idea, Scheme doesn't have the encumberance of these (admittedly sometimes useful) features.

Scheme has been a useful tool for exploring and explaining new ideas, some of which have found their way into Scheme itself. Its relatively small size has made it a proving ground for language features. The Scheme approach has been to lean toward adding fewer, more highly expressive primitives. An example of this is the Scheme operator call/cc, which subsumes what would otherwise be a variety of distinct primitives.

Another idea that Schemers have explored and then added to the language is hygienic macros. While traditional unhygienic and pseudo-hygienic macros do great things for other lisps, Scheme's hygienic macros and the more recent procedural hygienic macro systems designed and developed in Scheme have really pushed the state of the art forward. The macro systems available in Scheme seem more usable than those of other lisps, and lead to more readable and more reliable code as well.

LC: So, now the opposite: what can Scheme learn from Clojure?

JH: Well, one thing I haven't mentioned yet is that Scheme is in the process of growing. The Scheme steering committee hopes both to keep Scheme as this small, lightweight language, but also make it a language able to meet "the practical needs of modern software development". The groups working on the latest language standard are producing both a spec for a small language and a spec for a large language, which is to be, by some metrics, larger than Common Lisp. The small language report is finished and was announced at last year's Scheme Workshop. This year, we will hear an update from John Cowan, the head of the large language working group. I'm excited to hear what they've been up to.

I mention this all because Clojure is a recent, comparatively large lisp designed with the practical considerations of real software development in mind. Clojure provides an example of one way to build a large language and ecosystem, and from which we can learn. The first thing that comes to mind is persistent data structures. Clojure comes out-of-the-box with a suite of persistent data structures that'd make programmers in a lot of other languages envious. The R7 large group has an immutable data structures proposal on the table, and I think that would be a nice addition. Clojure has a number of libraries that could be good additions to the large language.

Too, for a (comp aratively) young language you all have----and have had----a broad, vibrant, and growing community. The conj itself is a big event. The recipe for that kind of enthusiasm and growth is something I hope the Scheme community can bring back with us.

LC: What are some resources for Clojurists who want to learn about Scheme to prep for the workshop?

JH: Clojurists are already about as well prepared as anybody to learn about Scheme. That's the wonderful thing about being close linguistic cousins. A classic introductory text that uses Scheme to talk about some really neat concepts is Abelson & Sussman's "Structure and Interpretation of Computer Programs". Another good resource is "The Little Schemer" by Friedman & Felleisen. It's cute, and as much puzzle book as it is textbook (full disclosure, my advisor is one of the authors). As far as online references, schemers.org, readscheme.org, and schemewiki.org have enough information to keep one busy for quite a while. Also, we've just put up on the Scheme '14 website the papers that will be presented. Those still hungry for more might be interested in the proceedings of previous years' Scheme Workshops, available at schemeworkshop.org.

LC: Thanks for the great interview!