DNA Workbench for X-windows Developers Guide?

birney at molbiol.ox.ac.uk birney at molbiol.ox.ac.uk
Thu Nov 10 19:52:53 EST 1994


In article <7NOV199412022977 at seqvax.caltech.edu>, mathog at seqvax.caltech.edu (David Mathog) writes:
> In article <39b2rt$sie at netnews.upenn.edu>, tisdall at amalthea.humgen.upenn.edu (James Tisdall) writes...
>>It will be based on
>>the new version 5 of the "perl" language, that includes a "Tk extension".
> 
> Looking the gift horse straight in the mouth...
> 
> Speaking as a harried system(s) manager, would all you developers please make
> a real effort to not develop on top of layer after layer of semiportable
> software?  I get really tired of having to install 2, 3, or 4 pieces of 
> software just to get the desired program running.  More often than not, 
> the requisite version of one of the support packages won't work on one
> platform or another (yes, especially VMS).  
> 
> I suggest that grant reviewers going through applications that include
> software development, make sure that the project employs the rules that are
> put forth below.  It will save us all some money and insure that any tools
> developed are available to the largest number of users. 
> 
> Portable software, which is relatively ulcer free in terms of installation
> and porting, adheres to the following guidelines:
[ .... Lots of guidlines ..... ]

Aren't we biologists...? can't we use natural selection to weed out the
programs which don't work. That is why clustalv is still about (and 
going strong) whereas GDE looks *real* cool on a sun and doesn't even
start under VMS... [not to knock GDE because it is cool. It's just that
I can't use it as I've got VMS or OSF/1 with no xview libs].

Now if you could only fund on the basis of the number of people which used
the programs then we really could set up "evolution in silicon"

And then your guidlines would just be "good genes" in the gene pool.

:)

Just kidding... not too practical.

To add what I think every developer should do

a) simple line interface (menu's etc) that will work happily on a vt52 
first THEN fancy GUIs. Everyone can telnet or kermit into somewhere: the
number of people running X  or even running windows from *their own*
machine at a lab is limited.

b) Check the memory allocation doesn't go over limits and works on all
OSs (I think these are the most intractable bugs to find in C).

c) Beta test on EVERY platform you can find/or persuade other people to
beta test on it.

d) Beta test lots with people who will give you bug reports/improvements
to make.

e) *Really* modular code.


ewan

birney at molbiol.ox.ac.uk




More information about the Bio-soft mailing list