rjf,

On a number of your points I agree (see below).  However, I think
there is one significant problem with your point of view.  In my
roughly 30 years of experience as a chemist and professor using
software for:
1) computations
2) writing
3) database work
4) data acquisition
5) data analysis/reduction
6) presentations
7) teaching tools
8) dissemination (web, email, etc.)
I have found that most software written by pure computer programmers
is not as useful or error free as the software written by people who
actually do the kind of work the software is designed to do.

Some examples:

A number of times I have had programmers work in my laboratory on
interfacing computers to hardware to control the hardware or collect
data from it.  Every time, I've had to rewrite the code (sometimes
from scratch) to get it to work properly.  The first time I thought it
was a matter of not specifying things properly, but later it became
clear the problem was basic understanding of what the software really
was doing.

There are a number of software packages designed for analysis and
display of large amounts of experimental data.  One of the best
(blatant advocacy warning!) is IgorPro by Wavemetrics, Inc.  The key
here is that IgorPro was originally written by people who needed to
collect and analyze large amounts of data.  The code development is
still directed and primarily done by these people.  It is not an
opensource package, but all the algorithms are carefully documented
and traceable to published sources.  This way I can check and know
exactly what I am doing to my data.  So opensource is not the only
way.  The key in this case is that the software is good for data
analysis because the people who write it understand exactly how it
will be used.  Most other software of this type appears to be written
by people who only have a vague idea of how it will be used.

Microsoft Office is another example of how code written by people who
don't actually use the software for its intended purpose lead to poor
programs.  I know that at least some of the people MS hired to work on
their products are very bright and capable, but the software is
nothing short of "clunky".

The quantum chemistry packages we use in chemistry for modeling
molecular behavior are another example.  The code is almost
exclusively written by chemists and physicists.  Once again, the issue
is the difficulty of explaining sophisticated mathematical and
physical concepts to computer programmers who do not have the
background.  In general, we find it easier and more time efficient for
us to learn the computer science than the other way around.  This
means we do fruitfully collaborate with computer scientists, but
rarely do they get to do much programming for us.

> Maybe because most people are not too bright? :)
This comment is unnecessary.  LISP was designed for a specific purpose
and I do think that computer programming languages have improved since
then.

> I obviously view the phrase "viable ... alternative" differently.
>
> I don't know enough about Magma, but for suitable values of "viable"
> your job is done already.
> Maxima is a free open source alternative to Mathematica and Maple.
> So is Axiom.
> So is Jacal, Mathomatic, Reduce, ....
> And for Matlab, there is Octave.
You have a very good point here.  The SAGE community should be very
careful to not duplicate effort unnecessarily.  However, my comments
above apply.  If the existing code does not integrate well into the
much easier to use paradigm of SAGE it will have to be rewritten.

> I don't understand "bus factor". But I disagree that more people
> understanding the code is necessarily better.
> It is an intellectual challenge to build a hierarchy of programs to do
> something significant. I would hope that, after a point, programmers
> will use the abstractions, interfaces, and code libraries of others
> effectively without looking at or understanding the internals.  For
> example, I used code for computing Voronoi diagrams recently. I have
> no interest in studying the particular code.  I suppose I might look
> at other code, sometime, but certainly not as a rule.
>
As an experimental scientists, I assure you that the more observers
the more likely issues (or bugs) will be recognized.  That said, using
code that already exists is a good idea as long as it really does what
you want.  A good example is my contribution to the Jmol package
(automatic generation of web pages with Jmol embedded).  I wrote
almost no user interface code.  I used the Java SWING package because
it did what I needed and saved me lots of coding time.  I only had to
worry about the generation of web pages that behaved the way we wanted
Jmol to work.

> Perhaps this is one difference between computer science and
> mathematics. For a mathematician, a proof is acceptable if it is
> somehow internalized or understood "down to the ground". A theoretical
> computer scientist dealing with proofs might act like a mathematician,
> but a skilled programmer will strive to understand the program  he/she
> is writing relative to the execution environment including only the
> necessary classes, libraries, compilers, debuggers, hardware,
> operating systems etc.
>
This comes back to an issue of documentation.  Most commercial
computer programs have poor to non-existent documentation on what they
actually do (IGOR, see above, is an exception).  As a scientist, I
need to be able to check exactly what the code I use does.  This means
that I have very limited choices on software I can use for my work.
Open source solves this problem by leaving the code visible, so it can
be checked if I need to.

> > > My experience is that, while there are many clever and capable people,
> > > they still write programs with bugs, or insert fixes which themselves
> > > introduce additional bugs.  Stamping out this phenomenon is difficult.
>
> > Yep.  Software sucks.
>
> > > Especially in open-source projects, I think there are also well-
> > > meaning and energetic individuals who are less clever and capable who
> > > offer designs and implementations of features, or "fixes" that may be
> > > best avoided. The more of these you have (hundreds?) the worse off you
> > > may be.
I echo, William:  Software sucks.  Thus we must be able to continually
improve it. In most cases open source has worked well for this.  Open
source is essentially a fast version of scientific peer-review/
publication and the way our arts and literature build on the work of
previous people.

>
> > It seems like you view Sage as a "waste of effort", since it is new.
>
> Well, if you exactly replaced  Maxima by writing it over in Python,
> Yes. It would be a waste of effort.
>
This rewrite definitely has potential to be wasted effort.  William
has provided some reasons why it might not be.  Is there a complete
list of reasons somewhere?  Sometimes migrating existing code to a new
language or platform is required to improve it.  I'm just not
convinced, but don't know the details.

Jonathan

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

Reply via email to