I'm going to branch this off from the discussion on programming not progressing.

...my impression is that programming got much better over the last few decades for large industrial users, at the direct expense of more convivial uses. More layers of abstraction to understand, more constant overheads for starting a project, more moving parts to maintain. But dramatically better distribution, tooling and scaling.

It's notable though that the arc in most other technologies has been towards increasing scale and centralization at the cost of individual capacity. A few hundred years ago a single village could probably build their own carts. Now we're down to a dozen or so car companies per country. Most countries don't have the ability to manufacture their own cpus. I doubt anything in my house was created within a 100 miles of here. There is certainly very little that I could make myself. In "The Toaster Project" the author couldn't even find a modern text on iron production that didn't assume you had an entire factory - he had to work off a 16th century textbook instead. And when it came to more modern materials, he completely failed to produce plastic. I can't think of many exceptions to this arc. Writing comes to mind because we use it as a comparison to programming so often - used to be a centralized profession and now is practiced everywhere. I'm not even sure to what extent this is a problem. Specialization and economies of scale have been some of our main tools for progress. Maybe the future where programming only happens in thousand-person teams is the one where software works better? Either way, I think it might be important for this community to understand why most technologies progress in that direction and what makes the few exceptions different. One plausible answer is that, like writing, programming has some anti-economies of scale too. If we think of the trend in industrial software as trying to constrain software so that complexity scales linearly with size, then maybe we can find points of leverage in tools that abandon those constraints in exchange for more power in the small-software-niche.

I could see a future where programming is more centralized, and it's mostly a good thing for many of the reasons you describe. Much more is possible when you can harmonize the work of thousands of people. For example, your programming editor might be a thin client over a mountain of cloud infrastructure. Very little software would run "locally", but that's ok, because software shouldn't care what device it's running on; your various devices should all be portals into a single, coherent world where all your data and your tools are accessible anywhere, and computational resources appear bottomless. In that world, when you open an app or press "compile", a small slice of a datacenter springs to life for you, and it takes millions of lines of code and thousands of engineers to maintain all that. But that's invisible to you, because you shouldn't have to worry about it, the same way you don't have to know how a fuel injector works (let alone build one) in order to drive your car. Modern web tech might be analogous to the complexity of a car, but using it is more like getting a chassis, engine, drivetrain, seats, etc. from various factories and assembling them yourself, and less like buying a complete working car and simply driving it where you want to go. As the "car" gets more complex and advanced, it's increasingly inaccessible for an individual to wrangle, but the assembled product can go further than something you could build from scratch in your garage. If we're operating under the assumption that user has to do this assembly, you'll tend to want the simplest possible "car" you can design. But perhaps there's a second local maximum, where a "car" is a polished, well-encapsulated product (with extreme internal complexity and power) that's easy for anyone to pick up and use. So we have advanced "cars"— complex, economy-of-scale-optimized engineering marvels— but individuals can't really buy and drive them. But we could get there. (And none of this should be to the exclusion of building go-karts in your garage if you want to).

Would you say something like airtable or notion is an example?

I think they're doing good work in that direction, though more for "databases" than "programming". (My aim is to make Lynx fill the programming hole).

I agree that for most people, technology that "just works" is what they want. As @tbabb said, that shouldn't exclude the possibility of people building their own stuff. I'd take that one step further: it shouldn't exclude the possibility of people modifying industrial products they use, nor the possibility of delegating such modifications to a competent expert of their choice. The "enemy" is not industrial product, but lock-in and dependencies on a single supplier. With cars, this enemy has just been arriving over the last decade, in the form of computerization. Every modern car has parts that even an independent professional mechanic can no longer fix. You need special equipment available only under strict licensing conditions. In computing, that's already the norm rather than the exeception. It's dependencies everywhere. Whatever technical progress may be in Airtable or Notion, the real problem with them is that they are silos that make you dependent on the companies running them. We have almost completely lost interoperability except for the lowest common denominator, which is text files.

For our company, we are wrestling through many of these same challenges, but from the logistics and of the user's home as it relates to their carbon footprint. I find it immensely helpful to ground in a simple understanding of what it means to be human, and build everything up from there. So while it might be possible to build vast code integrating the fridge to scan the barcode on a jug of milk and alert the user on their phone when it is close to expiry, it will still be more socially desirable in some contexts to simply ask a neighbour for a cup of milk.

Concerning: "For example, your programming editor might be a thin client over a mountain of cloud infrastructure. Very little software would run "locally", but that's ok, because software shouldn't care what device it's running on" You are correct that such a world achieves economies of scale, but only along a certain dimension. Consider any web application that can also be a local application. The local application requires less: • overall compute (an app in the browser typically takes vastly more resources on a local machine than a native app with the same functionality and then there is the added compute in the cloud). • network infrastructure • code complexity (network latency, error states, etc)

More or less agree. Generally I don't think centralization and customization are inherently at odds with each other. To echo Ivan and others, you could have a platform which is fairly opaque/blackbox, but where the data and software that lives within its ecosystem is totally fluid, customizable, and controlled by users. A common platform might actually aid customization by offering easy and standard ways for software-pieces to talk to each other. Right now that's a pretty hard/ugly problem. Or put another way, it's much easier to customize a piece of software that's made of blocks which you can take apart. But that first requires buying into a platform where everything is made of blocks.

I think it depends on the meaning you attach to the word "programming". If programming is about building software tools for other to use then I agree that it will follow the arc you describe. If you see programming as a way to solve problems and understand the world in a dynamic medium then it will evolve more like writing. Those are not mutually exclusive because when we design software we fundamentally do two things: (1) we define the behavior of the software to solve a problem and (2) we produce an acceptable implementation. I think (2) will follow the arc you describe and will even go beyond because it can be much more automated than the design of physical artifacts. But we will hopefully democratize (1).

One of the things that I've learned is "code is not for itself" (phrase not mine). That is, the tools, languages, libraries and everything else are ultimately in service of a problem. If you can solve that problem by not writing code, then you have actually done your job as a programmer. One of the things I have learned about being productive as a programmer is that the code you don't write is often vastly more important than the code you do write. Sometimes ecosystems of tools and blocks that you can take apart are actually just code being for itself. Maybe we don't need to solve the "standard ways for software-pieces to talk to each other". Maybe we can define or architect that problem away altogether.