The following is an extract of a document titled Common Lisp: Myths and Legends. It promotes Common Lisp commercial products of Xanalys, but the arguments apply to any CL implementation.
The reality is that when all datatypes are appropriately declared, a typical commercial Lisp compiler produces native machine code that is comparable in speed with other languages. However, something Lisp does which other languages don't is to allow you to run code with no type declarations. In this mode, types are dynamically determined and appropriate behavior occurs based on runtime dispatch. This is slower than heavily declared compiled code would be, but it's faster to write and therefore a big boon to debugging. After all, who wants to write type declarations for a bunch of tentative code they aren't sure they're even going to use? It's not appropriate to compare the speed of such non-type-declared code to the speed of other languages since in other languages, the absence of declarations is fatal to programs in most other languages. If you want to make a proper comparison, you have to either compare properly declared code in Lisp to properly declared code in other languages. If you do that, Lisp will compare favorably. Otherwise, to be fair, you should compare the speed of undeclared code in Lisp (modest) to the speed of undeclared code in other languages (often zero, since such code in other languages is usually ``incomplete'' and will not run). Once such a proper comparison is made, we again see the Lisp's behavior is quite favorable.
Big is a moving target. Sometime in the early 1980's, people started complaining about the size of Lisp as an impediment. Lisp was big at that time, compared to other applications of the time because it packed a lot of useful functionality and there was a limit to how small that functionality could be made. But Lisp vendors became very sensitive to the size issue and Lisp has been one of the few programming languages in recent years that has not been allowed to grow by leaps and bounds with every release. At this point, the size of a typical application in Lisp and its runtime libraries are comparable in size to what a similar application would be written in another language. But if the ``bloating'' trend of other languages increases as it has been, Lisp will soon be seen as the much more compact alternative!
Lisp has had an array datatype for at least 30 years, but it's common for people who took a ``comparative programming languages'' course not to know this. This is because other languages often have not had Lisp's well-known LIST datatype, and so Lisp is used as a showcase for dealing with linked lists and recursion. Sometimes out of ignorance and sometimes just for sheer lack of time, the discussion of array types in Lisp often receives no attention. But that doesn't mean Lisp doesn't offer powerful support for single and multi-dimensional arrays, arrays of varying element type, and array access that provides transparent access to fixed size arrays, arrays displaced to other arrays, and arrays whose size is expected to dynamically grow and shrink.
Since its earliest days, now 40 years ago, Lisp implementations have been variously interpreted or compiled, and often both. In fact, much important work in the theory of program compilation has been done using Lisp, and Lisp compilers have benefited enormously by this. No modern commercial Lisp is without a compiler. The fact that modern Lisps often come with an interpreter as well is simply a convenience for some implementations to encourage late-binding semantics and promote program flexibility, including interactive debugging. The ANSI Common Lisp standard does not require the presence of a compiler provided that an interpreter achieves the defined semantics. It is intended that the marketplace will sort out this issue. The ability to omit a compiler allows certain price/performance points to be achieved, especially among subset and freeware implementations. However, serious commercial implementations invariably offer optimizing compilers as a standard part of their product. Ask to be sure, but don't let ever anyone tell you there's no such thing!
This one is simple to correct. X3.226/1994, the American National Standard for Programming Language Common Lisp, not only exists but in fact was the first ANSI standard for an object-oriented programming language. A webbed adaptation of the ANSI Common Lisp standard, The Common Lisp HyperSpecTM (CLHS) is available from Xanalys free of charge from our downloads page. CLHS is contains a comprehensive glossary and myriad programming examples. It is heavily cross-indexed (105K hyperlinks) and is optimized to use low graphics for very fast browsing. Common Lisp is not only a standard but it places a heavy emphasis on program portability. This allows you to smoothly deploy the same program on quite different platforms. With additional help from CLIM, the Common Lisp Interface Manager, an application can be developed which uses the same code to take on a native Motif look-and-feel under X Windows or a Windows look-and-feel under Windows or NT. The design of the Common Lisp language planned for a wide variety of potential platform variances (character set, machine word size, filename syntax, interaction style) and will serve its users well into the future without the need to make costly program upgrades required by other languages.
While the ANSI standard for Common Lisp doesn't require it, a serious vendor of Common Lisp such as Xanalys goes well beyond what the standard requires in the way of potential connections between Lisp and the rest of your computer system. And in future releases, we'll be adding more because we know this is a key issue in the modern, heterogeneous computing environment. Foreign Interface. Data and program interfaces to C can be declared and called in a way that is transparent to Lisp programs. Network interfaces. Lisp supports easy access to TCP so that programming TCP-based interfaces is easy. Also, third-party software such as CL-HTTP (mentioned earlier), allows Common Lisp to talk to the web. And, of course, access to other network facilities for which there is no pre-packaged access in Lisp is still readily accessible using the Foreign Interface. CORBA Interface. A binding of CORBA to Lisp allows natural Lisp programming style to be used when interacting with CORBA interfaces. Database Interfaces. Flexible accesses to external database through SQL and ODBC interfaces make database entities conveniently available as Lisp data. DDE Client. A DDE client interface is available for programs requiring Inter-application communication under Windows. The reality is far from what the myth suggests because, in fact, Common Lisp from Xanalys provides a flexible and growing set of interconnection options.
If you haven't seen it before, the Lisp notation for what other languages might write as ``5*a+3'' is ``(+ (* 5 a) 3)''. And we'll admit this is to some degree a matter of personal taste. However, in spite of the fact that it may look initially a little funny to the unaccustomed, there are some sound technical reasons why Lisp syntax exists and is preferred by most Lisp programmers, and we've tried to enumerate them here: It's easy to teach. There are no complicated precedence rules waiting to trip you up. Grouping of operators and associativity is manifestly obvious. It's easy to parse. A few simple rules apply throughout. If you extend the language to add a new operator, you don't have to train the Lisp parser (provided to Lisp programmers as the function called READ) to understand your new operator. You can focus immediately on the semantics, which is what's important anyway. It maps naturally to an underlying data structure. When teaching someone about macros, it's obvious what the internal representation of a Lisp expression is because it looks just like Lisp program data. This greatly simplifies the writing of macros and ``automatic programming'' facilities. It means that when you extend the language, you don't have to worry about system operators looking different than the ones you define. This breaks down the system/user distinction and keeps the system operators from looking more important than the ones you write yourself. Text editors can provide better support. A text editor, such as Gnu Emacs or the built-in editor that comes with products like Common LispWorks, can automatically provide useful support for indentation based solely on parenthesis level without having to understand the specifics of your program. They can also provide commands for moving forward and backward conveniently over expressions, which in turn allows more flexible use of ``keyboard macros'' to perform automated program manipulation that is much harder to do in infix languages because the beginning and end of an infix expression must always be designated explicitly (usually by mouse motion to establish a ``region''). Of course, if you just can't get used to Lisp's syntax in spite of the many benefits it offers, consider the Dylan programming language. This has many features similar to Lisp, but with the infix programming syntax that some users prefer. An implementation originally developed at Harlequin is now being taken further by Functional Objects, Inc.
As with compilation, Lisp has been the place that much research in advanced garbage collection has been done. ANSI Common Lisp requires automatic memory management in some form, but Common Lisp implementations from Xanalys go beyond merely offering the minimal answer: Generational GC. First, Xanalys offers a modern ``generational'' garbage collector. Such collectors are based on a layering theory of data that says that when one wants to get back some storage, one should look ``nearby'' for recently discarded objects. If not enough are found, additional work is done to find slightly older objects. And so on. The idea is that the nearby search is quickest and if that succeeds, very little work will have been done. Objects that survive for a long time in the innermost circle are eventually ``aged'' and become part of a second generation. In practice, this kind of garbage collector can be highly efficient, especially in an environment in which virtual memory is used, because they generally don't have to touch all of memory in order to reclaim enough storage to succeed. Realtime GC. Customers whose applications can't even tolerate the speed of a generational GC should talk to Xanalys about its realtime implementation of Lisp. So far, this has not been packaged as a shrink-wrapped product but we might be able to provide it to you under some sort of consulting arrangement. Even if you're not sure you want to get involved in a consulting arrangement, please do contact us about your needs so we can be aware of your interest and help you determine how best to proceed.
No. Lisp's performance can certainly be optimized by special hardware. It's hard to imagine a language that couldn't. Various machines from Digital Equipment Corporation in the 1970's, notably the PDP10 and TOPS20 processors, contained numerous instructions which helped Lisp work efficiently. Later, in the 1980's and into the very early 1990's, there were several companies that built custom ``Lisp chips'' which ran Lisp very efficiently. But any language can benefit from a hardware assist; that doesn't automatically mean it requires special hardware to run that language. In the 1970's, the C language grew up on the PDP11, and yet now it is used widely. Lisp grew up on a wide variety of machines, most of them general purpose. Xanalys Lisp products were originally developed on stock hardware. They have never been ported to Lisp-only platforms. Today they run on Unix workstations and on the PC under Linux and MS Windows.
This is wrong on several levels. First, some people believe the expense comes from the need for special purpose hardware. As mentioned already, that's not necessary. Xanalys LispWorks will run comfortably on a low to mid-range home PC - that's about as general purpose as you can get. Second, Lisp available at a variety of prices. For example, a person who's just getting his or her feet wet with Lisp might want to obtain the Xanalys LispWorks Personal Edition, which is available for free. Hopefully that's not too expensive! Of course, it comes with some limitations that are not present in the Professional Edition and Enterprise Edition. And even these other editions are quite reasonably priced; see the products or contact a Xanalys sales representative for details. Or, if you're not ready to actually order a copy of Lisp, feel free to browse the Common Lisp HyperSpecTM to get a feel for the language.