On Apr 25, 11:43 am, David Joyner <wdjoy...@gmail.com> wrote:
> Hi:
>
> I just started preparing for a talk next Friday in an
> NSF workshop on "Future Directions of Computaton
> Research" in the "Symbolic Software Design" section. Therefore,
> I think I should say something about the work on pynac
> and how it will be replacing maxima. I tried the wiki to
> see what was there on this but the wiki seems to
> be down.
....
I would be quite interested in seeing a defense of this idea, because,
to me, it seems like quite a bad notion.
Replacing Maxima (which is [being treated as..] free/open) with
another [free/open] package, yet to be written, but which starts with
a package which does substantially less (if I understand the
description of pynac as Ginac), makes sense only if your mind set is
"lisp is bad, python is good".
If your goal is to compete with Maple and Mathematica, you will also
have to program all of the facilities in those systems as well in
pynac.
Why should the NSF fund this? It could fund people to start with
Maxima and add facilities, instead of reproducing Maxima. It could
fund people to improve Maxima's efficiency, or even include Ginac into
Maxima. Or it could just fund anyone who needs Mathematica or Maple to
just buy a copy. Which is what most reasonable funding agencies would
do if one of their grant-holders requested it.
And as far as open source goes, you say
"With open source software,
ideally it is possible for anyone who is sufficiently comfortable with
the im-
plementation programming language to find and fix bugs by analyzing
the
code, especially if the implementation language is easy to learn and
readable.
This increases reliability because it exposes the flaws (if any) in
the source
code to more eyes, and is critical to long-term maintainability."
This cuts two ways. A person, once given suitable open access to
code, can mistakenly identify what he thinks is a bug and "fix" it.
And then (if your protocol requires it) he may even convince another
person that the fix is right, when it isn't.
Some errors are very subtle and will not appear except in very long-
running or obscure tests.
The reliability of elaborate code will not be improved because no one
really wants to re-think such programs, and even an attempt to do so
will not likely result in fixes -- witness the statistics on how many
more bugs are introduced in the process of fixing bugs.
I don't know what your experience has been in Sage, but the idea that
many eyes make all bugs shallow may not apply in a case where only one
or two people have the understanding to write or read a program
regardless of how nice the language is.
I hope these comments, negative as they may seem, provide some help
in formulating your position paper.
RJF
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
