Bottom-up, top-down or both ?

[Didier Verna]

It is well known that a functional approach to programming helps
thinking in a top-down fashion. Idioms made available by first-class
functions (e.g. mapping and folding) help you write down the general
ideas first, and worry about the details later. Paul Graham has nice
examples of that in On Lisp IIRC.

In fact, it seems that being able to think in a top-down fashion is not
specifically tied to functional programming, but perhaps more generally
to the level of expressiveness that your language provides.

For example, I find that the very existence of a REPL helps a lot: you
can test a function on manually-provided data, that would normally be
constructed by a lower-level, yet-to-be-written function. You can
pre-define stuff to do nothing but print "I'm here", just to check if
the bigger thing works.

In Lisp, with half-defined generic functions, you can even have your
program half-working, some details remaining to be sorted out later. So
obviously, Lisp being as expressive as it is, is of great help in
thinking top-down.

Even in Lisp, however, some things need to be defined before they can be
used. So I recently discovered, to my greatest astonishment, that even
if my thought process is top-down 99% of the time, my /code/ is *always*
written down in a bottom-up fashion. Occasionally, I might have one of
those quasi-hysterical crisis in which I would spend hours re-organizing
my code until the I get the overall expression of the program as close
as possible to the ultimate upside-down pyramid of dependencies. And
then, we I need to immerse myself again into something I wrote a long
time ago, I usually read my files backwards... or not!

So I was wondering, how's your code organized? How's your thought
process organized? Top-down? Bottom-up? Both?

[Pascal J. Bourguignon]

Post by Didier Verna
So I was wondering, how's your code organized? How's your thought
process organized? Top-down? Bottom-up? Both?

This is a topic that has already been discussed (almost to death but not
completely, only 93 posts) on cll:

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ef6822230da2c706/7213ee8be6600ae9?hl=en&q=%22top+down%22+%22bottom+up%22+group:comp.lang.lisp+author:pascal+author:bourguignon#7213ee8be6600ae9

(also, have a look at this example of "wishfull programming" (one could
classify it as a top-down approach):
http://groups.google.com/group/comp.lang.lisp/msg/a827235ce7466a92
)



In summary, lisp allows you to do it however you need to do it,
bottom-up, top-down, outside-in, or inside-out.

How you need to do it depends on your knowledge of the problem domain,
and on the availabililty and precision of specifications.

[John Q. Splittist]

Post by Didier Verna
It is well known that a functional approach to programming helps
thinking in a top-down fashion. Idioms made available by first-class
functions (e.g. mapping and folding) help you write down the general
ideas first, and worry about the details later. Paul Graham has nice
examples of that in On Lisp IIRC.

In fact 'On Lisp' makes the opposite point. From the Preface: 'As well
as writing their programs down toward the language, experienced Lisp
programmers build the language up toward their programs. This book
teaches how to program in the bottom-up style for which Lisp is
inherently well-suited.'

During the brief period of my university career when people were
trying to teach me programming, top down ('structured') was the way to
go, not just in Pascal, but in COBOL as well. But that was when
writing a program meant using a pen and a specially printed pad of
paper (with the important columns highlighted), so having one's first
thoughts accepted by a compiler was not an issue. It was also an era
where the usual (or at least assumed) case was a well-specified
outcome e.g. produce this report that takes 3 accounts clerks 1 week
to produce in only one overnight batch job. PG (in 'On Lisp') says
this era is over, and that specifications are now 'extremely complex,
or even open-ended.' He continues: ' The theme of this book is
twofold: that Lisp is a natural language for programs written in the
bottom-up style, and that the bottom-up style is a natural way to
write Lisp programs.'

To answer your questions: both. As, I suspect, for all programmers,
always, everywhere.

JQS