Can a lisp ever go away

Lisp - a guide for beginners

A God's Lament

Some said the world should be in Perl;
Some said in Lisp.
Now, having given both a whirl,
I held with those who favored Perl.
But I fear we passed to men
A disappointing founding myth,
And should we write it all again,
I'd end it with
A close-paren.

- Randall Munroe, XKCD # 312

Table of Contents


This document is intended to answer some questions often asked by interested newbies, to clear up common misunderstandings and to serve as an entry point for those interested in learning.

It is probably not completely objective and unbiased, but rather an in some ways judgmental compilation of advice that the author would intuitively give if faced with someone who had a few questions about Lisp and wanted to know where and how to start and more to learn about this family of languages ​​little known to most.

If you've never tried computer programming, you should probably start right away in the "Getting Started Resources" section. I would like to ask everyone else to be patient with me and at least read the section "Is Lisp Still Interesting?" The remaining chapters can then be dealt with at your own discretion and interest.

Factual corrections and suggestions for improvement are always welcome.

Is Lisp still interesting?

Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA / Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. - Kent Pitman

Anyone who hears the name "Lisp" may think, as far as he can imagine anything under it, of an antiquated language that is at most of historical interest. Anyone who has already researched a little further may have heard of the two dialects that are relevant today, Common Lisp and Scheme, and got the impression that, on the one hand, Scheme may be aesthetic, but definitely academic and unsuitable for practice, and Common Lisp is baroque, outdated and overly complex Are languages ​​whose innovations may have been of interest twenty years ago, but are already supported everywhere today (e.g. in Java, Python or Ruby).

These typical impressions are not entirely wrong and not entirely right: Scheme is, at least if you only use it to refer to a Standard Scheme, in fact primarily a teaching and research language that can hardly be used productively without major additions. It is also true that Common Lisp is big and that many of the once outstanding features have now found their way into other programming languages. Nonetheless, both languages ​​still offer functions that cannot be found anywhere else in such a clear and consistent form and the learning of which can enormously expand the learner's horizons - and the latter in particular should appear to a good computer scientist to be worth striving for. In addition, the practical inapplicability of Lisp (especially Common Lisp) is not as far off as you might think. But more on that later.

First I would like to get rid of one clarification: Common Lisp and Scheme look very similar to one another, but they are still fundamentally different languages. Anyone who has already learned Scheme (e.g. while doing an introduction to computer science) shouldn't throw away Common Lisp with a wave of hands, because at first glance it looks like an uglier brother of Scheme. Appearances are deceptive: Hardly anyone writes their loops in a recursive style, e.g. in Common Lisp, and tangible object-oriented programming is the order of the day. These, too, are only two rather weak and superficial examples of the differences between the two languages, and there is still a lot to discover in Common Lisp, even for Scheme connoisseurs.

This guide is primarily about Common Lisp, not Scheme. Up to now the term "Lisp" has encompassed both languages, but in the following it basically refers to Common Lisp. Wherever information about Scheme fits, it is of course mentioned anyway.

What makes Lisp so special?

[The student] can so completely indulge in what he naively thinks is computer science, the mere refinement of his programming techniques, that he effectively prevents himself from studying anything really important. - Joseph Weizenbaum, The Power of Computers and the Impotence of Reason

The main reason why Scheme is interesting is that the language is very small and consistent, and that functions are treated like any other object. Common Lisp, on the other hand, is a language that not only embodies a single concept, but rather is characterized by its integrated diversity and contains a lot of concepts that may seem completely foreign even to an experienced programmer, although some of them can hardly be different have attainable practical value. Examples are:

  • The error handling and signaling system that goes far beyond mere exceptions.
  • The ability not only to execute self-defined code at runtime, but also at compile time and even at source code reading time (i.e. the ability to control compilers and parsers).
  • The integration of functional, object-oriented and imperative programming in the same language.
  • The flexible class-based object system which, when combined with the package system, removes the horror of multiple inheritance and multiple dispatch.
  • Macros.
  • The interactivity of the whole system, combining development, testing and troubleshooting into a single activity.

Many believe that macros are the key differentiator between Lisp-like languages. Others see the incomparable interactivity of programming in Lisp as its great advantage. So opinions differ here.

