Xah Lee wrote:
> The Mathematica language is very similar to lisp. From a Mathematica
> expert's point of view (me), the first thing that seems odd of lisp is
> the low-level-ness.
It's not so much about being low level, but rather about being able to
change the programming language from within a program itself. This
requires revealing implementation details of the language and providing
hooks to actually make effective changes.
If you believe that it's possible to come up with the 'right'
programming language(s) that don't require tweaking anymore, then this
probably appears as gratuitous to you. However, if you believe that an
essential part of solving a problem in a certain domain is to come up
with a domain-specific language, then this isn't so far off anymore.
Lisp was one of the first languages that enabled such tweaks in a more
systematic way. Yes, there were mistakes made in early Lisp dialects,
and some of those mistakes still live on in current dialects (including
Common Lisp and Scheme). But it is also clear that it is very hard to do
substantially better than Lisp. Some of the oddities in Lisp actually
seem to be necessary to be able to perform certain kinds of tweaks.
> Perhaps in order of the low level impression:
>
> 1. The cons business. (lists are made up of cons cells and it is
> necessary for the programer to understand this to write any non-
> trivial lisp program)
>
> 2. No highlevel treatment of lists. (In Mathematica, there are a
> system of functions to extract or manipulate (nested) lists considered
> as trees. e.g. getting all elements at a level, or arbitrary set of
> nodes of a tree. All these based on a tree index concept. (i.e. first
> branch's second branch's third's branch will be 1,2,3.) In lisp,
> programers uses cons, car, cdr, caadr, etc. That is bizarre and
> downright ****ing stupid.)
This is an example of providing low-level details so that you can change
the behavior at a higher level. If you provide a list abstraction that
doesn't let you access low-level details, then you're stuck with the
design choices and API that the original designers have decided, and
can't do much about them (except by starting from scratch).
> 3. The syntax is a bit quirky. In particular, a mathematica programer
> sees that sometimes list is written as “(list a b c)”, but
sometimes
> there's this oddity “'(a b c)” (which is syntactically
equivalent to
> “(quote a b c)”). And, when mapping a function, sometimes
the
> programer also needs to put the apostrophy in front. (A Mathematica
> programer would think, if a function (e.g. “map”) that
takes another
> function as argument, why would the function require the programer to
> put the apostrophy, why the function itself could be designed to not
> evaluate that argument.)
>
> 4. A behind-the-scenes model of computation. Namely, lisp the language
> deals with the concept of “lisp objects”, and there's a
“print syntax”
> that represent these objects. (and a “read syntax” that
reads a code
> into these objects)
Yes, it's an acknowledged issue in Lisp that has its drawbacks, but at
the same time gives you im****tant expressive power: By being able to
refer to runtime objects in source code directly you can actually write
programs about such objects (aka metaprogramming and reflection).
Brian Smith attempted to solve the problems with Lisp in 2-Lisp - see
his work on reflection and 3-Lisp, for which 2-Lisp was an intermediate
step. There are also two nice overview papers: "Reflection in logic,
functional and object-oriented programming: a Short Comparative Study"
by Demers and Malenfant, and "M-LISP: A Representation-Independent
Dialect of LISP with Reduction Semantics" by Muller.
I think 2-Lisp is pretty close to a good solution (but not substantially
better enough to warrant changing all existing Lisp and Scheme source
code to match the 2-Lisp model). M-LISP seems closer to what you would
actually prefer, I think (but I haven't checked in detail).
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Do***ent Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
|
