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

[Camm Maguire]

Greetings!  And thank you so much for your valuable input!

C Y <address@hidden> writes:

> --- Camm Maguire <address@hidden> wrote:
> >
> >  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 :-).
> 

Agreed on the complementarity, and the desirability of a common gui.
Isn't this exactly what texmacs was designed to be?  What advantages
over texmacs might accrue from implementing similiar natively in lisp? 

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

Agreed that no precise prediction can be made, but surely the likely
contributers are a subset of dedicated lisp users, which, alas, are in
short supply at present.  This is not to argue against the possibility
for possible future renewed interest in lisp, but it does, in my mind,
argue for a tight lisp binding to a widely used C library at the base,
with mcclim as a higher level lisp option on top.  Then we can lever
both sets of users.

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

This is encouraging!  But I think we will agree that these few apps
pale in numerical comparison to those directly exercising both the
gtk+ and qt libraries.

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

Mike has also mentioned the wxwidgets backend, which would appear
attractive. 

> 
> >    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?
> 

Yes, at least as a low level layer which is just 'guaranteed to work
virtually forever'.

> >    d) robust
> 
> This will probably come only with time and extensive testing.
>  

Indeed.  By whom?  We will never match the testing that goes into
gnome or kde.   So perhaps one option should be as close to these as
possible, (with perhaps wxwidgets in between for windows), and then
build mcclim for the power users on top of this.

> >    e) actively developed elsewhere
> 
> This puts McCLIM at the front of the class in the Lisp GUI department,
> as far as I know.
>  

Agreed, but it is again a question of the unfortunate dearth of lisp
users as a body.

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

What I meant to point out here is that all apps using qt4 on Windows
will be gpl instead of lgpl, which is not an issue for me, but might
be for others.

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

This is well taken, but we should keep in mind that even any lisp
solution will involve learning a completely new set of functions,
which few people currently know.  If there were a large body of
existing knowledge distributed among the contributors, this would be
quite important, IMHO.

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

Here is the tradeoff between 'native look' and gpl'ed windows apps,
which can in turn be resolved with wxwidgets at the expense of the
massive user base.  Getting consensus on the priorities is the hardest
part, but if you are doing the work, your priorities are the ones that
count :-).

Take care,

> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah