[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Lisp is a general-purpose language that is higher-level than C and in many ways more powerful than C. Powerful dialects of Lisp such as Common Lisp are probably much better languages for writing very large applications than is C. (Unfortunately, for many non-technical reasons C and its successor C++ have become the dominant languages for application development. These languages are both inadequate for extremely large applications, which is evidenced by the fact that newer, larger programs are becoming ever harder to write and are requiring ever more programmers despite great increases in C development environments; and by the fact that, although hardware speeds and reliability have been growing at an exponential rate, most software is still generally considered to be slow and buggy.)
The new Java language holds promise as a better general-purpose development language than C. Java has many features in common with Lisp that are not shared by C (this is not a coincidence, since Java was designed by James Gosling, a former Lisp hacker). This will be discussed more later.
For those used to C, here is a summary of the basic differences between C and Lisp:
(func arg1 arg2 ...) |
This is as opposed to C, which writes functions as
func(arg1, arg2, ...) |
but writes expressions involving operators as (e.g.)
arg1 + arg2 |
and writes control statements as (e.g.)
while (expr) { statement1; statement2; ... } |
Lisp equivalents of the latter two would be
(+ arg1 arg2 ...) |
and
(while expr statement1 statement2 ...) |
void *
pointers or
variable-argument functions), but the type information must then be
passed explicitly in some other fashion, leading to additional program
complexity.
free()
. If
you simply drop all pointers to memory without freeing it, it becomes
“leaked” memory that still takes up space. Over a long period of
time, this can cause your program to grow and grow until it runs out of
memory.
longjmp()
, but that is often very dangerous
because the routines that were exited past had no opportunity to clean
up after themselves and may leave things in an inconsistent state,
causing a crash shortly afterwards.
Lisp provides mechanisms to make such non-local exits safe. When an error occurs, a routine simply signals that an error of a particular class has occurred, and a non-local exit takes place. Any routine can trap errors occurring in routines it calls by registering an error handler for some or all classes of errors. (If no handler is registered, a default handler, generally installed by the top-level event loop, is executed; this prints out the error and continues.) Routines can also specify cleanup code (called an unwind-protect) that will be called when control exits from a block of code, no matter how that exit occurs—i.e. even if a function deeply nested below it causes a non-local exit back to the top level.
Note that this facility has appeared in some recent vintages of C, in particular Visual C++ and other PC compilers written for the Microsoft Win32 API.
For those familiar with Lisp, Emacs Lisp is modelled after MacLisp, an early dialect of Lisp developed at MIT (no relation to the Macintosh computer). There is a Common Lisp compatibility package available for Emacs that provides many of the features of Common Lisp.
The Java language is derived in many ways from C, and shares a similar syntax, but has the following features in common with Lisp (and different from C):
The Java language also has some negative attributes:
bc
it is necessary to write a special purpose, albeit tiny,
application. In Emacs Lisp, a calculator comes built-in without any
effort - one can always just type an expression in the *scratch*
buffer.
chdir
is not part of standard
Java, which is inexcusable.
Unfortunately, there is no perfect language. Static typing allows a compiler to catch programmer errors and produce more efficient code, but makes programming more tedious and less fun. For the foreseeable future, an Ideal Editing and Programming Environment (and that is what XEmacs aspires to) will be programmable in multiple languages: high level ones like Lisp for user customization and prototyping, and lower level ones for infrastructure and industrial strength applications. If I had my way, XEmacs would be friendly towards the Python, Scheme, C++, ML, etc... communities. But there are serious technical difficulties to achieving that goal.
The word application in the previous paragraph was used intentionally. XEmacs implements an API for programs written in Lisp that makes it a full-fledged application platform, very much like an OS inside the real OS.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.