The Story of Mel
[...]
I compared Mel's hand-optimized programs with the same code massaged by
the optimizing assembler program, and Mel's always ran faster. That was
because the "top-down" method of program design hadn't been invented
yet, and Mel wouldn't have used it anyway. He wrote the innermost parts
of his program loops first, so they would get first choice of the optimum
address locations on the drum. The optimizing assembler wasn't smart
enough to do it that way.
[...]
-- <http://catb.org/jargon/html/story-of-mel.html>
Know why Mel is no more in business? 'Cause one man can only do so much
work. The Empire State took many men to build, so did Khufu's pyramid, and
there was no whining about "many mechanisms that don't work well together."
Now go call your managers "PHBs."
--On Friday, December 26, 2008 3:44 PM -0600 blstu...@bellsouth.net wrote:
On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote:
appropriately, this being a plan 9 list and all, i find code
written from the bottom up easier to read.
Depending on the task (on the aim of the software), one happens to split
from top to bottom, and to review and amend from bottom to top.
There is a navigation between the two.
Bottom to top is more easier because you are building more complicate
stuff from basic stuff.
Some time back, I was trying to understand how to teach the
reality of composing software. (Yes, I do think of it as a creative
activity very similar to composing music.) The top-down and
bottom-up ideas abound and make sense, but they never seemed
to capture the reality. Then one day, after introspecting on the
way I write code, I realized it's not one or the other; it's outside-in.
I don't know what little tools I need to build until I have some
sense of the big picture, but I can't really establish the exact
boundaries between major elements until I've worked out the
cleanest way to build the lower-level bits. So I iterative work
back and forth between big picture and building blocks until
they meet in the middle.
As an aside, that's also when I realized what had always bugged
me about the classic approach to team programming. The
interfaces between major parts really comes last, but in assigning
work to team members, you have to force it to come first.
And of course, from that perpsective, it makes perfect sense
why the best examples of programming are ones where the
first versions are created by only 1 or 2 people and why the
monstrosities created by large teams of "professional software
engineers" are so often massive collections of mechanisms
that don't work well together.
BLS
