I’ve been thinking about existing Lisps a lot lately and where we’re headed. In particular, I’ve been considering the possibility of writing another Lisp dialect, and where it might fit.
If you haven’t already heard about it, Lisp is a neat little family of languages; its extremely minimal syntax lets us think in nearly-pure algorithms, un-muddled by crufty syntax or obligatory boilerplate.
What’s on the market today?
Traditionally, there’s Scheme, which is only useful for teaching in universities because of it’s intentional lack of libraries, and there’s Common Lisp, which is just a horrible, horrible mess (think C++ but with more parentheses than you can shake a stick at).
Clojure is obviously the most popular Lisp today. Some people would even consider it the only Lisp that’s actually practical anymore. It added syntactic sugar for more datatypes, seamless integration with the
JVM, and it ditches all the old legacy junk of traditinoal lisps.
There are a few others, such as Nu, which is super cool when you want to build an iOS or Mac app but don’t like pointers. (Hey, just like MacRuby!)
But why didn’t Nu take off? And why did
CL and Scheme die? Why is Clojure the only one gaining traction? Can another Lisp be implemented and have Clojure-like success?
A curse ... and a blessing
Obviously there’s the syntax. Lisp’s s-expressions make it enormously simple and give it the powerhouse feature we call macros, but all those parentheses are hideous and nobody can edit them in any editor other than emacs+paredit and expect to survive. Its biggest strength is probably its biggest weakness.
But there’s also a sense of platform, and portability needed. Nobody is going to write an entire application in Scheme because it has no standard libraries. Clojure arrived on the
JVM, which is portable and is already jam-packed with all sorts of built-in helpful classes and third-party libraries. Thanks to Java, the
JVM is already an established platform.
But what’s a platform?
Nu is an interesting Lisp. It was written to make iOS/Mac development easier and more fun. It brings Lisp macros to the table, and it comes with a goodie-bag of useful tools to help you get your feet wet.
But Cocoa is an
SDK, not a platform. Anyone who tells you otherwise is trying to sell you something (probably Xcode). In a Mac/iOS app, your ins and outs are
GUI, and each component you’ll need at every step of the way is provided for you (tightly-coupled to one another, I might add) by the frameworks. Little is left to the imagination.
So what’s wrong with that?
When writing an app in Cocoa, you are given the model layer, the controller layers, the view layers, and are told to glue them together with a little Objective-C. So there’s no room for any of the features Lisp would offer you. Nearly every line of Nu code you would write (I’m going to guess about 95%) would be making a bridged Objective-C call out of necessity, which defeats the point of using Lisp in the first place.
Besides, most of Apple’s libraries just don’t make any sense outside of an imperative-driven context. So there’s not much that can be done to make good use of functional-style programming, and you have to ditch many of the complex C-level features Apple provides that just can’t be made compatible with Lisp.
There’s simply no good reason to leave Apple’s built-in superglue for our own home-grown glue, it’s just not worth it. This is inherently the problem with any
SDK, not just Cocoa but Android and others too.
JVM is open-ended. Your persistence layer is completely up to you. Your model layer is up to you. Your view layer is dictated by what type of app it is (server,
GUI, command-line utility, etc). You’ve got complete freedom from beginning to end.
Finding the right platform
But that’s not unique to the
JVM. You’ve also got that same property with C and C++ and Ruby and Python, right? Let’s face it, a Lisp implemented in Ruby or Python is redundant: you already have 90% of the features you would want anyway, so there’s no motivation to go the extra mile just for macros, plus it would be much too slow.
And there’s no sane interoperability from an algorithmic language like Lisp to a processor-driven language like C or a spaghetti-driven language like C++. Who frees what memory when, and where did my chicken go? Suddenly everything’s a confusing mess.
Other potential niches
For a second, it seems like there’s another option: to go the route of Ruby and Python, by writing an interpreted Lisp dialect with its own set of standard libraries. After all, those two languages are pretty successful, right?
But that dream dies quickly with the realization that those languages each provided an emacs-free
REPL which anyone could quickly leverage to become an expert in the language in weeks flat. The s-expressions inherent in Lisp simply won’t allow for that.
Or a new Lisp dialect could take the Go approach and become a static language with super-fast compile times and execution times. But I don’t think that’s what people mostly care about. You can’t get faster compile-times than 0, which is where Ruby and Python are at. And you can’t get much faster execution times than the
JVM, theoretically, under particular circumstances (when certain stars are aligned and you hop on one foot 3 times).
To the foreseeable future!
The fact is, no other platform out there right now can provide the standard libraries, third-party support, extensibility, well-rounded feature-set, community support, and portability like the
JVM can. Clojure is currently the best incarnation of Lisp we have, and will remain for the foreseeable future.
My name is Steven Degutis, and I've been writing software professionally for a decade. During that time, I've written many apps and websites, quite a few techical articles, and kept up-to-date with the rapidly evolving software industry.
If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at firstname.lastname@example.org to set up a phone call.
- Self-employed – present
- Clean Coders – 5 years
- 8th Light – 2 years
- Big Nerd Ranch – 1 year
- Self-employed - 1 year
- Web: full-stack
- iOS (UIKit)
- macOS (Cocoa)
- REST APIs
- AWS / EC2 / ELB
- HTML5 / CSS
Over the past decade, I've written a total of 169 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.
Subscribe via RSS / Atom.
- 2017 — "Clean code" isn't actually clean
- 2017 — Passion in your field is overrated
- 2017 — What I learned in 5 days of writing an experimental website
- 2014 — Age of the Polyglot
- 2013 — How to Program
- 2013 — Ignore the Naysayers
- 2013 — Writing Clearly
- 2012 — Reinvent the wheel
- 2010 — Good usability
- 2009 — Twitter is the wrong tool
- 2009 — We're all pretty bad at driving
- 2008 — Why I Code
|March||Notes on Haskell Extensions|
|February||Second thoughts on front-end tools|
|February||First thoughts on front-end tools|
|February||Some thoughts on GUIs|
|February||First thoughts on OCaml|
|February||First thoughts on Haskell|
Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.
I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.
This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.
When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.
I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.
Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via Stripe.com) seamlessly into web apps, for a frictionless and pain-free payment experience.
This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.
This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.
This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.
As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.
These may be tiny, but they're interesting technical feats.
|Lua4Swift||Swift framework for embedding Lua with a native Swift API.|
|choose||Command line fuzzy-matching tool for macOS that uses a GUI|
|music||Command line music daemon for macOS that only speaks JSON|
|hecto||Command line text editor with an embedded Lua plugin system|
|ZephSharp||Window manager for Windows using Clojure for scripting|
|management||Minimalist EC2 configuration & deployment tool in Ruby.|
|go.assert||Assertion helper package for writing tests in Go.|
|go.shattr||Go library for printing shell-attributed strings to stdout.|
|OCDSpec2||Objective-C based testing framework with Xcode integration.|