[Tutor] a screed from a top down mind about a bottom up language

[Alan Gauld]

HI Kirk,

You are hitting on some very profound issues here. Ones that
have challenged the most brilliant minds in computing for years.

However, I do wonder about some of what you wrote. For example:

> I do not think bottom up, but top down. The language I use
> should allow me to write this way. it does not.

Most folks think top down. Thats why most software design books
teach top down design. So you start at the top, work your way
to the bottom and then sstart coding your way back up to where
you started. Thats the theory.

Now Python, being "executable pseudo code" allows you to follow
that process when *writing* the code but not when executing it.
ie you can only run it once you've reached the bottom level
- which is I think your point. But thats true of every computer
language because computers being stupid can only add 1+1 or 1+0
or 0+0 and move data from A to B. Anything else we need to tell
them - thats why programming is intrinsically hard.

> Proceeding from most general to most specific, I would define
> terms and functions, and layer by layer refine the definition,
> going into more detail, until finally defining the lower levels
> with existing python words methods,

That is a description of how I write most of my bigger programs,
whether in Python or any other language. (Actually its more correct
to say thats how I write programs using procedural programming, if
I use OOP then the technique changes because OOP doesn't work so
well top down)

> #####MAIN DO LOOP####
> DO:
> start
> crunch
> displayresults
> shutdown
> # FOLLOWING EXIT ONLY ENOUNTERED IF SOMETHING ABORTS DO TO ERROR!
> EXIT('FATALERROR IN MODULE'+$LASTFUNCTION)
> DONE;

def main():
   try:
      while True:
        start()
        crunch()
        displayResults()
        shutdown()
   except:
       print Error("Fatal error in Function")

> ######DEFINITIONS FOLLOW###########
> def start:
> readoptionsfile
> buildalistofallfiles
> readallfilesinlist
> clearscreen
> greetuser

def start():
   readoptionsfile()
   buildalistofallfiles()
   readallfilesinlist()
   clearscreen()
   greetuser()

etc/...

Looks like pretty standard Python so far. Its also exactly how
I write procedural code. What do you do different?

> And it would work. Because it's top down.

The two don't necessarily go together unfortunaely! :-)

> The computer has to traverse the thing many times, creating
> intermediate links,tables, temp files, and finally cooking
> it all down to a nice straightforward file of code which will run.

Thats a pretty good description of what the Python comiler does.

> This is either stored in the computer's mass data storage device,

As a .pyc file

> In time, every word would be defined in other words,

Which brings me back to the real challenge. You can't
run intermediate versions of your code until you define
stubs for the lowest level you have reached. Now in python
we can do that easily(with "pass") but it might be nice
for the computer to just define dummy stibs for us.
Unfortunately that has a big danger for producing reliabe
code...

> In fact, there seems to be some sort of twisted concept
> that this is actually VIRTUEOUS somehow, to be bottom up.

Nope, the top down approach is usually recommended as the
best way, but as I said at the statrt computers are so
stupid that until you define the bottom level they can't
do anything.

The compromise is to write ots of stubs at each level then
iteratively fill in the stubs until that level is complete

Your Policies are great BTW and what most good language designers
try to apply within the limits of current technology. In fact the 
Allan Kay paper I posted the other day explains exactly how he 
tried to meet those policies(including building his own hardware!)
when designing Smalltalk.


> Because it is interepeted, and executes things as it 
> encounters them, on the fly, It HAS to define things before 
> it can encounter a reference to them in another definition, 

Not totally true. Provided you keep things inside functions 
you can refer to things that haven't yet been defined, 
otherwise recursion wouldn't work!

So this works:

def foo()
   bar()    # refer to bar before its defined

def bar()
   print 'boo!'

So provided we put our top level code into a function 
- traditionally called main() and then call main as the 
last thing in our program - traditionally inside the 
if __name__ == "__main__":  mantra - then your style 
of top down programming works in Python pretty well 
as you requested...

> IMAGINE HOW MUCH MORE IT COULD DO IF IT WAS IN HARMONY 
> WITH NATURAL HUMAN CREATIVITY.

Thats where OOP comes in, it tries to go beyond the top-down
discipline and allow an even more creative approach that is 
still more closely aligned to the way the human brain works.
This is based on evolving patterns of ideas, with bits(objects) 
being added as you think of them. It also focuses on experimenting
with ideas as you go, trying things out even before the final 
solution works. Python is second only to Smalltalk in this 
regard IMHO.

Alan G.