Two Approaches to Learning Programming: Top-Down and Bottom-Up

Also don't forget about feasibility.

Whether you start bottom up, or top down, your design may run into performance problems at some point. In cases where this is likely, it is better to determine key components, test their performance, and run calculations.

This is why I say that JavaScript is a great first language. Not because it teaches you how to write good code, or be a good developer, but because the barrier to entry is so low to get started; with a text editor and a web browser that everyone has on their system, you can start making something that has a tangible (visible) result. That's powerful.

Once a person has a handle on things like how code is structured and interpreted, syntax, objects, etc. then you can introduce them to the terminal and start teaching them Python if you want. But nothing comes close to driving interest like making a button on a screen that moves stuff around.

Better would be the DSL approach: Express the problem in an easy to understand, natural-looking DSL and then implement the DSL. This is both top-down (describe problem) and bottom-up (implenent DSL words) at the same time.

In common OOP languages (i.e. Java), the mechanisms of OOP can be used as an ersatz DSL, albeit a bit limited.

Nowadays, programming is much more complex than it used to be (unless you consider toy programming languages). For me, visual feedback was always a key factor in the things that I made. When I started, there was no top down or bottom up. You just started programming, and you actually understood what was happening because it was not that complicated.

Let me give you an example. QBasic is the first language that I learned. Suppose you want to draw a white pixel in the left upper corner on the screen. To do this, you can do: SCREEN 13 PSET (0, 0), 15

If you understand this and for-loops it is trivial to fill the screen with a color. Then the next step is to make the color of the pixel dependent on the position. I made some wonderful graphical stuff with this (rotozoomers, plasma, fire effects...).

Now, if I want to do this in C(++), I probably can, but it will take me at least an hour of research. Same thing for C#, Java, Haskell, and so on.

This is not a completely fair comparison since QBasic ran in DOS and there was no need to summon a window, but that is exactly my point: things keep getting more complex. To plot a colored pixel on the screen in QBasic, you have to know about pixels, screens and colors. To do this in a more modern environment, chances are you have to pick the right API and understand all abstractions it introduces (probably including windows, graphical contexts, buffers...). The trend seems to be to ever more abstract, complex, and powerful frameworks.

If you are already a programmer, this is a gradual progress and it is feasible to keep track of everything, but for new programmers it takes a looooong time to get up to date with all the new abstractions that people have come up with (and I think are not always that important to start programming).

Now I'm not saying that we should not introduce abstractions or frameworks or implying that DOS graphics were better than today's system with windows. I'm just saying that these advances come at a high cost, and I don't know if there is a solution.

There’re no fundamental concepts.

If you’ll start with C, there’s assembler and machine code underneath.

Underneath there’s memory hierarchy, CPU microarchitecture, buses, and other things like USB protocol stack.

Underneath there’re logic gates, comparators, summators.

Underneath there’s physics, quantum mechanics, electrodynamics.

Each of these abstraction levels is fundamental relative to the upper one.

The level of abstraction that you declare fundamental is arbitrary. You can define your “fundamental level” threshold much higher, e.g. JVM or S-Expressions, and start bottom up from that arbitrary level.

The level a median developer believes is fundamental drifts upwards over time.

70 years ago it was impossible to be a programmer without knowing about logic gates. The majority of modern software developers can’t design stuff from logic gates, they don’t even know much higher-level USB protocol stack, and yet they are able to do their jobs just fine.