Burton Samograd <kruhft@hotmail.com> wrote:
+---------------
| If I wasn't being paid to reverse engineer it, I wouldn't have looked
| at it for more than two seconds, given up and gone to look at the postfix
| code, which is much nicer to look at.
|
| But by doing that, there is far less of a chance of me finding a bug
| which might be located somewhere in there. I think that's how most
| security flaws are found; not people explicitly looking for bugs but
| people looking to fix things somewhere and then they stumble upon them.
+---------------
And not just security flaws. All sorts of problems -- data size, code
bloat, speed issues -- seem to get fixed mainly when looking for some
*other* bug and then "just stumbling upon them" while reading the code.
In the 1970's, DEC started writing a lot of their PDP-10 systems code
(compilers, batch system) in the programming language BLISS (instead of
MACRO-10 assembler, which is what everything had been written in up to
that time). When users (of which I was one) started complaining that
the new FORTRAN-10 compiler (written in BLISS) was *huge* compared to
the old, beloved F40 compiler (written in assembler), as the fan of
BLISS myself I proposed a half-humorous/half-serious "Warnock's Law
for why BLISS programs are big", which was that since BLISS programming
was *so* much less error-prone than programming in assembler, once the
code had been written it was (mostly) never read again! And *therefore*
it missed out on all of the opportunities for optimization that ordinarily
occurred during "debugging".
Just consider: How many times have you dived into a piece of C code to
track down some simple bug, only to stumble across some *really* stupid
algorithm [e.g., a bubble sort of a large dataset instead of quicksort,
or a linear search of a large list of items rather than a hash table, or
massively-repetitious inlining of a large code snippet that could just
as easily be factored out into a subroutine, etc.] that you just fixed
"just in passing"?
In those same early 1970's, at Digital Communications Assoc. in Atlanta
we discovered how to write (nearly-)error-free assembler code [because
we *had* to -- we didn't have enough money to keep sending out updated
versions of the PROMs with the embedded code for our communications
processors!]. It was very simple, actually: We just made sure that
*every* line of code that went out the door had been read -- not just
glanced at, but actively *proofread*, with an eye towards "breaking"
it -- by *at least* 2 or 3 programmers other than the one who wrote it.
Read & read & read & tweaked & read & read & read some more. Expensive
(from one point of view), but very effective. Especially if the "readers"
get to look at the code in small, managable sections as its being written.
[At DCA, when one "came up for air" after coding any sizable subroutine,
one would grab a fresh cup of coffee and round up a couple of of people
to go into a conference room and have a "design review" (what we called
it -- really a line-by-line "break me if you can" walkthrough). Because
the reviews were frequent (a couple a day) and relatively short (~30min),
they were a natural part of the work flow and actually happened, rather
than being some monster "Project Design Review" event occuring entirely
late in the devlopment process to change anything!!]
But these days, try getting a manager of a C or C++ development team to
even *allow* people time to read other people's code, much less require it!!
[Though XP's "pair programming" is a re-invention of part of the spirit
of it, though with far too much rigidity of process for my taste.]
The implications for Lisp programming should be obvious. We speak
of avoiding premature optimization [which is good] during hyper-fast
incremental and interactive development, but once the resulting program
works (for some value of "work") how many of us -- honestly, now! --
always go back and perform a profiling and/or optimization pass over
the code? Or even just a "cleanup" pass?
Maybe I should retitle it "Warnock's Law for why {BLISS,Lisp,Dylan,ML}
programs are big"... ;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607