The Land of Lisp

While if they use Emacs' lisp features that approach could be useful for some people (mainly those unfamiliar with or undecided on an editor to use), it's likely to strike others that don't already use Emacs as extremely annoying. I'm glad I haven't encountered that (but I haven't read a book on Lisp either).

It is now several years later and I have earned my living ever since by working in another lisp, Clojure. And I have indeed learned a lot along the way and what I've learned does indeed translate to how I work in other languages (even C++, which I also love).

However -- it is not all roses and nicely-flavored toothpaste after a savory feast. There is one aspect to lisp programming that, by virtue of its dynamic typing, I still find myself struggling to reconcile. No matter how much I marvel at what I can do in one or two lines of lisp, I do still often find myself making dumb mistakes that a compiler would catch instantly. Without type annotations and checked structured data for everything, it can also be hard to remember what a function does, or what its variables represent, when you read the code later.

One aspect of this that has made a big difference is naming -- how you name things in lisp and dynamic languages is a skill in its own right that helps guide the readability of code in the absence of types. When I look at C++ code I've written, the verbosity of naming is a clear influence from lisp. And it is an improvement.

The other feature that occurs more often is in-line documentation. It is a joy to read Clojure programs (the good ones, anyway) where every (non-trivial or meaningful) function has a little paragraph summarising what it does. This is just good in any language, but somewhat essential in a dynamic one.

Finally, run-time contracts and things like Clojure.spec come about to help fill the void of static typing. The problem I have there is that you add back into your code a fair amount of the verbosity that was removed in the first place by using a dynamic language (just look at Clojure.spec's lengthy annotations for a function signature, and I find myself wondering... why god oh why?). At which point, I then wonder why not just go back to using a static language.

So using lisp taught me perhaps one final, frustrating lesson: there are just great things about both dynamically typed and statically typed languages, and I've learned that the fence is an awkward place to sit.

This is one of the best criticisms of Design Patterns i've ever read. Great point.

Now I'm learning Racket, and Typed Racket feels great so far (despite a few awkward spots). You don't have to sit on that fence; you can switch between typed and untyped code at will.

I guess this problem you mention must be Clojure-specific, because in Common Lisp you can declare the data types of the input parameters and all return parameters, and have the compiler (i.e. SBCL) do static type checking; also the compiler can tell you which data types are accepted and returned by your function, by use of the "describe" function.

Furthermore, you can define your own types, structs, and classes, and the declarations (and static type checks) will work with them as well.