Lisp -- The Secret Weapon

2/7/2006 10:07:47 AM

Lisp -- The Secret Weapon

Sriram Krishnan writes a post called “Lisp is sin,” which extols all the virtues of Lisp.

Once commenter in his post calls Lisp a secret weapon:

But I will make a closing comment - Lisp can be a developers "secret advantage". Partly the language partly that lisp systems tended to have very powerful development tool suites.. But I was able to develop large products with a tenth the staff that comparable "conventional" implementations would need. (example: building a whole AC cad system from scratch, including routing, automated device layout, "live schematic", functional simulators, and lots of etc.. with less than 20 man years of development investment - and several of them were fearing the language at the start...)

Another major and well known proponent of Lisp is Paul Graham.

I first picked up Lisp, after attending a special high school program sponsored by Columbia University, in which I took a course in artificial intelligence. I was fascinated by Lisp (my previous languages being Basic and 6502 assembler) because I was actually writing programs that dealt with higher-level human concepts like natural language and algebraic manipulation.

Sriram mentions how the notions of code and data merge in Lisp. Lisp makes it easier to build DSLs within the language; in fact, that style of programming is encouraged. DSLs can be interpreted in three different ways: (1) in the traditional way as data fed through code, (2) as data transformed into code via macros, or (3) as data simply executed as code. This is how I developed my habit of writing code as data first in XML or S-expressions. I have associated this approach with greater productivity and significantly less bugs.

Further mixing code with data, I also have an interpreter for a Lisp-like language in my software, similar to how Emacs has a built-in Lisp interpreter and actually encodes most of its commands within the Lisp language. I believe there is a GOF design pattern named after this approach, called the “Interpreter” Design Pattern.

In contrast to the underlying C# language, my internal language is primarily a “functional” and “logical” language, evaluates lazily, and performs computations symbolically rather than numerically.

I didn’t borrow everything from Lisp. My lists use vectors instead of linked nodes, because I believe that Lisp’s reliance of linked lists was a design mistake and somewhat ruined an elegant language. Each list has a head, which eliminates the awkward quote notation.

My language (which has 300 commands) is actually seamlessly integrated with C#.

Exp exp = Symbols.Plus[ x, 2 ]

or, via operator overloading,

Exp exp = x + 2 

List expressions are useful for performing pattern matching, logical reasoning, solving constraints, validation, and more. They tend to make programming more “intentional.”

It’s often said that all new language features simply borrow from Lisp, which was invented in the 1960s. For instance, C# 3.0 introduces lambda expressions, object initializers, query expressions, expression trees that have some root in Lisp.

Lisp is my secret David-and-Goliath weapon.






Net Undocumented is a blog about the internals of .NET including Xamarin implementations. Other topics include managed and web languages (C#, C++, Javascript), computer science theory, software engineering and software entrepreneurship.

Social Media