Top down and Bottom up programming

Question

The "top down" approach takes a high level definition of the problem and subdivides it into subproblems, which you then do recursively until you're down to pieces that are obvious and easy to code. This is often associated with the "functional decomposition" style of programming, but needn't be.

In "bottom up" programming, you identify lower-level tools that you can compose to become a bigger program.

In reality, almost all programming is done with a combination of approaches. in object oriented programming, you commonly subdivide the problem by identifying domain objects (which is a top down step), and refining those, then recombining those into the final program — a bottom up step.

In Top-Down development you start out with your main function, and then think of the main steps you need to take, then you break up each of those steps into their subparts, and so on.

In Bottom-Up programming you think of the basic functionality and the parts you're going to need and build them up. You develop the actors and their methods, and then you tie them together to make a coherent whole.

OOP naturally tends toward Bottom-Up as you develop your objects, while procedural programming tends toward Top-Down as you start out with one function and slowly add to it.

I've never heard the terms "top-down" and "bottom-up" used in that way.

The terms are usually used to describe how one approaches design and implementation of a software system and so apply to any language or programming paradigm.

In "On LISP", Paul Graham uses the term "bottom-up" slightly differently to mean continually extracting common functionality into shared functions so that you end up creating a new, higher level dialect of LISP that lets you program in terms of your application domain. That's not a common use of the term. These days we would call that "refactoring" and "domain-specific embedded languages" (and old LISP programmers would sneer that LISP has been able to do that since the 1950s).

I've never heard that classification applied to specific languages, rather it's a programming paradigm - do you first fill out the details (i.e. build full implementation methods) and then put them together (e.g. call them from them main() method), or start with the logical flow and then flesh out the implementation?

You can really do either with both types of lanugages... But I would say it's typically the opposite, in current OOP languages you'll first define the interfaces, forming the logical structure, and only afterwards worry about the implementation, whereas straight procedural languages like C, you need to actually implement some methods before you call them.

This Wikipedia page explains it pretty well http://en.wikipedia.org/wiki/Top-down#Programming