Re: [Axiom-developer] Embedding Axiom

[Tim Daly]

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