--- Richard Fateman wrote:
> Not only could they be wrong, but there is a whole class of bugs in
> which nearly every CAS gets the same wrong answer. In fact, some of
> us take particular pride in finding them.
And thank goodness for you guys :-).
> > Really, it would be nice if this type of software could be
> developed
> > using proof systems, but before that makes sense we would probably
> > need something like Coyotos to mature, since without a provably
> > correct OS I don't see how you could prove your application
> > behavior. (To full rigor anyway.)
>
> You can read MKM (Mathematica Knowledge Management) conference
> proceedings if you want to see what the current state of the art
> is. Don't expect much.
Oh, I know. Rigorous software development is currently very rare, used
for things like railway routing software where the consequences of ANY
failure are dangerous to life and limb. I think some medical equipment
software is also written to such standards, and a few other special
applications. Even our power grid software isn't written that way, as
they traced the failure that caused that huge blackout in the northeast
to a software failure condition that had a window of milliseconds or
some such absurdly small amount of time. If you need to avoid things
like that, no testing is enough. But the programming tools, support
structure, and even theory (to say nothing of training!) are nowhere
near what is needed for this.
Fortunately, things work well enough most of the time. But I'm hoping
the day will come when the only way to add real value to most
non-special purpose software will be to make it provably uncrashible.
That will be an interesting time.
> > I understand the frustration. I do agree that it would be nice if
> > the time spent on these issues were to go into mathematical/feature
> > work.
>
> One question though, is whether the people doing the SBCL etc hacking
> are at all interested or able to improve the math stuff, or are
> they treating Maxima as just a big benchmark?
Hmm. Good question. I think one helpful point is that Maxima, being
one of the largest end user lisp applications around, is a logical test
target for the developers of the lisp compilers themselves, but I know
there is also overlap between some of those guys and Maxima developers.
Hopefully, as all the lisps develop towards full ANSI compatibility,
such issues will disappear. GCL was originally the major holdup there
IIRC, but with all the hard work they've been doing I hope to see such
issues reduced to the point where they are rare, easily fixed, and not
a real distraction.
> But I think the best way to ensure Maxima is here for the
> > long haul is to make it as portable as possible.
>
> Aren't we taking out the conditionalizations that
> make it run on PDP-10, Multics, Franz Lisp/VAX? I generally do
> that so I can read the relevant code. But I haven't fed stuff into
> CVS.
That is the plan, but I think it was decided to do that post 5.9.2.
(There are other cleanups as well - it's surprising what's hanging
around in there.) If PDP-10 or Multics were still viable platforms I'd
argue for leaving them in, but they are essentially dead and gone now.
There is no benefit going forward from being able to run on such
hardware. My argument I guess is if we run on all the major current
platforms (however you define major) we can reasonably expect to run on
whatever survives over the years or evolves from the current major
projects. Maxima grew from VAX and PDPs to Windows and Linux, and
Franz Lisp and other early variations to GCL/Clisp/SBCL/CMUCL/Allegro.
So if/when something grows out of these systems to become FooOS and
BarLisp, Maxima will be in a position to follow that development as it
happens and not have to scramble later on.
Of course, it is possible that we have reached a much more "mature"
point than VAX/Multics/etc, but somehow I think the software will keep
marching forward. (Or marching somewhere anyway.)
CY
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/