the RULES OF DESIGN :

1 - MODULAR

2 - MULTI TRACKING

MULTI STORING

MULTI TASKING


3 - SUPER CRYPTO -
ALONG THE LINES OF : TWIN PHOTON EXPERIMENT


4- TOOL INTEGRATION INDIVIDUAL OF ANY OTHER MODULE

YET RESULTS OF TOOLS REDUCED TO A COMMON EXPRESSION


5 - TOLERANT OF SYSTEM

6 - MESHED : NETWORKED AND DEVICE SCATTERED MIRRORED

WOULD SAY HOLOGRAPHIC

But then again, you also spell it LISP in all caps, think that it's for doing some AI, and that it consists of processing nested lists.

There are some difficulties in using Lisp (specifically, Common Lisp) for applications that require a broad access to the specific features of multiple platforms. Those problems have nothing to do with lists or parentheses, but are rooted in library support.

Large, cross-platform Lisp projects are not unlike, in some ways, let's see, large cross-platform C++ projects. You have the equivalent of #ifdef, ad-hoc build systems and whatnot.

Lisp is a lot closer to C++ than to things like Java or Python that try to stuff the platform into the language. Like C++, it has a large ANSI standard, and built in libraries that are broadly applicable for any kind of computing: object system, streams, data structures. Just like C++, Common Lisp has no support for networking, graphics, multithreading at the like; these are left as extensions. Like C++, Common Lisp implementations have lots of local extensions, and escape hatches for platform access. Like C++, Common Lisp is a multi-disciplinary language that has support for many programming paradigms: procedural, OO, functional. In addition, it has support for arbitrary compile-time extension to the language. A good chunk of the source code of a typical Lisp application contains something that is not found in C++ programs: a set of compilers for language features used to express the remainder of the program.

If you can solve the platform challenges, Common Lisp is an amazing language that blows away pretty much everything else.

Oh yes, and what is a C++ program if not a list of lists of lists of lists ...

A C++ translation unit is a list, a list of declarations. Those declarations contain more lists: specifier lists, parameter lists, declarator lists. A statement block is a list of things, some of which can be statement blocks, etc.

Lisp programs are the same way, except that one lexical syntax is used for all the different kinds of lists. And Lisp programs can manipulate their own source code, so there is all that support for working with these nested lists as a data structure. The area where you encounter that type of programming the most is macro writing, because macros deal with the source code at compile time. If C++ programs could manipulate their own source code, you'd be dealing with lists of lists also. At some point you'd have a handle on a list of declarations, and have to iterate over the declarators within a declaration, find out that the declaration is a function, and then go into the list of parameter declarations and so on.

Lisp has other data structures beside lists. Vectors, strings, characters, symbols, numbers (integers, rationals, floating, complex and bignums), and a very powerful object-oriented programming system. It's a lot, lot more than list processing. Yet, the interesting thing is that the list processing is still so convenient and pervasive.

For instance, the ancient MAPCAR function now implements the Visitor Pattern:

(mapcar #'generic-function list-of-objects)

Each object on the list is ``visited'' and the appropriate method specialization of the generic function is dispatched on each object. The return values are collected in a list: this is still MAPCAR. :)

Actually in the true Visitor Pattern you dispatch on two objects. One comes from the list/tree/whatever structure that is being traversed and the other provides some additional context to customize the algorithm. Here, we are already customizing the algorithm by indirecting on the generic function, something that is not found in the Visitor Pattern (and only appears as a pointer-to-member-function hack in C++).

So we actually get a double-dispatch plus function indirection kind of Super Visitor Pattern:

(let ((function #'some-generic-function)
(object (make-some-object)))
(mapcar (lambda (obj-from-list)
(funcall function obj-from-list object))
list-of-objects))

Now MAPCAR calls my anonymous lambda function, which invokes a two-argument generic function, giving it the object from the list, and the fixed object that I constructed in the LET block. The Lisp object system (CLOS) performs a double dispatch, choosing the method specialization on the types of both arguments! And in addition, we are indirecting on the function itself. In the Visitor Pattern, the second object is used to choose the algorithm: e.g. for a syntax tree you have an evaluating visitor, a pretty-printing visitor, a type-checking visitor, a code-generating visitor, etc. Here, we can do that just by swapping out the function, without needing dispatch on an additional argument. We don't have a fixed function like visit() and accept().

So we end up doing some pretty advanced stuff that takes reams of C++ to set up incompletely. And yet, at the heart of it, there is still traditional list processing too, since the objects being visited are in a simple list.