Re: [guppi-list] Re: use of GSL in guppi

[Dirk Luetjens <dirk luedi oche de>]

Hi,

thank you for your comprehensive answer, but I would like to comment
on it and enhance my initial proposal. (My problem with english is that 
I can write more or less readable sentences, but that I canīt express
myself in the same detailed way as in my mother tongue. :-)

"Asger Alstrup Nielsen" <alstrup@diku.dk> writes:

> > I know there exist a lot of scientific related software, so why create a
> > new one? Because I think we can make it better if we integrate 
> > 
> > 1.) powerful CORBA services to allow all other libraries and
> >     applications be used from within "_GNU Science_" and to hide
> >     different implementation details from the user.
> > 2.) provide a "Visual Prototyping environment" 
> > 3.) support different programming languages
> > 4.) use glib as a basis for common data structures
> > 5.) use GTK+/Gnome as a highly sophisticated development environment
> > 6.) try to attract other scientific projects to include their code
> >     
> > Naturally everything would be released under the LGPL to have as much
> > feedback as possible from commercial and universitary institutions.
> > 
> > So, what do you think?
> 
> I don't want to sound overpessimistic, but I fear that this is too ambitious,
> and you run the risk of killing the project because it's more than we can
> handle initially.
Yes and no. But if there is no direction we all walk to, we never meet
in the end. The problem I found with the existing implementations of
mathematical libraries is, that everybody introduced a new set of basic
datastructures and every library dictates a different programming
philospohy to the user. You will seldom mix different libraries.

> IMO a better approach for a young project is to start with more modest goals
> and fulfill those.  Once you have something good running, you will attrack more
> people to contribute to the project, and it will slowly grow from there.  If it
> is a success, it might explode at some point.  But it won't explode from
> nothing.
My goal is to provide a home for scientific related libraries and
applications. I want to give a set of deign patterns that we are able
to use all the different libraries, data formats and what ever in the
long run. And I want to provide a set of basic structures and
functions used in every application. But these functions are almost
there (in glib, gtk+, ...) 

If you think of GNOME and KDE, they although exploded more or less from
nothing. The goal is to provide a user firendly free desktop. Whatever 
this is, isnīt layed out up to now.

A second example is copy straight from my knowledge during working in
an institute. All the students working on a diploma thesis reinvent more
or less the wheel over and over again. There is no common code base
since they work on different environments (Windows/Unix/Mac) and different
frameworks. The code they produce is more or less functional within
the project, but it is not portable to other systems. Having
recognized this malfunction the institute wrote an internal paper on
how to produce reusable code. The result is, that the first step
towards this is commenting the code. This is definitifly right, but not a
solution. I think there must be more. I for example as a young
engeneer have looked through different sources to find my way of
programming. If there would have been a guideline, basic libraries and 
such a project I would have been very lucky. So I worked hard to
implement e.g some polynomical regression within the khoros
environment. To solve the matrix I copied the LR decomposition code
from the "Numerical recipies" book. After days of debugging I
recognized that it wasnīt my code that computed wrong values, but the
code from the book was wrong. Not in all cases but in some
special circumstances. (They forgot a line during the exchange of
rows). 

