[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Embedding Axiom
From: |
Tim Daly |
Subject: |
Re: [Axiom-developer] Embedding Axiom |
Date: |
Mon, 16 Nov 2009 11:59:51 -0500 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
Martin Baker wrote:
On Monday 16 November 2009 04:35:00 Tim Daly wrote:
This is a request for design discussion for those who are interested.
Tim,
Can I ask a nieve question? If you were starting from scratch would you write
Axiom in lisp? I've no special axe to grind and no special technical
knowledge, I'm just asking out of curiosity.
Axiom depends heavily on lisp's ability to write programs which write
programs. No other language
seems to have this ability. The macro facility in lisp gives Axiom the
ability to "get inside the compiler"
at compile time to perform needed optimizations. It can do this because
lisp macros are source-to-source
transformations on the syntax tree that occur at compile time. Axiom
uses closures and passes them
around as first-class objects so you can create stateful objects
in-context on the fly, pass them around
and call them in other contexts. Unlike other languages, lisp programs
are data which are programs.
If I were starting from scratch I don't know what other language could
be used.
Python/Java/Scala cannot dynamically create program text and use it
immediately.
They do not have a macro facility that is source-to-source.
They cannot create useful runtime closures.
I qualify my "cannot" remarks with Greenspun's Law which states that
"Any sufficiently complicated C or Fortran (Python/Java/Scala) program
contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of common lisp."
It just seems to me that for Axiom to hit the bigtime:
* potential programmers and advanced users would want a modern graphical IDE
and useful error messages.
* non-advanced users would want a html-like interface that changes with the
fashion of the time (the look seems to be important these days).
Axiom is re-targetting the user interface to use the browser (nod to
Bill Page).
The browser only recently supports needed elements like the <canvas>
object but Axiom
can already create dynamic browser pages that allow inline computations
(supported by Ajax calls).
The hyperdoc help system is already partially rewritten to be
browser-based.
The graphics subsystem is being redesigned to work on html canvas
objects in browsers.
All of this works from lisp.
As for "hitting the bigtime".... Axiom is not trying to achieve success
in the way you are thinking.
Your definition of success has an element of "lots of people use it".
Axiom's definition of success involves being the basis for computational
mathematics, which is a
small intersection between mathematicians and programmers. The total
number of people in this
set would likely fill a small parking lot, assuming you could get them
out of doors.
Success means that computational mathematicians are able to build upward
from the existing
system in a mathematically correct way. Success involves making the
system into something that
can be taught to the next generation so they can move further with
confidence. So what does it
take to provide reasonable guarantees that Axiom is mathematically
correct (insert philosophical
debate here)? What does it take to teach the next generation to think
like computational
mathematicians (insert literate programming debate here)?
I just wondered how practical it is to do all these things on top of lisp? As
opposed to say another functional language supported by something like the
Eclipse framework? When I first came across the spad language, a few weeks ago
now! I was really surprised how similar it is to the language Scala, without
knowing what the technical issues might be it would be interesting to know if
spad could be built on top of Scala?
Unfortunately nothing I can possibly say will be meaningful if you
aren't a lisper.
Lisp is an "epiphany experience"
Epiphany languages change the way you think. Other examples worth
learning are APL,
Forth, Snobol, Prolog, OPS5, etc.Python/Ruby/Scala/Java are weak
implementations of Algol 68.
Ultimately, there is a gap between the problem you are trying to solve
and the machine that
will execute the solution. I call this the "impedance gap" (impedance is
resistance because
of a mismatch... think of a soda straw connected to a fire hydrant).
This gap is very wide
if you are trying to solve a complex problem on a microprocessor. A
computer language
that is close to the machine (e.g. assembler) means you have to move
your concepts from
your head to the machine. A computer language that is close to the
problem (e.g. AutoCAD
for solid models) means you need only small programs to express your
problem but you
need a lot of special-purpose machinery to "cross the gap" to the
microprocessor.
Lisp is the only language I know that operates at all levels across the
impedance gap.
(e.g (integrate (car x) .... uses a heavy algorithm on a machine pointer)
You could build spad on top of Scala but it would be painful. You would
end up using
"factory objects" to create "eq pointers" to unique instances which is
dirt trivial in lisp.
You would have to build a Scala parser to a special internal data
representation, a
Scala macro language that could manipulate the internal data
representation, a Scala
interpreter so you could call Scala functions on the internal data
representation, a Scala
compiler so you could compile the internal data representation, and an
internal-to-Scala
printer program. In short, you would have to build "an ad-hoc,
informally-specified
bug-ridden slow implementation of half of common lisp." And when you are
done you
still have a language that sits on top of a virtual machine that does
not support tail-recursion.
The REAL question is why we don't all rewrite everything in Go :-)
Methinks I'm becoming something of a curmudgeon.
Tim
Elder of the Internet
- [Axiom-developer] Embedding Axiom, Tim Daly, 2009/11/15
- Re: [Axiom-developer] Embedding Axiom, Martin Baker, 2009/11/16
- Re: [Axiom-developer] Embedding Axiom, Stephen Wilson, 2009/11/16
- Re: [Axiom-developer] Embedding Axiom, Tim Daly, 2009/11/17
- Re: [Axiom-developer] Embedding Axiom, M. Edward (Ed) Borasky, 2009/11/17
- Re: [Axiom-developer] Embedding Axiom, Bertfried Fauser, 2009/11/17
- Re: [Axiom-developer] Embedding Axiom, Tim Daly, 2009/11/17
- Message not available
- [Axiom-developer] Embedding Axiom (Hickey and fold/unfold), Tim Daly, 2009/11/20
- Re: [Axiom-developer] Embedding Axiom (Hickey and fold/unfold), Martin Baker, 2009/11/21
- [Axiom-developer] Embedding Axiom (Hickey and fold/unfold) and rule based programming, Tim Daly, 2009/11/21
- [Axiom-developer] Embedding Axiom (Hickey and fold/unfold) and Reifying time, Tim Daly, 2009/11/21