[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 (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.


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.

Elder of the Internet

reply via email to

[Prev in Thread] Current Thread [Next in Thread]