"We never have time to do it right, but always have time to do it again."
from: http://www.netbeans.org/kb/60/uml/why-model.html
I do not support personally the idea of rewriting/replacing maxima but
the discussions remembered me the words above. This is why I mostly
spent my large percent of time to planning instead of coding.
Personally lisp is designed for symbolics, and it is more productive
to code symbolic software in lisp with respect to python, but I can,
to some extend, understand if people are hard at finding programmers
for lisp than python. So maybe, the long term education objective of
some computer/math courses/colleges should be motivating and educating
more lisp people.
Also, about the replacement of maxima, when William commented that
they can to some extend rewrite the code to compete to Mathematica,
Maple etc, I think, the users must be segmented and searched for their
preferences of needs on capabilities. Maybe someone only wants a
simple user interface to integrate, and maybe their numbers are much
more than others who can deal with much advanced tools in a command
line interface. Maybe some marketing research approach can illuminate
the way of the discussion's dİrections...
AAP

On Sat, May 2, 2009 at 4:15 PM, Jonathan <gu...@uwosh.edu> wrote:
>
> 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