From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32077 invoked by alias); 22 Oct 2002 23:55:29 -0000 Mailing-List: contact gsl-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sources.redhat.com Received: (qmail 32067 invoked from network); 22 Oct 2002 23:55:28 -0000 Received: from unknown (HELO ra.astro.lsa.umich.edu) (141.211.105.12) by sources.redhat.com with SMTP; 22 Oct 2002 23:55:28 -0000 Received: from orb.astro.lsa.umich.edu (orb.astro.lsa.umich.edu [141.211.105.50]) by ra.astro.lsa.umich.edu (8.9.3/8.9.1) with ESMTP id TAA15938 for ; Tue, 22 Oct 2002 19:55:27 -0400 (EDT) Date: Tue, 22 Oct 2002 20:49:00 -0000 From: Christos Siopis X-X-Sender: siopis@orb.astro.lsa.umich.edu To: gsl-discuss@sources.redhat.com Subject: Re: About coordinated efforts on scientific software. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-q4/txt/msg00073.txt.bz2 On Tue, 22 Oct 2002, JJ Gomez-Cadenas wrote: > Let me bring an important subject to the discussion, that of > wrappers. If GSL is going to be truly the core of free-software > numerical calculations, wrappers are needed. For HEP it seems > one would like C++ and python wrappers. I have played for more > than a year now with a C++ wrapper for GSL and a number of > non-trivial issues emerge, such as the speed, correct use of > error handling, minimizing of copying of structures and the > like, which often end up by suggesting re-implementation rather > than wrapping (at least for some parts of the library). It would > be nice to understand better and to discuss all those issues. Interesting issues, indeed! Some of our very own GSL developers have thought about some of them, see e.g.: http://t8web.lanl.gov/people/jungman/except.pdf My little personal experience with this is that there is a dichotomy between "big project" folks and "Joe Numeric" folks. If you talk to people involved with the development and maintenance of big codes, they will probably propose some elegant top-bottom design, which usually requires an object-oriented programming methodology to implement and, increasingly, component programming. These folks will also often insist that any code bigger than a hundred lines needs to follow a similar path :) and that "a project rarely starts with the intention to become big" but in the end, it does, so better plan early on. If you talk to Joe Numeric, he'll wonder why you need anything else but Fortran, he'll tell you how annoyed he is by NAG's requirement to return error numbers, and will reprogram a new single-variable equation solver each time he needs one because he hates black boxes :) Seriously though, i wonder if your experience with C++ wrapping ultimately means that we are doomed to reprogram our libraries every time we move from one language family to another (at least if we want to do a good job)... Christos