Atomized

Why Lisp is Awesome

A few weeks ago, I was talking to some people about the nerdy things I work on, and the nerdy things I like. The conversation inevitably turned to Emacs and Lisp, and someone asked why I liked them so much.

There are a lot of reasons, but I think the main one is that it’s such a pioneering and influential language, and most people aren’t aware of it. An astonishing number of language features we take for granted owe their existence to Lisp.

• The switch statement. In lisp, this works like so:

  (cond
      ((= var "foo")
       (message "This is the foo block."))
      ((= var "bar")
       (message "This is the bar block."))
      (t
       (message "Default case")))
  

  This is equivalent to the following code in C:

  switch (var) {
      case "foo":
          printf("foo block.");
          break;
  
      case "bar":
          printf("bar block.");
          break;
  
      default:
          printf("Default case")
  }
  

  As you can see, they both have advantages and disadvantages:

  • The lisp version is more succinct.
  • In lisp, you can test for any condition, whereas C only lets you test one expression. This is a wash, since if you want multiple tests on the same expression, you have to repeat it throughout the (cond).
  • There’s no way to fall through in lisp like there is in C.
  • …But, your condition can be an expression in Lisp, rather than a simple test for equality, so your condition could be (cond (or "foo" "bar"))
  • As a commenter points out, you can use switch(true) to test more complex expressions in your cases. While this works, it feels pretty hacky.
• Lambda functions. One of the fundamental building blocks of Lisp, lambdas have gained widespread adoption in modern languages like JavaScript, PHP, Python, Perl, Visual Basic, Ruby, and C#.
• Hand in hand with lambdas, functions are data. That is, you can pass a function to another function. A function can return a function. Using lambdas, a function can create an entirely new function, return it, and it may be passed to yet another function.
• Closures. In a nutshell, closures give you a private, inherited namespace. So if your parent closure defines a variable x = 5, and you create a closure inside it, you also can see that x = 5. If your closure changes that to x = 50, that is invisible to your parent closure, but visible (in the same way) to any closures that closure creates. Essentially, it’s a private copy-on-write namespace. Closures were first implemented in Scheme, a Lisp-descended language. Before that, the let expressions gave some of the flexibility of closures.

  (defun print-foo ()
      (message foo))
  
  (setq foo "Foo")
  ;; Calling (print-foo) will print "Foo".
  
  ;; Inside the let block, 'foo is changed to "bar".
  ;; Evaluating this prints "Bar".
  (let ((foo "Bar"))
      (print-foo))
  
  ;; This prints "Foo" again
  (print-foo)
  

• Dynamic programming. With fset, you can change any function. Common Lisp adds flet, which works the same as let, but on functions. So you can change how library code works at an extremely deep level, but keep those changes out of the way of other code which expects the stock behavior.
• Data is code. This is an extremely powerful concept, and it’s been seen more recently in JSON. The basic idea is that you leverage the language parser to parse complex data structures, rather than writing your own parser.

  '((item-one . (foo bar ))
    (item-two . (baz quux)))
  

  This is equavalent to

  {
      "item-one": ["foo" "bar"],
      "item-two": ["baz" "quux"]
  }
  

  In other words, your data is expressed in the same literal notation as if it was in your code.

• And-or trick. At least Python and Ruby have copied this feature. In Lisp, boolean expressions don’t evaluate to true or false; rather, they evaluate to the portion of the expression causing the test to pass or fail. This sounds much more complicated than it really is. Here’s are some sample expressions:

  0 || 99;
  

  In C, this will return TRUE; The zero is considered false, and non-zero is true. Since the condition is true, true is returned.

  (or nil 99)
  

  The same test in lisp. Rather than return t (Lisp’s equivalent to C’s TRUE), this expression returns 99. The value 99 is what caused the expression to terminate, so it’s value is returned.

  It’s hard to understand the power of this at first, but consider the case where you want to assign the variable x the value of variable a if it is not false, or b otherwise. In C, you have:

  if (a) {
      x = a;
  } else {
      x = b;
  }
  

  Not very elegant. You can use the ternary syntax, where it becomes:

  x = a ? a : b;
  

  This is better, but note how you have to repeat the a variable twice. Contrast this with the lisp version:

  (setq x (or a b))
  

  No repetition. While it’s actually longer than the C version in this simple example, you gain much benefit when you use more complex expressions, such as ones where you want to assign the return value of a function if it’s true. In C, you’re stuck with calling the method twice, or assigning it’s output to a variable before the test.

  In Python, you’d use:

  x = a or b
  

• References. Lisp’s basic data structure is the linked list. What’s interesting is how they’re managed. Lisp lists are constructed from cons cells, where the first half (the car)points to the data for that cell, and the last half (the cdr, pronounced "coulder") points to the next cell; the last cell in the list has a null pointer. The really neat part of this is that everything is a pointer. So every member of a list exists on it’s own, and other lists are free to point to it. Consider this:

  ;; This sets 'ex to a two-element list: (foo bar)
  (setq ex '(bar baz))
  
  ;; This creates a new list 'ey; the first cell is 'foo, and the rest of the
  ;; list is the contents of 'ex.
  ;; Evaluating 'ey will show: (foo bar baz)
  (setq ey (cons 'foo ex))
  
  ;; This sets the first element of 'ex to quux
  (setcar ex 'quux)
  
  ;; Evaluating ex now produces: (quux bar)
  ;; Evaluating ey produces: (foo quux bar)
      

  This works because ey’s cdr points to ex; it hasn’t copied ex, it’s incorporated it by reference.