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?
Didier Verna didier@lrde.epita.fr writes:
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/ef6822230da2...
(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.
On Fri, Mar 11, 2011 at 5:18 PM, Didier Verna didier@lrde.epita.fr wrote:
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