Earlier I wrote: Or, this is probably a manifestation of the people who have the domain expertise not coming from a background that is software rich.
If you looked at, say, numerical codes for finite element analysis, the people doing that have been using computers for decades, so there's a goodly number of people who have gone through the learning curve of "roll your own" vs "use the library".. Or, even if they're not actually doing it, they're working with other people who are doing it, so they pick up "good design" by osmosis if nothing else. The other thing is that a lot of codes (I don't know about the biology space, but certainly in engineering) are rarely from scratch. It starts as someone else's code that you modify, and then someone else modifies, etc. Over time, I think that process also leads to better design: the nasty ones tend to die out, the good ones persist and are reused. ... I also occurs to me that there's another factor here.. I learned to code in the late 60s and early 70s, when FORTRAN was king, and IBM's Scientific Subroutine Package (e.g. http://media.ibm1130.org/1130-106-ocr.pdf) was an essential part of doing things (who wants to code up a version for SIN() every time). As I understand it, This was something that IBM basically almost gave away (did it originate within SHARE?). So you were in the habit of using libraries to do things you needed. Likewise, I'll bet a lot of people used the source code published in the IEEE journals for FFTs (I know I sure did.. that early simple non-optimized radix-2 FORTRAN code that's about 20-30 lines long, for one thing). And you may have done this out of sheer laziness by borrowing the deck from a colleague or friend (who wants to punch all those cards). Burroughs had a similar thing for their mainframe machines. And there was tons of stuff available from DECUS. In fact, those documents and code were a fairly decent education in numerical algorithms (and of course, grist for subsequent discussions of poor algorithms.. random number generation is notorious) In an academic environment in the 70s, there wasn't any particular reason NOT to share your code. If you were working under a government grant or funding, it was basically public domain anyway. For big FEM codes (NASTRAN for mechanical stuff, NEC for electromagnetics) the source codes were published, with documentation on how they worked, and a lively commentary on the quality of implementation. So there's an enormous number of fairly well written examples (for the time) out there to look at and use and modify, so the culture evolved that way. In the biology area though, computers are a latecomer. There's also a recognition that those codes might be "valuable intellectual property" no matter how poorly coded and designed they are. A well-engineered and efficient code would be especially valuable, and provide a competitive advantage. AND, because of the Bayh-Dole act, even government funded development within the academic environment (traditionally open and sharing) can be proprietary. James Lux, P.E. Task Manager, FINDER - Finding Individuals for Disaster and Emergency Response Co-Principal Investigator, SCaN Testbed (née CoNNeCT) Project Jet Propulsion Laboratory 4800 Oak Grove Drive, MS 161-213 Pasadena CA 91109 +(818)354-2075
_______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
