> to come up with a conceptual framework where it became easy to express
Feels a lot like building software from bottom - once you get the building blocks defined right, the action, or the program, are trivial to express. When doing it from the top-down, you write the program using the building blocks you haven't defined yet, and you might end up with overly specific building blocks, needing other blocks for expressing different behaviors.
When you do the bottom-up building blocks right, new behavior is easy to express with them. Essentially, you are building up the language to reach the problem. Or making a DSL, whatever definition you like best.
Well, it depends. Sometimes in math you do a lot of chipping away at a problem, and eventually a bigger result falls after all the right foundations are built. That seems to describe bottom-up building.
On the other hand when a new high-level concept becomes clear and seems to emerge like a revelation, and people start thinking in terms of those new definitions, it seems that a hundred pages worth of smaller results can fall out of it almost effortlessly. This way of describing it is more top-down.
I don't know that there's an exact parallel with software. Math keeps feeding into itself in a way that software dreams about with our ambitions of code reuse. The old Object Oriented dreams of perfectly encapsulated classes and abstractions partially worked out, but not to the degree that was envisioned.
The current situation with package managers doesn't look like a tower that keeps growing higher and higher levels of abstractions. It looks like a tower where each person wants to place one tiny brick that they call left-pad, and next year we will rebuild the lower levels instead of going higher. So the top-down and bottom-up building that we do is different. We keep rebuilding the bottom, and we don't very much like when the tower of abstractions get too tall and hard to reason about.
Well, it depends. Sometimes in math you do a lot of chipping away at a problem, and eventually a bigger result falls after all the right foundations are built. That seems to describe bottom-up building.
On the other hand when a new high-level concept becomes clear and seems to emerge like a revelation, and people start thinking in terms of those new definitions, it seems that a hundred pages worth of smaller results can fall out of it almost effortlessly. This way of describing it is more top-down.
I don't know that there's an exact parallel with software. Math keeps feeding into itself in a way that software dreams about with our ambitions of code reuse. The old Object Oriented dreams of perfectly encapsulated classes and abstractions partially worked out, but not to the degree that was envisioned.
The current situation with package managers doesn't look like a tower that keeps growing higher and higher levels of abstractions. It looks like a tower where each person wants to place one tiny brick that they call left-pad, and next year we will rebuild the lower levels instead of going higher. So the top-down and bottom-up building that we do is different. We keep rebuilding the bottom, and we don't very much like when the tower of abstractions get too tall and hard to maintain.