From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 26 Dec 2008 22:04:04 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <6839CD55D7371D7DC4433F3B@[192.168.1.2]> In-Reply-To: <0f120489807d451fadb7c7768fef6dbe@bellsouth.net> References: <0f120489807d451fadb7c7768fef6dbe@bellsouth.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Changelogs & Patches? Topicbox-Message-UUID: 71848f84-ead4-11e9-9d60-3106f5b1d025 > 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. > > [...] -- 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 blstuart@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 > >