This lack of consensus is also the most likely reason why development feels so different in different Lisp environments, especially between Scheme and Common Lisp. Most Scheme implementations do not place as much emphasis on interactivity as most Common Lisp environments.

Be that as it may, there is no doubt that the Lisp community has its very own traditions and ways of thinking, and that membership of a language in the Lisp family is not a purely technical but also a cultural question that leads to a certain degree Only in the last instance can be answered emotionally.

Historical note: While today Scheme and Common Lisp are collectively referred to as the two important Lisps - which is also the view of the majority of the Scheme and CL communities - there is no absolute consensus in both of them that they actually belong to the Lisp family. About twenty years ago (i.e. in the late 80s) it was still quite controversial whether the Common Lisp, which was still in development at the time, should still be recognized as a Lisp, because it radically broke with many traditions. Interlisp supporters in particular saw Common Lisp as an attempt to undermine the spirit of Lisp in his own name and to murder the true Lisp tradition from behind. Unfortunately, I personally never had the opportunity to work with an Interlisp system, which is why I cannot judge whether there was or is something to these concerns or not.

Scheme and Lisp

Is Lisp a Functional Programming Language?

(Of course SML does have its weaknesses, but by comparison, a discussion of C ++ 's strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) - Thant Tessman

Yes and no. If someone calls Lisp a functional programming language, then it is probably about Scheme, in which the functional paradigm is actually often used. Common Lisp programmers write their code much less in a functional style and use all sorts of paradigms depending on the situation. Since Common Lisp has a powerful built-in object system, modern Lisp programs are mostly written in a combination of functional, imperative and object-oriented styles.

The point to remember here is that it doesn't mean much that a programming language is functional. Treating functions as objects like any other is one thing (and indeed all Lisp family dialects support it); Whether code is written in the respective language but also in a functional style depends more on the people who use the language than on the purely technical properties of the language itself.

How much is the difference between Scheme and Common Lisp?

How many Schemers does it take to change a light bulb? Eventually a Common Lisp programmer changes it because the Schemers were all worried about the side-effects! - Sohail Somani, comp.lang.lisp

Read they think we're mean-spirited about them, I sort of imagine the Schemers probably have the reverse sentiment ... How many CL programmers does it take to change a light bulb? None. They don't want to be enlightened. - Kent Pitman, follow up to the above

The differences between Common Lisp and Scheme are not only technical, but above all social and political. Two languages ​​that start out similarly, but are further developed by very different communities, drift further and further apart over time.

Where Lisper emphasizes practicality, Schemer emphasizes elegance and compactness, and where Lisper emphasizes interactivity, Schemer emphasizes the clear semantics of program text. Such differences in views are of course reflected in the available development environments, libraries and programming methodologies of the two camps.

Occasionally the opinion is even expressed that Scheme has strayed so far from the spirit of Lisp that it can no longer be described as a Lisp. (Conversely, the same has been said about Common Lisp - primarily by Interlisp supporters.)

Historical note: You can now even hear voices from within the Scheme community itself who no longer recognize the latest incarnation of the Scheme standard, R6RS, as a lisp. At the same time, some critics have made it their business to develop an alternative standard called ERR5RS to counteract this development. What the implications of this novel controversy will be and what it will mean for the Scheme community is still uncertain.

Where should I look if I'm interested in Scheme?

First of all, it is a good idea to choose a specific Scheme implementation, as there is little point in trying to stick to the standard, which is known to be very small and offers little functionality on its own. Good candidates for this are DrScheme, Chicken Scheme, MIT-Scheme, Scheme48 and GNU Guile, with DrScheme having the most beginner-friendly development environment.

Web sites of interest are,, and the SchemeWiki.

newLISP also sounds like an alternative. Is it one?

About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. - Edsger Dijkstra, How do we tell truths that might hurt?

The short answer: No.

The main flaw of newLISP is its name: it should actually oldLISP ring.

newLISP reintroduces many ideas that the Lisp community, after a long struggle with itself, ultimately recognized as misguided and left behind. These include, for example, the dynamic variable binding as a default and the lack of macros in favor of functions that do not evaluate their arguments (FEXPRs, as they were called in the old MACLISP). In addition, it sometimes makes compromises of a kind that both Lispers and Schemers are at most wearily ridiculed (e.g. the lack of proper automatic memory management with constant deep copying of entire data structures as an apparently less expensive alternative).

Overall, newLISP only repeats the mistakes of the past and at the same time offers nothing essentially new - at least from the point of view of today's Lisp community.

Certainly: who knows - maybe newLISP and even more so Pico Lisp are also cloudy windows into another world in which the forgotten traditions of languages ​​like Interlisp, which have their best days still to come, live on.

But for the here and now, if you want to experience the Lisp experience from a quarter of a century ago, you can take a look at newLISP. In all other cases I would personally advise against it.

Comment: All of this is not to say that newLISP does not have its place in a good craftsman's toolbox. According to its author, it is not intended to compete with Common Lisp and Scheme, but purely for "scripting", for which it may or may not be well suited. All I want to say is that if you are new to Lisp you shouldn't learn newLISP because it gives you a completely wrong, namely anachronistic, impression of what Lisp is today.

Resources to get you started

After hopefully answering the most burning questions, we now come to the sources of information that you need as a beginner.

The first installation of a Lisp environment

The Lisp compiler and SLIME

First you should install a suitable Lisp environment (see also the next section on choosing such a system).

On Windows you should try the Personal Edition of LispWorks and Edi Weitz's STARTER-PACK to start with. It automatically configures ASDF and installs some frequently used libraries at the same time.

Debian and Ubuntu users have it relatively easy. You can install a Lisp compiler offered by your distribution in the normal way, e.g. for SBCL:

sudo apt-get install sbcl

ASDF systems can also be installed, e.g. like this:

sudo apt-get install cl-ppcre

Then you can start Lisp and e.g. enter the following to load CL-PPCRE:

(clc: clc-require: cl-ppcre)

The Debian package name does not always have to be the same as the system name. Sometimes it is necessary to leave out the "cl-" in the system name, for example.

You can find out which libraries can also be installed by using the capabilities of (by the way, a very useful tool in general):

apt-cache search '^ cl-'

In any case, it is a good idea to also install SLIME:

sudo apt-get install slime

When you have done that, you can start SLIME from Emacs with (i.e. Alt-X, followed by "slime" and confirming with the Enter key). (Depending on the Lisp implementation, i.e. Control-U, Alt-X, »slime«, , works better because it also asks for the name of the Lisp compiler you want. Here you can enter, for example, »sbcl«.)

All other I recommend using clbuild, a script that performs a similar task under Unix-like operating systems as STARTER-PACK under Windows. It can also download and install SBCL if necessary. SLIME can be started by calling. An alternative to this is Lispbox, which also comes with a whole, preconfigured Emacs.



ASDF-INSTALL allows systems (i.e. libraries and applications) to be automatically downloaded and installed along with their dependencies.

When ASDF-INSTALL has been installed, set up and loaded, you can, for example, install CL-PPCRE by entering the following:

(asdf-install: install: cl-ppcre)

To load an already installed system (here CL-PPCRE):

(asdf: oos' asdf: load-op: cl-ppcre)

In SBCL (but only there!) You can save yourself the later cumbersome incantation for loading ASDF systems and use it instead:

(require: cl-ppcre)

To install new systems, however, there is only the "normal" command in SBCL.


The ASDF-INSTALL tutorial describes how to set up ASDF and ASDF-INSTALL in Lisp environments other than SBCL.

If you use SBCL, you don't have to worry too much, as it comes with both ASDF and ASDF-INSTALL in the standard installation. In this case, the following lines are sufficient for loading.


(require: asdf)


(require: asdf-install)

Which Common Lisp implementation is right for me?

In the case of Common Lisp, the choice of implementation is far less important than it is for Scheme, as it is easy to write portable code that runs equally on all of them. It is best to orientate yourself on the development environment and the desired license.

There are unlimited free versions for the non-commercial use of Allegro CL and LispWorks, which both come with high-quality development environments and extensive documentation and are suitable for programmers without Emacs experience (and those with negative Emacs experience).

Windows users should try LispWorks first and install Edi Weitz 'STARTER-PACK. It takes over the configuration of ASDF and allows you to install a lot of useful libraries at the same time (see the previous section on setting up a Lisp environment).

If you prefer free software, SBCL is the first option, which runs on many platforms and is well supported by the Emacs-based SLIME development environment. Its main drawback is the still in its infancy Windows version, which can be a knockout criterion for many. (But don't forget: It is usually not a problem to develop in SBCL and later deliver the finished program with a more Windows-friendly Lisp.)

Mac OS X users might find Clozure CL interesting. In contrast to SBCL, it also supports multithreading under Mac OS X and allows native GUI applications to be implemented directly with Cocoa. It also allows access to all other libraries available to an Objective-C programmer.

If you are looking for a free Lisp for Windows, you can use GNU CLISP. Unfortunately, SLIME support for CLISP isn't the very best, and CLISP compiles in bytecode, not machine code. The latter is certainly not a big problem for the development itself, but the former can be a bit annoying.

Whichever system you prefer, the author of the online Lisp book Practical Common Lisp has a pre-built, Emacs-based package called Lispbox that is specially set up for beginners to use with the book. The beginner-friendly development environment ABLE, which is also available as free software, is an emacsless alternative.

At this point I would like to advise against GNU Common Lisp (GCL), a Lisp compiler based on an outdated version of the Common Lisp language. It lacks critical development tools and has few newly developed libraries to support it. GCL has its place, but a beginner should choose a different Lisp system. Under no circumstances should GNU Common Lisp be confused with GNU CLISP.

Tutorials and books

The most recommendable introduction to Common Lisp, which is free to read on the Internet and available as a printed book, is Practical Common Lisp by Peter Seibel.

For ambitious advanced learners, Paul Graham's book On Lisp, which can also be downloaded for free, is suitable, as it introduces the reader to some techniques and tricks that are not covered in most introductions.

Another book that can also be read online is Successul Lisp by David Lamkins. It's not as new as Practical Common Lisp and isn't recommended as often. Although it is less practical and less suitable for people inexperienced in programming, it is worth a look if you are looking for an alternative point of view.

reference books

What you should always have at hand is the CLHS (Common Lisp HyperSpec), which is basically not strictly official, but at least it is de facto represents reference documentation of the Common Lisp language that corresponds almost exactly to the text of the ANSI standard. She has her own style of writing, but there are people who prefer her clarity and precision over everything else. For a specification it is undoubtedly unusually reader-friendly.

Usually, good Lisp development environments always offer quick access to the CLHS by moving the cursor to the class / function / etc. name in question and pressing a certain key combination or selecting a menu item.

If you don't know exactly what you are looking for, you can open the table of contents of the ANSI and GNU Common Lisp Document and do a bit of searching (e.g. using the search function of the web browser). Like the CLHS, it corresponds to the ANSI standard in terms of content, but is prepared a little differently.

Another work that is worth looking into from time to time is Guy Steele's Common Lisp the Language (second edition). CLtL2 describes, as the book is briefly referred to, a version of the language that does not exactly correspond to the ANSI standard, since it was written before the completion of the ANSI standard, but visible deviations can only be found in places that a novice cannot actually access should bump so quickly.


Some addresses for which is its own loop language embedded in Lisp:

Support from like-minded people and experts

If you are looking for support or answers to a specific question, the best thing to do is to contact the comp.lang.lisp newsgroup. Despite all the rumors, the people there are really very nice and happy to help.

Since there is unfortunately also a nontrivial number of trolls (i.e. nuisance makers) there, it may well happen that some comp.lang.lisp members react somewhat defensively when questions are asked that show some or all of the following symptoms:

  • They are actually not questions, but statements.
  • They indicate that the questioner thinks he knows everything better than those to whom he is addressing the testimony - especially what is good for them. (“If Lisp doesn't so and so changes / adapts to the rest of the world / etc., you can never save it! «- Who says that Lisp is in a state in which it has to be» saved «? Perhaps the questioner sees it that way, but hardly anyone who is successfully using Lisp productively at this point.)
  • They bring the same well-meaning suggestions that have been made at least twenty times in the same month, each time by an enthusiastic newbie who has never written a line of Lisp code. ("You should build a large, well-documented standard library!" so and so changes, you can attract a lot more newbies! ”And so on. How likely is it that in fifty years no one has come up with the same brilliant idea? We all already know the ideas. It would be helpful if someone really did the necessary manual work.)

Don't worry, it's not difficult to avoid these kinds of non-questions, and newcomers are otherwise very welcome in comp.lang.lisp.

Of course, you should also observe the Usenet etiquette, which is valid everywhere, and show, if possible, to what extent you have already dealt with the question asked. Someone who asks every question in a newsgroup without having at least looked for an answer in Google beforehand will generally meet with little approval on Usenet.

A side note: comp.lang.lisp is probably the only place on the Internet where you can meet members of a technology community of any generation. Both young Lispers and seasoned veterans who have worked in Lisp machine companies or who have even been involved in the design of influential Lisp dialects and who have become acquainted with all possible dialects in the history of Lisp as users or implementers frequent comp.lang.lisp. Historical questions are discussed there just as much as technical ones, and since the long tradition of Lisp has many details worth knowing for the inclined reader, the newsgroup is a good place for newbies and experienced people alike to kill time and actually write code for as long as possible to procrastinate. But you can treat yourself to that every now and then, because: What counts is the fun.

Libraries for GUIs, sockets etc.

The best way to find libraries and other code is to look in the CLiki and the Common Lisp directory. The latter also contains links to various types of documents.

My personal, specific recommendations for libraries are:

  • C libraries: CFFI.
  • Databases: CLSQL for traditional database access.
  • Databases: Elephant for a complete persistence solution.
  • Databases: Postmodern for PostgreSQL.
  • GUI: Clozure CL's Objective-C bridge for pure Cocoa development. (I would like to recommend my own Objective-CL at this point for creating cross-platform Cocoa / GNUstep GUIs, but unfortunately it is still in its infancy and is not recommended for a beginner at this point.)
  • GUI: LTk for traditional GUI development. In the latest version (8.5), Tk uses the nativeTheme engine under Mac OS X and Windows thanks to Tile, and the level of the previously admittedly ugly appearance has also improved many times over under Unixoid systems.
  • GUI: McCLIM for more exotic minds. Abstract GUI description - powerful and flexible, but strange and not necessarily visually appealing.
  • GUI: If you really don't want to part with Gtk +: CLG. (I still recommend LTk.)
  • Regular Expressions: Everyone uses CL-PPCRE.
  • Sockets: usocket.
  • String magic: CL-INTERPOL.
  • Threads: Bordeaux threads.
  • Different tools: Alexandria, SPLIT-SEQUENCE and Iterate.
  • Web applications: weblocks.
  • Web server: Hunchentoot.

If you have set up your Lisp with clbuild or STARTER-PACK, as suggested above, you can install some of these libraries with it.

Classic stumbling blocks

I don't fully understand the package system ...

If C ++ has taught me one thing, it's this: Just because the system is consistent doesn't mean it's not the work of Satan. - Thant Tessman

The package system is certainly one of the biggest stumbling blocks for a newbie who has already mastered other programming languages, as it contradicts the intuitions of a non-lispers in some ways and offers the confusion several opportunities to strike at once.

First of all, the most important thing is to understand what the packaging system actually is. One has to distinguish between two separate things that can easily be confused:

  1. A system is a collection of code (e.g. a lot of source files or object code) that can be loaded in order to make certain functions, classes, methods and other things available. So a system is what is called in languages ​​other than Library or module designated.
  2. A package is a namespace for function, class and variable names.

It is very important not to mix these two things together, because a priori they have nothing to do with each other. In particular, packages cannot be "loaded", but a system can (but does not have to) create one or more packages while it is being loaded.

Okay. So how does the parcel system work?

The central term in the package system is that one Symbol. A symbol is a name for a function, a class or a variable. For example, there is the symbol in the package, which is the name for a certain standardized function. At the same time, however, it also denotes a standardized class. Just writing, however, is ambiguous without context because there can be multiple symbols with the name, in different packages. The full, unique name for the symbol in the package is or alternatively. The part before the colons will Package prefix called.

When creating a package, symbols can be imported from other packages (using or, see description for defpackage). This makes them available in the new package and eliminates the need to specify a package prefix when referring to them from within the new package. However, it is important to realize that when you import from, you are not only importing the function that is identified with, but the symbol itself. If the new package is called, from now on and same symbol. In particular, you must not then define a function by name yourself, otherwise you will redefine the function!

Note: The package system works with symbols and symbols only. What the symbols designate, or whether they designate anything at all, does not matter to the package system.

Often there are quite unexpected conflicts when subsequently importing symbols or entire packages use-package (or when reloading a modified defpackage-Shape). To understand these conflicts, you have to know how the packaging system interacts with the reader (the part of Lisp that reads the code and uses it to make data structures that the compiler can understand). An absolutely readable explanation of what is happening there, which the author can recommend from personal experience, is The Complete Idiot's Guide to Common Lisp Packages by Ron Garret. Since it is very important to understand the package system in order to avoid frustration with Lisp programming, you should take the time to read the above article carefully and to play around a bit with the examples given.

And what about these "systems"? Libraries, did you say?

How systems work, i.e. collections of code that other languages ​​would call modules or libraries, is not specified in the ANSI-CL standard (although there was a standardization proposal for this). Fortunately, nowadays there is a de facto standard that all new releases adhere to: Another system definition facility (ASDF).

How to set up and use ASDF is described in the section on installing a Lisp system for the first time.

"System" is a fairly general term. If you write code yourself, you will also want to define a system with ASDF that describes the associated files and dependencies on other systems that are to be loaded by ASDF. You usually do this not only for libraries, but also for applications.

Get to know the foreign

Why the bracket-heavy syntax?

Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in. - Larry Wall

There have been more suggestions for more conventional syntax for Lisp than can be counted, and yet none of them have caught on. This came as a surprise to McCarthy, who invented Lisp in the 1950s, as he was still working on an alternative syntax himself.

The reason for this is the immense power that such a simple syntax - or actually: that Absence a syntax - brings with it. One can hardly overemphasize how much the equal treatment or standardization of code and data depends on the syntax, which at first glance seems strange, and which role this standardization plays for programming in Lisp.

Another, seldom-mentioned benefit of Lisp's syntax is the ability to use an editor that works at the expression level rather than the character level. In the past there were even structure editors for Lispcode, which some Interlisp fans still swear by. But even less radical approaches, such as the Paredit mode for Emacs, make navigating and working with S-expressions, as they are also called, more comfortable for the experienced than any editor for another language, however convenient.

This point is also related to the fact that many lispers point out that for them the brackets virtually disappear when they look at the code. The brackets are only a visual aid when looking at code, while the structure is usually revealed through the formatting. Therefore it is also important to either always indent Lispcode correctly or to let the editor do the indenting. (Emacs is hard to beat in this respect.)

Newbies usually ask the syntax question for one of two reasons.

The first reason is that in other languages ​​they have become so used to the fact that only complex expressions are bracketed that they automatically and unconsciously associate incomprehensible code with brackets. In fact, a lot of parentheses in other languages ​​is a sign that the code is poorly thought out and can likely be simplified. However, this is almost always a symptom of complicated operator precedence rules, which of course do not exist in Lisp.

The second reason is that newcomers often have concerns about whether the lack of visual cues in their source text, or even the unified notation, could make different types of expressions more difficult to distinguish than in other languages. In fact, in Lisp, distinguishing between types of expressions doesn't really matter, even if it may seem strange at first that an "if" query should have the same syntax as a function call. However, many text editors also highlight special expressions in Lispcode in color or bold, which means that these concerns will vanish with a little practice.

Isn't the great freedom in Lisp harmful to teams?

Just because we Lisp programmers are better than everyone else is no excuse for us to be arrogant. - Ron Garret

The fact that programmers can define their own special expressions discourages some who know from languages ​​like Java that the compiler wants to force programmers to write non-illegible spaghetti code from nothing but self-defined constructs. In practice, however, these fears mostly turn out to be unfounded, because the programmer, with the newly gained freedom, is able to write down his thoughts in such a way that repetitions are avoided and the code becomes considerably clearer.

And let's face it - bad, undisciplined programmers who don't adhere to coding guidelines are a disaster for any team, no matter what language is used. Horror stories in this regard are not uncommon, especially in the industrial Java world. So there is no reason to assume that virtual straitjackets will alleviate the problem.

More recently, the success of languages ​​like Ruby and Python, which also combine seemingly uncontrollable power with structured simplicity because of their inspiration from Lisp, shows that the practical problems of practiced freedom are nowhere near as great as one might expect.

Last but not least: Should it ever be necessary, because of the lack of syntax, it is comparatively easy to write code checking tools for Lisp that control compliance with coding standards. Lisp makes it easy for you. Can the same be said about Java?

Why the anachronistic names?

I invented the term Object-Oriented, and I can tell you I did not have C ++ in mind. - Alan Kay

Sometimes the unusual (lambda list) and sometimes anachronistic (and) to downright creepy () terms that some concepts and operators in Common Lisp have as an unnecessary hurdle. These concerns are justified, and the worth of an obscure name like is well arguable. At the same time, however, one can be reassured that nobody is forced to ever use them in their programs, since there are also the synonyms and - and even if they did not exist, it would be easy to define them yourself (this applies also for special expressions!).

The reasons for these apparent anachronisms lie on the one hand in the compatibility with old code, on the other hand in the tradition-conscious thinking of the Lisp community. Anyone who has got used to the sometimes quite nice-sounding, but above all technically precise jargon, is reluctant to give it up.

What one must never forget, however, is that each discipline develops its own jargon, which has both a cultural and political value (namely, the ability to delve into a certain culture or a certain thought pattern) as well as a technical value (namely precision). Neither of these two values ​​should be disregarded when complaining about the seemingly excessive use of technical terms by experts in a field.

As in many other aspects, the motto here is: close your eyes and go through! If you get involved in the foreign culture instead of closing yourself off from it, everything suddenly becomes half as wild.

How do I create an executable program (e.g. an .exe file)?

Some people, when confronted with a [programming] problem, think, "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski

The only helpful, albeit likely unsatisfactory, answer for a newbie is to first write the program in question and only then think about how to deliver it. I don't want to go into detail because the procedure differs from compiler to compiler, and it is really much, much easier to understand when you can already program in Lisp.

The key point, which should be enough for information at this point, is that it works, both under Windows and under other operating systems, but that it does not work nearly as a novice expects, and it is better to yourself save the specific transactions for later.

Is Lisp being used in practice anywhere?

I suppose I should learn Lisp, but it seems so foreign. - Paul Graham, November 1983

Franz, Inc. has a fairly long list of success stories on the use of Lisp in the industry on their corporate website. Many of the members of comp.lang.lisp also use Lisp at work or have even set up their own company with it. Paul Graham is a well-known entrepreneur who made a ton of money from Lisp.

Common Lisp is a standard that has been promoted by companies. From the beginning, the focus of the standard was on practical application in the commercial sector. Accordingly, it supports this purpose well.

Common misunderstandings

Is "CLISP" an abbreviation for Common Lisp?

There's an aura of unholy black magic about CLISP. It works, but I have no idea how it does it. I suspect there's a goat involved somewhere. - Johann Hibschman, comp.lang.scheme

No. CLISP stands for GNU CLISP, a very specific Lisp compiler - and by the way, not a particularly characteristic one. For example, it is the only Lisp compiler that is relevant today that does not generate machine code, but bytecode.

Is Lisp Slow?

A Lisp programmer knows the value of everything, but the cost of nothing. - Alan Perlis, Epigrams on Programming

Almost all Lisp implementations used to be interpreters, but those days are long gone. Lisp is one of the few languages ​​today that is both interactive and compiled into fast machine code.

Some implementations use interpreter and compiler at the same time (e.g. CMUCL), others only have one compiler (e.g. SBCL). The only relevant implementation today that does not contain a machine code compiler is GNU CLISP. Instead, it compiles in portable bytecode (similar to Java).

Matthias Benkard, April 5th, 2008, 10:08 pm CEST