Top down and Bottom up programming

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).

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.