In article <1994Nov9.173053.28588 at comp.bioz.unibas.ch>, doelz at comp.bioz.unibas.ch (Reinhard Doelz) writes:
|> 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.
Sorry, I did not make myself clear. It is information exchange via
WWW that was initially non-portable: "This grant should not be funded
because ASCII files are the only portable medium". I think the widespread
use of WWW speaks for the portability of its underlying implementation.
But what if the grant never came in the first place?
|>|> : 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.
(I agree).
|>|> : 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?
I absolutely agree that portability should be an important early
design goal, to be balanced with other goals. The balance should not
be struck through lack of training as is all too often the case.
|> 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.
|> ?? I don't understand this comment. My primary point was: let's
not rush out and convince grant agencies to fund only if it will be
lowest common denominator software. The message should be: let's rush
out and convince grant agencies to fund more software, including work
that will help scientist produce more portable code.
|>|> 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.
|>
If scientific computing systems are considered primary reference
material suitable for sustained funding and career advancement, then
quality will improve dramatically. Rather than ask for restrictions
on software projects, ask for more and better projects.
|> And, did I miss that the *documentation* is done before the first line
|> of code is written?
|> Some programmers need this; some do not. All users need it: perhaps
we should settle for good docs in the end.
|>|> 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>
--
John.
John J. Barton jjb at watson.ibm.com (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598
