Chapter 1 Introduction
Stanford University Professor John McCarthy
discovered the basic principles of Lisp in 1958, when he was processing complex
mathematical lists. Common Lisp (CL) is a high-level computer language, whose
syntax follows a simple list-like structure. The term "Lisp" itself
originally stood for "LISt Processing." When developing, testing, and
running a CL program, at the core is a modern-day version of the original List
Processor which processes (compiling, evaluating, etc.) the elements of your
program. These elements, at the source code level, are represented as lists. A list, in this context,
is just a sequence of items, much like a familiar shopping list or checklist.
Originally the List was pretty much the only data structure supported by Lisp,
but modern-day Common Lisp supports a wide range of flexible and efficient data
structures.
In a sense, Lisp acts similarly to the
concept of a Java Virtual Machine, but in a much more integral and natural
fashion. The internal Lisp processor behaves like a complete operating system, with
multiple threads of execution and the ability to load new code and redefine
objects (functions, etc.) dynamically, i.e. without stopping
and restarting the "machine."
This "operating system" characteristic
also makes CL significantly more flexible than other popular programming
languages. Whereas other OS languages, such as shell scripts or Perl CGI
scripts, need to pipe data around, in CL all data manipulations can run
interactively within one single process with a shared memory space.
The most popular
form of Lisp used today, "ANSI Common Lisp," was principally written and designed
by Guy Steele in Common Lisp, the Language, 2nd Edition ("CLtL2") - (see
the Bibliography in Appendix A). This version of Lisp became the accepted
industry standard. In 1995, the American National Standards Institute
recognized a slightly updated version as ANSI Common Lisp, the first object-oriented
language to receive certification, and ANSI CL remains the only language that
meets all of the criteria set forth by the Object Management Group (OMG) for a
complete object-oriented language.
Paul Graham outlines ANSI CL in his 1996
book ANSI Common Lisp, also listed in Appendix
A.
Official language standardization is important, because it protects developers from becoming saddled with legacy applications as new versions of a language are implemented. For example, this lack of standardization has been a continuing problem for Perl developers. Since each implementation of Perl defines the behavior of the language, it is not uncommon to have applications that require outdated versions of Perl, making it nearly impossible to use in a mission-critical commercial environment.
Many developers
once hoped that the software development process of the future would be more automated
through Computer-aided Software Engineering (CASE) tools. Such tools claim to
enable programmers and non-programmers to diagram their applications visually
and automatically generate code. While useful to a certain extent, traditional
CASE tools cannot cover domain-specific details and support all possible kinds
of customizations - so developers inevitably need to handcode the rest of their
applications, breaking the link between the CASE model and the code. CASE systems
fall short of being a true "problem-solving tool."
The recursive
nature of CL, and its natural ability to build applications in layers and build
upon itself - in essence, code which writes code which writes code..., makes CL a
much better software engineering solution. CL programs can generate other CL
programs, allowing the developer to define all parts of the
application in one unified high-level language. Using macros and functions,
naturally supported by the CL syntax, the system can convert applications
written in the high-level language automatically into "final" code. Thus,
CL is both a programming language and a powerful CASE tool, and there is no
need to break the connection. Several other features of CL also save significant
development time and manpower:
Automatic Memory Management/Garbage
Collection: inherent in CL's basic architecture.
The most common
criticism of Lisp usually made by programmers unfamiliar with the language is that
Lisp applications are too big and too slow. While this may have been true 20
years ago, it is absolutely not the case today. Today's inexpensive commodity computers have more
memory than some of the most powerful machines available just five years ago,
and easily meet the computing needs of CL. Hardware is no longer the critical
factor, programmers are!
Further, CL programming teams tend to be small,
because the inherent features in CL empower developers to do more. Without
excessive effort, a single CL developer can create and deploy a sophisticated,
powerful program in a much shorter period of time than if another language were
used.
Programming in CL is distinguished from programming in other languages due to its unique syntax and development mode. CL allows developers to make changes and test them immediately, in an incremental manner. In other languages, a developer must follow the "compile-link-run-test" cycle. These extra steps add minutes or hours to each cycle of development, and break the programmer's thought process. Multiply these figures by days, weeks, and months - and the potential savings are phenomenal.