At 10:16 PM 8/30/2005, Frank Brickle wrote:
Jim Lux wrote:
> However, my comment was more addressed to developers of the
> software. Basic documentation will make it a realistic goal to get
> multiple contributions to the free codebase. Otherwise it will remain an
> interesting toy for the technically persistent and skilled software
artists
> with plenty of paid or unpaid time to spend on it.
Well, there is a definite philosophical difference here. I should point
out that, FWIW, my view is based on -- well, I was going to say almost
forty, but, eep, it *is* forty -- years of working with these idiotic
machines, and countless thousands of lines written fast, slow, and
anywhere in between.
Documentation ain't worth the paper it's writ on.
I would say that is is situationally dependent. I'd hate to have to try
and write software (of any kind) without some reference that defines the
language syntax and semantics, at least at the start.
Documentation also becomes more valuable when multiple people are involved,
particularly over large spans of time or space.
<snip>
At the same time, I happen to be a convinced exponent of bottom-up
programming style. What that means is, in short, building up a small
vocabulary of low-level application-specific operations, composing them
then into a larger vocabulary of utterances, and then telling the final
story in the language that's grown up with the application.
Sure.. and one can tell a moving and elegant story with your own private
language, and it may sound just fine.
However, if you want a dozen people to work on that software, and they
aren't all there at the start, the problem is one that the "first step" in
working on the program is that you have to "learn the language",
unfortunately without the help of a dictionary or any other thing.
Immersion may work, but it's painful, and requires a big commitment. It
also only works if there's a body of speech to be immersed in. If all the
speakers have died, and all that remains is their writings, translating
might be a bit tricky. The Rosetta Stone is prized for a good reason.
"Bottom up" is a fine programming style, but it's not a particularly
effective architectural approach for large systems (where large is defined
more in terms of the number of contributors than the number of lines of
code). This is a hard problem, which is why software development
methodologies have evolved a lot from the "modular programming" of my
youth. Creating architectures that can support concurrency is only one
challenge. Another is creating software that can be maintained and
modified into the future, generally by people not the original creator.
To use the construction metaphor: the outside may be stunning and elegant
and one of a kind, but making it took a lot of unexciting hammering
standard sized nails into standard sized pieces of wood. At some point
Frank Gehry has to do drawings, because he can't single handedly build the
building.
James Lux, P.E.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875
