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?
Regards
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>
