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

["Asger K. Alstrup Nielsen" <alstrup diku dk>]

I don't know if this discussion is off topic.  If you feel it is,
please tell me, and we'll take it to private mail.

> 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. :-)

I think I understand what you mean without problems.  One thing
that maybe would help a bit:  When you comment on some of my text,
please have an empty line in between the quouted text and the new
text, like above.  Sometimes, the stupid mail program will wrap lines 
at bad places, and this can make it hard to tell your comments from the \
original quote.

Also, maybe you could trim the quoting a bit such that the mail isn't
so long.

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

I agree that there is a need for a standard.  I argue that it is hard
to obtain such using the monolithic approach unless you have many
resources.

> 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 base this on glib and gtk+, you are tied to Unix.  That is hardly
a standard.  I realize a lot of scientist are using Unix, but even more
are not.

What I'm referring to when I'm talking about common data structures is
simple: Use the natural data structures applicable to the programming 
language you are using.  For instance, an array of doubles is natural in C.  
In C++, a vector might be.  Of course there are situations where there is
no clear choice, and there can be very good reasons to do something else.
In those cases, do that.
For instance, in Goose, the DataSet class represents a dataset of two
arrays (IIRC) that in turn are a reference counting array class.  This
makes sense in Goose because it allows the class to maintain constant
time statistical information when you update the class.

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

GNOME exploded because KDE exploded even more.  KDE exploded because
Matthias Ettrich took existing applications and ported them to Qt.
He had a clear goal to realize an easy-to-use desktop for unix, and
took the easy, less ambitious way out:  He started with an existing code 
base and hacked them to use Qt.  Since then, the project has gained a lot 
of momentum, and now they are doing things the "right" way (disregarding 
the licensing problems attached to Qt.), i.e. implement applications from 
the ground up, rather than hacking existing ones to pieces.
But I argue that this approach only works *now* because the project has
momentum, and therefor many resources.  Of course, maybe I wrong.

GNOME is a different example:  GNOME is gaining a lot of momentum,
because a lot of people feel that KDE is wrong, since it is based
on non-free Qt.  So, it's a counter reaction to KDE.  Since KDE is
going well, Gnome is trying to catch up (but there is still a long way
to go for them). In fact, RedHat has hired people to work on it full-
time, and this gives the momentum.  When you have that, you can afford
to do things "right".

As a better point for my argument, consider all the failed standardization
efforts for Unix.  There have been many, many efforts to try to create
a user friendly desktop for Unix in the past, and practically all have
failed.  It was when Matthias Ettrich took a pragmatic, and "unclean",
approach that things started happening.  He started out with an existing,
stable library (Qt), that enable the success of the project.  This turned
out to be the genious idea, and also the bad idea.  In the meantime, Troll
Tech has hired him :-)

GNOME has spent a lot of energy implementing GTK+, Orbit, Imlib and
other stuff in order to have a free base.  All of this is good, and now 
slowly we can benefit from this.  But it takes a long time to do this, and 
GNOME is far behind KDE because of this.  If more energy was spent on
writing working and usable applications rather than all sorts of cool
features, including bindings to all programming languages, far more
applications would exist.  I'm not saying that GNOME has been doing
the wrong thing, and I like KDE more.  I don't.  I just think that GNOME
can afford to do what they are doing because they have the resources to do 
it.  And my claim is that you can do more with less resources if you take a 
different approach.  Have a look at the list of applications available for 
KDE on
http://www.kde.org/applications.html 
and 
http://www.kde.org/cvs-applications.html.

Compare this with the similar page of GNOME on

http://www.gnome.org/applist/list.phtml

Once again, this is just my point of view.

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

Maybe, I don't know.  I just fear that the same thing will happen as
with Imlib:  The API is declared final, but then it is changed in the
next release.
This is not bad.  It just means that there is a risk that you have to 
spend time fixing other things each time a new Orbit release is made.

You just have to decided whether you want to take the chance or not.

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

http://www.swig.org :-)

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

I agree.  Just start with something you can handle.

> Yes, and from where do you get the stable libraries and the common
> data structures? 

The stable libraries are few, but never the less existing:
C++ provides a STL which is very useful.  It contains lots of the things
needed to provide standard data structures and algorithms.  Other languages 
have similar things.
Another existing libraries are the GNU mp library.  There are others, and
GSL is a good candidate for a future library.

The lesson to learn is to judge whether the library is stable or not.
Will we have to spend time rewriting lots of code because the library
we based ourselves upon is changing, and will the improvements resulting
from these changes pay off?

> 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

I predict that you will end up with lots of discussions in many months,
and the outcome will probably be good.  However, maybe you could have
spent that time implementing a sub-optimal solution instead, and using
that attrack people to help fix it and improve it.

> > 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 :-)

Yes, and this depends on how many people get interested in your project.
No better way to attrack attention than producing something useful.

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

And we have to learn from this:  Most designs turn out to be sub-optimal,
no matter how much time has been spend on it.  It is very hard to create a 
perfect design.  Therefor, just dive into it and do something.  Improve this 
later, when you have learned exactly what is wrong, and what you want to fix.

This is especially the case when you don't have many resources.

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

That is a nice vision.

Greets,

Asger Alstrup