Xah Lee wrote:
> struct as in C's ?record? data type? Classes as in Java? Mathematica
> doesn't have these things. For Class, it depend on what you mean. As a
> language's data type, no. As a function that contains data ond inner
> functions one can implement in just about any well designed lang, yes.
I think one might validly claim that Mathematica does provide such
functionality though. Questions of the type system become trivial because
it has only a single type (expressions) and, therefore, there are no type
definitions to worry about. Inheritance is then nothing more than applying
one set of rewrite rules before another:
f //. {derived, base}
What Mathematica lacks is any way to ensure adherence to an interface.
Perhaps you can implement such a test at run-time using pattern matching
but I doubt it would be as elegant as the above. However, is this a
requirement of OOP? e.g. does Lisp enforce interfaces and, if so, when do
they get checked?
> As i repeated many times now, programing in Mathematica does not have
> any concept of memory, reference, pointer, WHATSOEVER. There is NO
> behind-the-scene memory, object, abstract storage location, where some
> other entities ?reference? to it.
That is a triumph of hope over reality, I'm afraid. Here are a couple of
counter examples that I have experienced:
.. You must learn about stack consumption and tail recursion because
Mathematica is extremely prone to segfaulting when the stack is exhausted.
Hiding this behind $RecursionLimit does not abstract away this problem but
merely provides a safe-looking facade compared to segmentation faults
(which happen if you raise $RecursionLimit)
.. You must learn about the memory management of cyclic data structures if
you want to avoid leaks in your code because Mathematica is not properly
garbage collected.
The language might not explicitly expose storage concepts but the
implementation requires users to understand it. This might be fixed in the
future if Wolfram Research make the core rewriter tail recursive and
migrate to accurate garbage collection but I don't think that will happen
any time soon.
> The thought has come to my mind to write a few pages of tutorial of
> mathematica for lisp programers. Written in a way such that every
> mathematica construct has a exact analogous counter part in lisp, in
> both syntax and semantics, so that the tutorial actually also
> functions as a fun-oriented lisp programing excursion. (in fact, if
> you are a lisp expert, you can consider yourself already half of a
> Mathematica expert. (lisp's major concepts of fully functional nested
> syntax, forms, macros, lambda, lists, function application are just
> about the same set of fundamental ideas in Mathematica, almost token
> for token identical except few syntax quirks or when we get into hairy
> stuff of evaluation model exhibited in lisp as ?quote?, ?eval? ... or
> in Mathematica as Hold[], HoldForm[], Evaluate[], ReleaseHold[]...)
There are some important discrepancies though. You've even neglected one:
Mathematica's lists are arrays where are Lisp's lists are real linked
lists. This has some important ramifications, e.g. cdr is O(1) in Lisp but
O(n) in Mathematica.
You've also got other problems like Lisp has better-defined asymptotic
complexities for its core operations whereas Mathematica has next to
nothing (what is the complexity of "<", for example?).
> Lisp can actually relatively easily do it, emulating the full
> Mathematica's systematic list/tree extraction/manipulation functions
> (getting rids of the cons problem for good), as well getting rid of
> the lisp ?behind the scenes? object concept with some practical
> benefits, a full automatic code formatter (beyond emacs current
> offerings) that get rid of the endless manual ?how you should indent
> parens? once for all (as in the benefit transparently offered by
> Python), and also layer on top of sexp a infix notation while
> maintaining absolutely the full sexp benefits, and even more, if lisp
> experts are interested in spending now quite a lot energy, go as far
> as making lisp a full 2D Mathematical notation display system, and a
> notebook system (think of it as a language feature so powerful that
> the SOURCE CODE actually transparenly functions like a Word Processor
> file format that can contain structures and images).
I would not call that "relatively easy". Just implementing Mathematica's
pattern matcher is a lot of work...
> This is a social and psychological problem of lisp mainly caused by
> the old timers. Besides fixing problems of the lisp the language
> proper, other problems and possible solutions such as frequent
> complain of its libraries are similarly thwarted and smiten.
I don't think that the social dysfunction of Lispers is caused by old
timers. Perhaps it is exacerbated by some university lecturers but,
ultimately, it is the result of users who haven't studied anything more
modern. I was the same when I was a kid: I'd liked writing rats nest code
and didn't care a hoot for "a fascist type system" that might encourage me
to write something more maintainable.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
|
