Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom

[C Y]

--- Camm Maguire <address@hidden> wrote:
>
> Wonderful initiative!
> 
> These are just my simple thoughts on these broader questions:
> 
> 1) I worry a lot that concern over graphics, as valuable as it is,
>    detracts seriously from developer attention to the core math
>    abilities of these systems.

Only if it is true that effort by people working on graphics could be
used to do mathematical work.  The skills are somewhat different. 
Currently this may be true, since we have relatively small development
teams on both Maxima and Axiom, but to be fair on both projects the
core functionality (and code cleanup) is much higher priority.  Maxima
as a project hasn't devoted much energy to this since the gnuplot/plot
improvements - wxMaxima is an improvement over Xmaxima, but is being
worked on as a separate project. 

I can safely discuss this because I'm not sufficiently skilled (at
least at this point) to be tinkering with the core mathematical code. 
My most ambitious project to date has been teaching Maxima about units,
which has its wrinkles but can't be considered serious core
functionality.  So I'm not much of a loss on core math issues :-).

> 2) In keeping with the above, there seems to be a well-intentioned
>    desire to try to attract mass market users with dazzling eye 
>    candy.

Well, I like pretty pictures too ;-) but yes I guess that's the case.

>    My only quibble is one of priority -- what are these attracted
>    users going to contribute back to the community?  

If you mean by directly working on the code, no.  But they will help
build the momentum of the project, and its relevance to people other
than its current developers.

> If we did attract them now, are we ready to respond to a deluge of 
> feature requests and complaints?

Clearly we aren't, in the sense that everything else we want to take
care of is done.

>  If not, will these users turn against the project
>    when their desires are not immediately gratified and the latest
>    alternative toy becomes available?

Possibly.  But what alternative toys are you thinking of?  I doubt
Axiom and Maxima have any serious free competition at the moment -
there is too much work involved building up systems to their current
levels of ability.  I hope Maxima and Axiom can someday both make use
of the same lisp UI code - this will help both projects and enable end
users to use both systems more easily, since they will be using the
same basic GUI and only need to adjust to quirks associated with each
system's unique features and syntax.  I always viewed Maxima as the
"free Mathematica but better" project, and Axiom as something new
focused on theoretical purity and correctness above all else.  I think
these tools are complimentary more than they are competitive, and it
never hurts to have another system to check results in :-).

> 3)I also worry that we are not mass marketing specialists, and that
>   we cannot design a system based on what we imagine 'those users
>   out there' want.  What we can do is develop the system so that it
>   presents real value to the work *we actually do*, fix the bugs that
>   bother us, add what we think is imperative for us to be able to
>   rely on the system ourselves, etc.  If we do this, others like us
>   are bound to see the value too, and some of them will join us.  If
>   and when we get a large enough team intimately familiar with the
>   system, we can then try to reach out little by little to the mass
>   market, who are most likely to be 'takers' rather than 'givers' by
>   simple necessity of the overwhelming complexity of these systems. 

I don't mind the "takers" so much, since if nothing else they are
involuntary bug testers.  And every "taker" who uses the program
spreads the word.  But I agree a robust system is a better platform to
work from.  Probably what will happen (and is probably already
happening) is that potential takers are downloading and trying out the
system all the time (I think the download figures suggest this,
actually - I remember Tim Daly wondering who all those downloaders
were.)  There are lots of non-serious but curious folk out there, and
even they are good for spreading the word.  We dont' need to advertise
until we feel the system is "ready" but people are of course free to
check it out, so matters will evolve naturally.  

> 4) To the extent that we adopt this perspective, the only critical
>    need for graphics in these systems is the ability to plot and
>    print mathematical functions, IMHO.  At this early stage in its 
>    open source life, I would recommend axiom adopt the simplest and 
>    most portable system with a sizable user base, preferably 
>    maintained and developed externally, and to then move on to the
>    algorithms.

I'll agree here, with the hope that expedience can be substituted for
"the right way" at some point in the future when the math is robust
enough.

>    Maxima has adopted gnuplot, which I think is a wonderful and
>    powerful choice.  We have a working alternative system now and
>    there is no need to throw this away, but if we ever feel the need
>    to do something new in this area (for example, because our
>    existing graphics does not yet work on Windows), this is the 
>    direction I would recommend for now.

Probably a decent idea.  I'm not sure how "wonderful" I'd say gnuplot
is (ask Jim what he thinks about it sometime :-), but it does get the
job done reasonably well and it's clearly the best current free
solution.
 
> 5) In the longer term, lisp graphics is certainly very interesting,
>    and some beautiful work from a programming point of view has been
>    done, notably the McCLIM to which you refer.  The only problem
>    here which is nonetheless quite serious is the lack of unity or
>    consensus.  No one can afford to invest the time in putting
>    something together if they run the extremely high risk that it
>    will be abandoned later due to the extraordinary degree of
>    fractiousness in this area.  People need to see the payback 
>    measured in terms of user contributions in the future -- in this 
>    way they lever their own efforts.  Ask the question, "If I do 
>    this, what new user contributions will I likely trigger?"

Unknown, and unknowable currently, for whichever system you might
consider.  :-/.  This has been the primary reason I've not discussed
this more on the Maxima list - I've been waiting to see where the
various toolkits go and what the possibilities are.  We don't need to
make a final choice for quite a while since, as you noted earlier,
there are much more urgent matters to attend to.

> 6) Here is a list of lisp graphics options of which I am aware, all
> of which are workable with possible modest effort within GCL, but
> none of which appear to have any serious use by any existing
> applications.  (Please correct me if I am mistaken:)
> 
>         a) xgcl --
> http://www.cs.utexas.edu/users/novak/cgi/xgcldemo.cgi