> For a starting project, I think that it is more important that the project gets
> positive attention rather than boast high ambitions.  Compare the two different
> scenarios (in both I exagerate to make my point more clear):
> 
> 1) We have very high ambitions and want to make the all-killer application for
> scientific use.  Therefor, we want to use the latest technology for everything.
>  We want to use Corba to tie everything together (not a bad idea), but before
> this happens we have to work a lot on GSL to make it object oriented (maybe not
> a bad idea either).  Of course, we want this to be LGPL, so we have to convince
> the GSL people to change the license (not a bad idea), and this seems feasible.
>  We also want to use the data structures from GLib, so we have to rewrite
> everything to use that (that's a bad idea IMO).  Also, we want to support many
> programming languages, so we have to use a free and efficient Corba
> implementation that allows this.  Since this is non-existant at this point in
> time, maybe we could give a hand with Orbit.  Or maybe we should use SWIG
I think ORBit is stable enough to start using it. I go with the
argument someone on the gnome list mentioned: "The programmer expect
the defined API from the CORBA object. The faster he gets it, the
luckier he is." So I think we can start using ORBit and while ORBit
evolves our project evolves.
> instead.  However, SWIG is undergoing a rewrite at this point in time, and the
I donīt now SWIG. Can you give me a link.
> improvements they are boasting are worth waiting for.  But maybe another
> release won't happen within the next year.
> So we will start focusing on providing a visual prototyping environment,
> probably using some interpreted language.  We have to go shop around for such a
> creature.  Of course, using Fortran would bring a lot of benefits because of
> the huge existing base of scientific Fortran code, but did anybody hear of a
> free Fortran interpreter?  Hmm, maybe we could get somebody to do such a thing.
>  Maybe we should use a different language instead, Python is a nice one.  But
> since we want to use GTK+/Gnome, we have to get the Python GTK+/Gnome bindings
> done.  Since GTK+/Gnome is a moving target that takes quite some time, but of
> course it is feasible.  And while we do all this (how many people are we?), we
> have to attract people from other scientific projects by demonstrating the nice
> ideas we have.
Yes there is a circular dependency. But isnīt our life always compared 
to the "a dog bites itself into the tail" image. If you want to break
this circle you have to start somewhere. 

> Consider the alternative approach:
> 
> 2) We have modest ambitions initially.  We start out with a small, but clean
> and extensible code base using common data structures and well known
> algorithms, and stable libraries.  On top of this, we build a nice little GUI
> and take care that the basic functionality is there.  Then we make a release,
Yes, and from where do you get the stable libraries and the common
data structures? 
> maybe not too stable, but never the less good enough to show the world what we
> are planning to do. A few hackers pick it up and start tickering with it
> because they need a feature for their home assignment the next day.  They send
> in a patch, and the next week a new more stable release that compiles on three
> more platforms is done with a few new and useful features that solve real
> problems real people had.  At the same time, more and more people subscribe to
> the mailing list, and the patches start flowing in from different parties. 
> Somebody had written a symbolic equation solver as a school project, but don't
> want to start a new project.  Instead, she will spend a week plugging it into
> our project, and the leave it at that.  But since the system is useful, other
> people will mend out the bugs and clean it up to be really useful.  The program
> slowly grows, but constantly gains momentum because people can see that things
> are happening.  At some point in time, we'd have to switch to CVS because the
> maintainer can't handle all the patches, and I think you get the general idea.

Again, I donīt want to provide _the_ monster application in the first
run. In the first run I want to build a discussion forum where we put
all our requirements on a scientific application together into one
paper. This paper can be seen as a developpoing guideline and is
marked as a subjkect of change. In my
opinion we should although formulate a final goal. Afterwards every
group goes on implementing whatever they need for their project. E.g. I 
will do some image processing routines, another one statistical
routines, another one basic mathematical services. On a common
discussion forum we discuss the ongoing effort in the various groups
and start sharing code. E.g example I will need a FFT for my image
processing environment. So we think of how to integrate the different
libraries into the other project without posing circular dependencies
onto the different projects. 

> IMO it is more important for a young project to gain momentum than providing
> everything in the first release.  This is done by frequent releases such that
> the outside can see that things are happening here.  There are so many
> different projects around, and most of them have something good in them, that
> it is important to profile against all.  And the best way to profile oneself is
> to show that the project is alive:  Frequent releases and useful improvements
> in each one.  In short:  To provide people with the first datapoints from which
> they can extrapolate into the future and by that see that this is the project
> to cling on to.
> 
> Of course I exagerate a lot in my description, and I'm not trying to put you
> off from trying.  I just want to warn you that you might risk using a lot of
> energy on things that don't really get you anywhere.  Focus on the problems at
this depends on how many people help :-)
> hand, and solve those.  Maybe you would have to rewrite the code base at some
I think rewrites are one of the most common task during a programmers life.
> point because the original design starts to show it's shortcomings, but
Yes and I want to share me knowledge with other scientists working on
different fields but having one thing in common: All of us want to
manipulate and generate complex data sets
> hopefully, the project will have obtained so much momentum that a stable core
> of developers will undertake and *succeed* in this project.
> This is the way the succesful open source projects of today have been doing it.
>  And they have demonstrated that this development model is succesful.

And last, but not least, I donīt want to turn guppi into a big monster 
application. I want to make guppi part of a "GNU Science" project as
e.g the Midnight Commander is part of the GNOME project.

Dirk