This article dispels some untrue preconceptions commonly held by novices venturing into Lisp.
We do this by stating answers often given to questions presented by Lisp novices.
This article dispels some untrue preconceptions commonly held by novices venturing into Lisp.
We do this by stating answers often given to questions presented by Lisp novices.
Many people acquainted with other programming languages take an interest in Lisp based on advice, hype, rumour or plain curiosity.
Whatever the motive, they often dive in expecting to find a new but mostly familiar culture, but are shocked to find this is not the case with Lisp.
The resulting confusion and turmoil is naturally undesirable for everyone concerned—the student as well as the communities they engage.
Here are some things that, in my opinion, you might want to know if you're considering learning and using Lisp for the first time.
"Lisp" here refers to Common Lisp.
That is, there is no one true Lisp download. There are many.
By visiting python.org or ruby-lang.org, you can find obvious "download" links to fetch an official release of those systems. This isn't quite true of Lisp, because there are multiple Lisp implementations.
Each one implements the ANSI Common Lisp specification as faithfully as it can, but differs in aspects such as additional extensions, platform compatibility, licensing, community support, history, and so on.
You will need to choose an implementation to learn. Consult a list of available systems. Prefer one that targets your OS platform, and that you have access to support for. (I recommend free Lisps such as SBCL, Clozure, ECL and CLISP.)
This is not unlike the multiple implementations of Python or Ruby—Jython, JRuby, etc. However, because Lisp has a well-specified standard, there is no need for a canonical reference implementation.
That is, there is no one true Lisp community. There are many.
Some communities form around particular implementations of Lisp. Others around particular projects, applications or libraries. Others in particular geographic regions, internet spaces, academic institutions, or companies. Others with particular interests—e.g. free Lisp software.
Consequently, there are many websites, "home pages", and discussion groups around Lisp. There are multiple wikis, multiple directories, IRC channels, news groups, discussion forums, etc.
There is not necessarily a consensus among any of these communities or individuals, besides the language spec. The spec in its current form has been frozen and stable for years.
There may be broad agreement on some issues like code style, portability guidelines and so on, but this is rarely universal, and not determined by a central project.
That is, there is no one true Lisp development tool. There are many.
Many users, especially in *nix or free software environments, use Emacs with SLIME. However, you may choose Vim with an extension like Limp or Chimp, or Eclipse with Cusp, or a bundle like Readylisp or Lispbox, or a shrink-wrapped system like LispWorks or Franz provides.
You really will need a decent Lisp-supporting editor. Learn to use one of the above, so you can efficiently manipulate structured Lisp code, format it correctly, and interact dynamically with running Lisp processes. (I recommend Emacs with SLIME.)
Note that even in the Java world there are many IDEs—Eclipse, NetBeans, etc.
There are native Lisp editors like Climacs and ABLE, which are usable but in comparatively early development.
The standard doesn't include "batteries" like sockets, HTTP services, date and time calculation, extensive OS facilities, foreign-function interfaces, etc.
This is because the Lisp standard tries to specify a portable language, not a library. Note that even the C language doesn't include these things.
But Lisp implementors and developers are free to provide libraries, and they do. Most implementations include their own extension packages with such APIs. And many third-party libraries are portable across implementations.
Lisp is a general-purpose language. You can service most computable tasks with a Lisp system. There are libraries for web serving, GUIs, text processing, mathematics, OS integration, dates and times, FFIs, and so on.
They are not all portable across implementations and OSes, but by selecting your deployment environment thoughtfully, it need not be an obstacle.
There are tasks for which Common Lisp is ill-suited. For example, some kinds of embedded systems programming, requiring direct machine access or pathologically confined resources; or situations where legacy constraints limit choices, etc. These are special cases.
In general, Lisp can be a candidate in at least any domain you would consider using a language like Python or Java or high-level C.
Lisp is not just for artificial intelligence research. It's not just for list processing. It's not only for functional programming.
Lisp is a multi-paradigm language, embodying a variety of useful and interesting concepts. Only a small subset of it is functionally oriented.
For instance, the standard includes a sophisticated object-orientation system (CLOS), which is far more advanced than OO of the kind in Java, C++, C#, Python or Ruby. There are also many imperative and procedural constructs (e.g. the LOOP macro).
Lisp does provide lexical closures with first-class functions, and some functional operators for mapping, reducing, filtering, etc. But this is not a generally enforced style.
Instead it forgoes many notions of functional programming, such as immutability, laziness, and constrained side-effects—unlike, say, Haskell or Clojure. Such a functional style would be non-idiomatic Lisp for most purposes.
If you're after good, honest functional programming, look elsewhere.
Lisp programs can perform well, with the right implementation and optimizations. Many Lisp compilers target native code (not only bytecode), and the standard allows various hints and declarations to adjust compilation strategies.
However, you won't need such performance in early development, especially when learning a new language. Novices sometimes try to make "efficient" programs by prematurely optimizing, resulting in code that's incorrect, difficult to understand, or not even performant.
Rest assured that Lisp can support high performance when the time comes. Focus instead on correctness and good style when researching, rapidly prototyping and incrementally growing your application. Save valuable developer effort, not cheap computer resources.
(Of course, you can easily take advantage of the "free" performance benefits of using a compiled implementation with high-level data structures and algorithms.)
They're a feature, not a wart. The parentheses capture some very important information: the programmatic structure of your Lisp code. Lisp is a homoiconic language—that is, its code is represented by its own data structures. Eliminating parentheses will only spoil this quality.
Use a good editor (see above) that provides syntax highlighting, formatting rules, code traversal and manipulation shortcuts. Spend some time getting used to reading Lisp; it can take a little exposure to get over the parentheses, and even more to begin exploiting them to your advantage.
A frequent mistake some novices make is to invent new surface syntax for Lisp that eschews parens. These efforts invariably fail. Don't waste your time on it, unless you happen to have a genuine interest in programming language research or something like that.
While we're at it, the name "LISP" is obsolete. It's reminiscent of variants of the broader lisp family of languages, circa 1980. We're talking about Common Lisp instead, often shortened to "Lisp", being a much more modern language. Besides, "LISP" reads like you're shouting. :-)
This article only claims to represent my own opinion, formed through experience and observation as a novice, in only a few years of learning Lisp. YMMV.
| Author | Abhishek Reddy |
| License | CC-BY-SA 3.0 |
| Created | 2009-252 |
| Updated | 2010-207 |