DNA Workbench for X-windows

Reinhard Doelz doelz at comp.bioz.unibas.ch
Wed Nov 9 12:30:53 EST 1994

John Barton (jjb at watson.ibm.com) wrote:

:     In addition, this suggestion could backfire: without support, new
: approaches to software development will die.  "It must be univerisally
: portable" would have killed the WWW effort at CERN and Mosaic could not
: have been developed under such restrictions.  What's more, if you insist

Oops - wait a moment. As I talked to TBL the first time the W3 system 
was introduced to a wide audience this dated back in 92 on the JENC 
conference in Innsbruck/Austria and it *was* portable like hell. The 
W3 effort is so successful as it *is* portable software. New software *must*
be univerisally portable.

: on portable software, be prepared to switch to DOS/Windows/Intel: is
: that what you want?

sorry, yes ! Millions of users can't be ignored. 

:     Rather than attack the support of innovative software, wouldn't it
: be better to support innovation in software that promotes portability
: and to support money for adapting software to make it more portable?
: Grant money flows for publications, rarely for software: when this
: changes, portability will come quickly.

True, but only half-way. Prototyping on an exotic system is ok, but don't
release prototype code. Your suggestion implies an attitude that the 
developer will not need to incorporate the portability idea in the design,
and I strongly argue that this behaviour bight be typical but is one of 
the reasons that software lacks usefulness today. Why should you publish
software which can't be used? The grant agencies will not applaud on this
attitude for a long time as everyone reaches out for research which is 
applicable in fields other than the original researcher's laboratory. 

We rewrote our HASSLE system twice before version 3.0 showed up on the 
internet inoficially,  and HASSLE 4.x was the version which was finally 
published. As we currently redesign the software *from scratch* we can 
actually afford a top-down design and require functionality in an 
abstracted, language-independent fashion as we have learned in the previous
releases that it will work - earlier versions proved that it does work. 
(By the way, HASSLE is a 5+ person-year effort). 

C++ is, for us, just not an option today as we must currently support 
biologically used software on 10+ different flavours of operating systems. 
C is, for us, economically, the language we must use at this point of time 
because all other languages and CASE tools are far too expensive or 
problematic to be used (did you try to write lower-layer socket calls in 
C++ ever? Good luck!). It is true that version 6 iof our software will 
have an object-oriented C++ binding, but version 5 of HASSLE is object-
oriented in design, and implemented entirely in C. Actually, some people 
argue that C++ is not object-oriented enough and prefer Oberon.

The language doesn't really matter, neither does the actual coding in 
the end, the *design* matters. If you call for professional software the 
developers in academia have to recognize that the plan-and-design phase 
is two third of the work. Scheduling a PhD thesis for a complex software 
package in biology might be problematic if a 'real' package of 10000+ 
lines shall be the result as three person-years will not necessarily allow 
for careful design, prototyping, redesign, and final implementation. 

And, did I miss that the *documentation* is done before the first line 
of code is written? 

Reinhard Doelz
EMBnet Switzerland 

 R.Doelz         Klingelbergstr.70| Tel. x41 61 267 2247  Fax x41 61 267 2078|
 Biocomputing        CH 4056 Basel| electronic Mail    doelz at ubaclu.unibas.ch|
 Biozentrum der Universitaet Basel|-------------- Switzerland ---------------|
<a href=http://beta.embnet.unibas.ch/>EMBnet Switzerland:info at ch.embnet.org</a> 

More information about the Bio-soft mailing list