[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] (Possible) reasons Axiom didn't appeal to SoC coders..

From: C Y
Subject: [Axiom-developer] (Possible) reasons Axiom didn't appeal to SoC coders...
Date: Tue, 10 Apr 2007 10:20:36 -0700 (PDT)

--- Bill Page <address@hidden> wrote:

> Unfortunately we did not receive any eligible applications from
> students regarding Axiom. :-( I think we should try to analyze
> why that happened. Although I do think that Lisp is an important
> programming language, I fear that Axiom's association with Lisp
> is of very little benefit to Axiom. It seems that very of the
> already very few student Lisp programmers are really interested
> in Axiom... Does anyone have any other ideas about why we did
> not receive any applications?

A few, none of which have any particular supporting evidence:

a)  There are very few students interested in CAS work
b)  Axiom is not a CAS that appeals to students (this has been
discussed in the past - there are good reasons for Axiom doing things
the way it does but the benefits take time to appear).
c)  Using GCL in non-ANSI mode is not a work environment that would
appeal to most lisp programmers today (no SLIME, many standard libs
won't work, etc...)
d)  There is still a lot of "cleanup" work to be done before more
interesting projects that will produce user visible results will begin
e)  The "learn the territory" work needed to do useful work on Axiom is
much more extensive as opposed to other projects (learning how Axiom
does things and how to change them without breakage is a process WE are
still going through, after all...) - a single summer is not a lot of
time to both get up to speed and code something interesting.

The work that is being done on the branches now will help to address
many of these problems (running on SBCL should be a big help...)

For example, I've wondered about the possibility of using the
hunchentoot code to define a "gateway" for
Axiom IO that would be used for everything - have the terminal connect
to it, a webpage interface connect to it, and a GUI connect to it. 
Essentially Axiom would become the mathematical "server" and all client
interaction systems would talk to it through the same basic mechanism,
with different communications protocols being chosen based on the
interface connecting.  Mathematica uses this kernel-client approach,
but they defined their own protocol to do it called MathLink.  I'm
wondering if Axiom couldn't achieve the same result with the server
code in hunchentoot, and more or less for free get a web interface at
the same time.  However, this requires a) sufficient knowledge of
Axiom's systems to know how to set up something like that and b) a
system on which hunchentoot and its requirements (and there are a
number of those) can be run - i.e. not GCL in its current form.  When I
look at trying to do this from the SoC point of view, I can see that
Axiom would be a very intimidating prospect.  Most other projects would
have similar hurdles.

I think in the future Axiom will fare better, as we are slowly cleaning
up the system and porting to SBCL et. al.  That should be one big step
forward, and improved code documentation also will be a big help.


Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 

reply via email to

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