GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Thu, 29 Apr 1999, Dennis Plunkett wrote:

>
> I must say a long and very interesting response, but I do see that the
> second last paragraph seems to be a bit of a contradiction. I always
> thought that "Top down" and "Bottom up" design was what gave you the "Big
> picture", and the "low level details" that went to making the product
> reliable, by forcing the programmer to cover all bases. Perhaps yo would
> like to elaborate on this point a bit more so that the cloudiness is removed.
>
> I do think that you last comment for embeeded programmers can and does
> apply to nearly all levels of software , perhaps with some minor variations.
>
>
> Dennis
>
I took the "big picture" to be a meta comment about the nature of
programming, rather than a statement about TOP Down programming,
perhaps I am wrong....

But personally, I use an alternating approach:

1. Top Down to get an idea of what the machine is meant to do.

(Top Down is the name for breaking down the big task into smaller subtasks
until you reach the point where the tasks are equivalent to commands you
can program the computer to do.)

2. Bottom up to test the low level assumptions.

(Bottom up is the name for building libraries of working routines that you
can plug in to any program) This is harder than it seems because the code
has to be relatively efficient, AND bulletproof or it will crater on you
or overgrow your processor.

3. Top Down to the new level that your routines have proven is practical
(much simpler once the original design is done)

4. Bottom up to deal with the ways the routines interact.... here's where
you find unexpected results, like the system crashes every time you
combine parta with partb... No explanation in the code, which operates
fine alone, and in other programs.... until you analyse just what the code
is doing at the processor level...

5. Top Down to the new level, and what work arounds you have managed to
make work.

6. Bottom up to put these elements together into something closer to the
original intent...

and so on, until I get something that does what I want it to, and doesn't
crash every time I run it.

(Not always possible).

But then, that is where the PICLIST seems to come in ;)

If you get completely socked in, it is helpfull to have a list full of
guys that have been there before to point out the error of your ways, or
the one missed opportunity that makes it all possible. You will note that
many of the articles on this list, have to do with cleaning up the details
of the low level code. That is because the bottom up programming requires
a level of skill with the exact hardware that no one programmer can be
expected to have on their own.

On top of that there is often a bit of high level debugging going on,
having to do with the best approach to make the low level code possible.

Languages like C or BASIC have the cachet of having proven code that is
very near to bullet proof.... Your Mileage May Vary, for a specific
processor, at the low levels, allowing you to do much of your programming
at a higher level of abstraction... which is one reason they are called
high level languages.

Sorry if I got a little long-winded there ;)

                                GREY