Comparing Lisp and Python
This was written in response to a post to comp.lang.lisp by Santanu Chatterjee, which asked, "So, what's so common between python and lisp? To me (I know absolutely nothing about lisp) they sure seem very different." The original post has Usenet Message-ID <bmcb90$7p5$1@baldur.whoi.edu>. Posted here at Kenny Tilton's request.

I'm rather new to Lisp still, but I find it interesting to draw up a list of some of the similarities and differences I've found, also coming from a Python background. Please don't take this as a statement by either a "Lisper" or a "Pythonisto" -- I'm just a security systems administrator who uses Python regularly and is trying to understand Lisp as well ....


They're both multi-paradigm languages with strong functional and object-oriented tools, introspection, and an interactive prompt (read-eval-print loop). They're both "practical" languages which, while they incorporate a lot of thought from computer science research, are intended for "real-world" programming.

They both have syntaxes which confuse people used to languages like C and Java. (That said, their syntaxes are very different from one another.)

They are both rather strong at dealing with complex data structures, more so either than low-level languages like C or text-processing languages like Perl. Likewise, they both have a lot of data types built into the language, rather than as add-on libraries -- diverse numeric types, hash tables, lists, and so forth.

Both support higher-order functions and lexical scoping; thus, both can support (e.g.) closures.

Both are strongly but dynamically typed. Lisp allows the programmer to specify types of function arguments, which serve as an optimization aid to the compiler. Likewise, both have automatic memory management (garbage collection) and separate the user from having to deal with the explicit allocation of memory.


Someone coming to both from the direction of C, Perl, or Visual Basic is likely to see a lot of similarities, despite the blatant visible syntax differences. That said, they have a lot of differences aside from syntax, too.

In the object-oriented space, Python is a single-dispatch language (methods are defined on classes) while Lisp is a multiple-dispatch language (methods are defined on tuples of argument types). That is, in Lisp, a method is selected on the basis of the types of all its arguments, not just the first one.

Python has more extensive type/class unification than Lisp. In Python, you can subclass the built-in types, such as numbers and lists. In Lisp, you generally can't. Python also uses the method call syntax for various basic operations upon built-in types (such as sorting a list); Lisp method calls look just like function calls.

Lisp uses user-defined classes as a more powerful sort of structure definition. Python uses classes as a general-purpose construct, serving the purposes of Lisp classes and structures as well as some of the roles for which Lisp uses symbols. (Or, put another way, Python classes are a lot like Lisp symbols -- they have identity, can carry around properties, can stand for callable functions, are used for exceptions, and so forth. They also serve the purpose of classes in OOP.)

Neither language supports strenuous OOP access control of the sort found in C++; if you can name a data element of an object, you can access it and change it. (This drives some OOP ideologues batty.)

Lisp has an immensely powerful macro system which allows programmers to define new syntactical constructs. Python has a clear distinction between syntax and user functions, although one can do some "macro- like" things using higher-order functions in Python. The importance of the Lisp macro system cannot be understated, though -- to Lispers, writing macros is not at all an unusual or remarkable thing; it is simply part of how the language works.


Both languages are to a certain extent misunderstood by those who have not used them. (This is probably true of all languages!) People coming from C-like languages criticize the syntax of both, largely because it is unfamiliar to them: Python seems to use too little punctuation, while Lisp seems to use too much! In the case of Lisp, this is a conscious choice to keep the language close to its own syntax-tree internal representation; in Python, it is a conscious choice to ensure that the visible representation matches the block structure.

Another thing common in these misinterpretations is the claim that either is an "interpreted language". Python is bytecode-compiled, like Java, with a native-code compiler under development for some platforms. Lisp can be either interpreted or compiled; production implementations mostly feature native-code compilation on demand, while one popular one (CLISP) does bytecode. Lisp is probably unique among languages in allowing extensive interaction between the user, interpreted code, and compiled code: from the Lisp prompt one can compile, disassemble, and trace arbitrary code, as well as call interpreted functions from compiled ones and vice versa.

In a sense, Python is more abstract than either C or Lisp. Just as C places the programmer close to the binary representation and the underlying hardware, Lisp places the programmer close to the syntax representation, the reader, and the compiler or interpreter. Python does neither, not allowing the programmer to manipulate binary structure in memory (like C) or syntactic structure in the program syntax tree (like Lisp). Put another way, Python is more restrictive than either C or Lisp ....


Culturally Python and Lisp are vastly different. While both are bound between the world of research and that of practical programming, Lisp has a much longer tradition behind it, and the tensions between academe and industry are more an elemental part of its culture. (Just listen in on any Lisp-vs.-Scheme discussion.)

The Python culture is connected to the Unix and Free Software (or Open Source) cultures; while it has made many efforts to extend itself to other platforms, it's in many ways a product of Unix, for instance in its ways of handling files and the network. It is also closely tied to Free Software -- Python itself is a Free Software product, with many developers contributing back to a single code base, while Lisp is a more industrial product with many commercial vendors (as well as open-source developers) separately implementing and extending an American (ANSI) industrial standard, namely Common Lisp.

It should be noted: Lisp pre-dates both Unix and Free Software, and there are some deep-seated disagreements between Lispers and both Unix fans and Free Software partisans.

(Python is also connected to the Unix idea of "scripting" and the use of disparate languages for different purposes. Thus, Python users do not consider it a weakness that the language is extended in C rather than being self-hosting. This may reflect a deeper disconnect in various people's views as to what a "computer language" is!)

Modern Lisp is the direct, lineal heir to a computing tradition going back almost fifty years, to before the dawn of anything new users would recognize as a "modern" computer system. This manifests both in its syntax and its culture: there are features Lisp has that no other current computing system does, and Lispers know it. Python, on the other hand, is a comparatively brand-new system, which "cherry-picks" features from the history of computing languages, fitting them into a minimal system which seems almost ahistorically abstract.


If you're coming from Python you might also want to look at Peter Norvig's article "Python for Lisp Programmers." (Added by Edi Weitz, 2003-10-13)