axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: A modest proposal


From: C Y
Subject: Re: [Axiom-developer] Re: A modest proposal
Date: Sat, 30 Jun 2007 05:31:15 -0700 (PDT)

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

> Thanks for carrying my side of the conversation for me, Cliff. :-)

<turns red>.  Sorry, didn't mean to presume Bill - please forgive my
rudeness.  I just had a feeling I knew pretty well what that side of
the argument would be, and wanted to respond before I fell asleep ;-).

> I've had my mind on other things for the last few hours... Yes, you
> state very clearly and exactly my concerns.

OK, good.

> I have a very great respect for Lisp, but I wonder how you can look
> around the web and at the type and number of programs that have been
> written in the last 10 years and not think that Lisp is essentially
> already a ghetto (as you have so clearly and accurately defined it).

That's a fair question, and if you take the definition of "ghetto" as
laid out above I suppose it DOES satisfy that definition.  Which leaves
the question of why I don't think of Lisp as a ghetto even though it
might technically satisfy the definition.  

I would say my line of reasoning goes something like the following:

1.  Once I was able to understand the basics of how Lisp works, the
simplicity of it and the power it offers were worth the initial
learning effort.

2.  In the world of computer algebra specifically, Lisp is a staple and
has been for decades.  Far, far back in the depths of the Maxima
archives, before I knew what I was doing, I proposed rewriting Maxima
in a language with more popular support.  The archives no longer seem
to be online, but IIRC the response at some point was that learning
Lisp was a small effort compared to the effort required to properly
implement CAS abilities, and the benefits of using Lisp outweighed the
difficulties in this particular case.  I have since come to agree with
this.

3.  Lisp may not get the "popular interest" other languages do, but
much of the code written for it seems to be rather well written - it
solves problems well when it does solve them. 


> We might wish that that was not true but all the evidence is clearly
> there. Ask the people who teach computer science at university what
> they think of Lisp. Ask them what there students think of Lisp. Gaby
> for example has already said what the reaction of his colleagues was
> to the fact that he has been spending so much time on an "old Lisp"
> system like Axiom... When I mentioned Lisp to a room full of
> enthusiastic Sage developers you should have seen the "tolerant
> amusement" on the faces those under 25 in the crowd. Man, did that
> make me feel old... :-(

Lisp is still a working, functional language despite having its roots
in the Fortran days - that says something about the robustness of the
ideas behind it, IMHO.  In my opinion the question should be what does
the language bring to the table.  The only area I am aware of where
Lisp is seriously lacking compared to other languages is libraries
defining graphical tools.

Python has great library support for modern operating systems - I have
used it in the past because of this.  However, for the 30 year horizon
what is popular today is of somewhat less concern to me.  Who knows how
language trends will progress?  Something new may become the next
"star" language.  Lisp has been around for a very long time, and offers
a lot of power in exchange for being willing to think a little
differently.  To me that's worth the tradeoff.


> > >  And the goal is to develop tools such that given a working Lisp
> > > environment users and developers will be able to focus on the
> > > Algebra without worrying about the underlying tools.  If they
> > > MUST work with them, I would like them to be literate all the
> > > way down - no dark corners to get into trouble with.  But that's
> > > again just me.
> 
> That part I completely agree with but I fail to see why that requires
> doing the things that you and Stephen are proposing.

OK, ask these questions - is autoconf (not our configure file but GNU
autoconf) literate?  What about GCC?  If those programs are in the
critical dependency tree any problems that no one else takes care of we
have to deal with, because without them we would have no working
program.  noweb is at least literate but it also requires gcc.  GCL and
Clisp bootstrap off of GCC, true, but CMUCL and SBCL do not.  

Being able to maintain a working CAS means that everything required to
go from source code to finished binary is a potential issue for the
Axiom developers to deal with.  The easier it is to deal with any
potential issue at ANY point in the software stack, the better. 
Perhaps most of the time Axiom will be built and used with tools that
require external support, but (like Maxima) I would like Axiom to be
able AT NEED to get up and running with only tools that are fully
literate.  The less Axiom is at the mercy of ANY external requirements,
the more robust it will be for the 30 year horizon and beyond.  If
autoconf someday dies, if noweb becomes unmaintained someday, we would
still be able to build as long as an ANSI Lisp environment can be
bootstrapped.  That's robustness.

A consequence of this approach is that we rely less on mainstream
tools.  To me, the approach should be to have the option of using
mainstream tools if they do something better/faster, but be able to
fall back on Axiom itself if something goes haywire with the external
requirements.  Future proofing Axiom means that the work put into the
Algebra code will still be usable indefinitely, so long as the
supporting Lisp environment can run.  In some ways, it's the same
reason Java software is portable - it uses the virtual machine and
writes everything inside of it.  Java was designed from some people
familiar with Lisp - I have a feeling this idea came from there.  In
theory Lisp could provide many of the same benefits, if the work was
put into interfacing with the different graphics libraries properly.

"Mainstream" is a matter of definition, and the community defines it. 
We are part of the community, engaged in a major project with wide
ranging implications.  Rather than follow the trends, why don't we set
them?  Find the best tools for the task, use them, and make them
mainstream?

The Spad/Aldor languages are even more of a ghetto than Lisp, yet we
are putting effort into them because they provide enough benefits by
virture of their language constructs to be worth the effort.  I
personally like Lisp enough to consider it worth the extra effort
(which isn't really all that much, to be honest - I have a LOT of
basics to learn and that would be the same in any language) to make
ASDF capable of handling pamphlets and do some other work as well to
make it close to an ideal environment.  And I'm sure ASDF is a LOT
easier to make literate than autoconf, when the goal of "turtles all
the way down" with literate programming comes into play.

Anyway.  We'll see - it's an experiment.  All we can do is give it a
try.

Cheers,
CY




       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
 




reply via email to

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