mac (04/21/83)
...more on LISP. Virtues: Tim Maroney (unc.5017) has said about all that I was going to say here. LISP has Semantic Sugar. Flaws: LISP has Syntactic Alum. Functions can return only a single value. Several results must be cons'd together, then picked apart. This is a nuisance. Often people just use side effects. I think I might like expressions to return definitions as well as values. Accessing data structures can be tedious. DEF-STRUCT macros may be a way around this. It's difficult to produce side effects on data structures. There are too many bizarre features in LISPs. It's time for a little housecleaning. Too much bizarre and inconsistent terminology & jargon. (greaterP vs. atom, assQ vs. setQ, Nconc vs. Nlambda). There is hardly any compile-time checking of anything. Many times that this has saved me in Pascal. (less so in PL/I). Even compiled code is slow. Many features of LISP just can't be compiled well. Compiled programs don't work the same way as interpreted programs. The dynamic binding of traditional LISP is a serious mistake. There is some argument for the availability of such a feature (exception handlers should be dynamically bound), but it's not what's usually wanted. The applicative nature of LISP doesn't go far enough. It's hard to define and use functionals (APL "operators"). Variables that are SETQ aren't distinguished from those that are lambda bound. I think SETQ types should be explicitly created and dereferenced. I might add that some of these objections are answered by SCHEME and other new dialects. I'd also like to point out that there *are* large programs written in LISP. Some of them are for extremely hard problems. In fact, I believe LISP has an advantage on really complex algorithms. The length of a program in LISP is an order of magnitude less than the equivalent in Pascal, etc. What I'd like to see is some language with all the virtues of LISP, none of the vices, all the speed of assembly code, none of the hassle.