Don't know much about this one - my initial reaction is it is too low
level to be attractive for this type of work, assuming it is an
interface to xlib.

>         b) gcl-tk -- (tk::connect)(load "...gcl-tk/demos/widget.lsp")

Has the advantage of being more active, but my tk bias kicks in here so
I'm disqualified. 

>         c) ltk  -- another tk binding

I think Tim said this looked like the best bet to get things working
quickly?  tk bias again rules me out here.

>         d) gtk-based -- cl-gtk, lgtk, http://www.cliki.net/Gtk

This is promising, but I don't know enough about how "good" these
bindings are to comment.

>         e) garnet -- http://garnetlisp.sourceforge.net/

Ah yes, garnet.  I set up the sourceforge site before I was really
aware of McCLIM, and I still like it as a toolkit, but between it's not
using CLOS and needing a serious modernization of its look and feel... 
Someday it may rise again, but for now I don't think this is the best
choice since it has no active development team to speak of.  This one
will bug me indefinitely because I think it SHOULD be modernized - it
deserves it.  But I can't recommend it at this point.

>         f) clx, clue, clio, clim, mcclim

McCLIM to my mind is the best choice right now, for the following
reasons:

1)  Active development team (we wouldn't have to maintain toolkit and
CAS.)
2)  CLIM is as close to a GUI "standard" as the lisp world gets.
3)  With different backends we might be able to get native look and
feel on a wide variety of platforms - for instance, gtk and QT backends
might let us fit nicely on both Gnome and KDE desktops with one set of
code.

With the exception of Garnet, which was used in some special purpose
apps long ago, McCLIM is the only of these toolkits where I do know of
a program written using it - Gsharp.  There was also the Closure web
browser, although I don't know if that has been maintained.  

>         g) cells/cello -- comp.lang.lisp

Can't comment much on this one - haven't figured it out.

>         h) Java based japi -- lsp/gcl_japi.lsp

I would prefer not to rely on Java, but that's just a personal
preference.

> 7) In deciding among these longer term options, please let me
>    emphasize that any are likely workable, but it is very important
>    IMHO that we pick at most one if we are to avoid wasting our
>    lives.  I also think it important that we
> 
>    a) choose a purely open source option

On most of the lisp alternatives we should be in the clear as far as
that goes.

>    b) cross-platform

There is no simple solution here, particularly from a lisp based
standpoint - my favorite idea is to wait for QT4, which will have GPL
versions both on Windows and Linux, and create an McCLIM backend for
that.

>    c) wide user base -- this effectively means a huge C user
>       base with a smaller user base of tight lisp bindings

Um.  You mean lisp bindings to a popular toolkit?

>    d) robust

This will probably come only with time and extensive testing.
 
>    e) actively developed elsewhere

This puts McCLIM at the front of the class in the Lisp GUI department,
as far as I know.
 
>    f) comes with a graphical interface builder -- as attractive
>       as graphical programming in lisp might be, even though it is
>       lisp, it is still much less efficient IMHO than using a tool
>       like glade.  I've used this myself in C, and I haven't had to
>       write a single gtk call.

Garnet I know had an interface builder, but I was never able to get it
to work reliably.  Not sure if McCLIM has one, but it is a VERY good
idea.  

>         g) LGPL is preferable to GPL if we're doing a general
>         interface, but I have no problems with GPL myself.

Maxima is LGPL, and Garnet is public domain - not sure about the
others.

>    All of this would appear to argue in favor of cl-gtk or the like.
>    Tim Daly Jr. has worked on it, and he indicates it would probably
>    take a week's work to get running under GCL.  We need to know how
>    good the Windows and MacOSX ports are.  *If we all agree* that
>    this is the way forward, I'll be happy to donate a few cycles to 
>    moving it along.

Well, I don't really get to say anything substantial unless I actually
show code, so don't worry about me.


> I think this is wonderful!  If you have the time to take this ball
> and lead with it, I'll be happy to support.  As stated above, I 
> think gtk is a slightly better choice than QT, but *whatever draws 
> consensus* is the best!

That's one of the reasons I favor McCLIM - it makes the GTK vs. QT
choice not an either/or proposition.

I'm not sure whether I can become skilled enough to do a good set of
bindings, but it would certainly be a challenge.

> This is well founded, I think.  tk is quick and portable, not
> necessarily 'robust and polished'.  The importance of the latter for
> these considerations is questionable.  Can you describe the maxima
> experience?  

Essentially the problems stem from us having to fix problems in the
Xmaxima code.  The "included" openmath plots was an odd affair that
never behaved reasonably when scrolled, and getting things working on
Windows was always a challenge for any given release.  I never was able
to figure out the TCL/TK code myself - I know Jim (our project leader)
really didn't want to mess with it.  We did finally get someone who was
knowledgeable to clean it up, but given Maxima is a lisp project we
were of the general opinion it was annoying to have to maintain a UI in
another language.  I'm only one (biased) source though, so I recommend
checking the list archvies for Xmaxima issues.  My memory may be making
it sound worse than it was. 
 
My GTK on Windows misgivings stem mainly from my own experiences with
it - GTK doesn't really "feel" like a native Windows interface.  QT I
know Trolltech supports on Windows as one of their most significant
platforms, and I'm guessing they will do their best to ensure QT apps
look and behave like normal Windows programs.  GTK is workable too, and
I wouldn't be at all opposed to seeing McCLIM+GTK, but my personal
preference would be QT to try and avoid the "this doesn't act like a
regular Windows program" phenomena.  This might have been fixed over
time though, so my reaction could be quite dated.  I haven't used
Windows in a significant way in quite a while, so I have no recent
experience.

CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com