This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


Gerard Jungman wrote:

"E. Robert Tisdale" wrote:

> Actually, counting by man years of effort,
> most of the "programmers at LANL"
> spend their lives writing very expensive,
> large, and nondisposable applications.
> 
> It's fairly rude to tell other people what they do.

I'm familiar with LANL.
Most of the programmers at LANL are scientists and engineers.
They don't think of themselves as programmers.
They don't get paid to write programs
but they do write programs to help them do their own work.
They seldom write programs that other people use.
Usually, their programs are of no use once they have completed
the task that their programs were written to perform.
Their programs are usually archived for a while
and then deleted when nobody can remember what they do
and the storage space is needed for something else.

> Apparently you consider yourself a "professional programmer",
whatever that is.

Someone who gets paid
specifically to write programs for other people to use.

> Ok, why don't you put a little substance behind your mouth
> and contribute some "professional code" to this project?
> Maybe you could earn the right to badmouth the people
> who have actually done something.

Take a look at
The C++ Scalar, Vector, Matrix and Tensor class library

	http://www.netwood.net/~edwin/svmt/

Take a look at
The ANSI C Numerical Class Library on the same page.

Take a look at
The Vector, Signal and Image Processing Library

	http://www.vsipl.org/

I've contributed.

> I think most "professional programmers"
> would fail to find their own assholes in the dark.
> I can't be expected to account for their behavior.
> 
> The question at issue here is not one of API design.
> The main point of this discussion
> is how to most efficiently implement the functionality
> that is required to reach the stated goals of the project.
> Don't change the subject, and don't insult the people
> who are actually doing something.

Personally,
I don't see anything wrong with Brian's implementation.
It's his implementation and he should be left alone
to develop it as he sees fit.
If you don't like it, you should re-implement it yourself.
The problem is that Brian isn't simply implementing
a standard API like the BLAS library API.
He is inventing a new API and
his API is designed around his implementation.
Eventually, he will discover that he has made mistakes.
Everybody makes mistakes but if application programmers
start using the GSL, it will soon be practically impossible
to correct those mistakes without breaking
all of the existing application programs
that depend upon the GSL.

> Finally, I apologize to the readers of this list
> for even bothering to reply to these messages.
> Perhaps doing so is simply a waste of everybody's time.
> If somebody out there has something intelligent to say
> about the implementation policies for this project,
> please do not be discouraged by this exchange from doing so.

If you invite discussion in an open Forum like this,
you are bound to read things that you don't like.
Right now the GSL API is pretty awful.
The so-called error handling is ineffective
and the API provides many more opportunities
to make programming errors than any error handling scheme
could ever hope to deal with.
It is difficult and dangerous to use.
It adds unnecessary overhead to numerical functions.
There doesn't appear to be any design rationale
behind the GSL that anyone can articulate.
In short, the GSL API stinks.
Numerical application programmers should avoid the GSL
until the GSL designers get their act together
and publish a document which specifies the GSL API
and the rationale behind their design decisions.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]