The problem is scaling and complexity: if you have 100 interacting entities, and add one more, it increases complexity by a factor of 100x. The solution is to

The problem is scaling and complexity: if you have 100 interacting entities, and add one more, it increases complexity by a factor of 100x. The solution is to subdivide it into modules that can be treated as a single entity. The complexity within each module is much less because there are fewer entities within it, and there is less complexity between modules because there are fewer modules (which can be seen as entities at a higher level - and we can nest modules, to further reduce complexity). The problem with this is that it is hard to find the right modules, that minimize interactions within them and between them. It takes a lot of data, a lot of insight and a lot of trial-and-error to find modularities that work well - it amounts to a theory of the data. In science, most theories take a long time to be discovered and a long time to be improved on - but we expect to do this routinely on each individual software project... [ One way this is done in practice is when someone decides to tackle a generally needed problem, and wrap it up as a component (e.g. 3rd party library). To the extent that this is the right modularity, it will not only reduce the work a user needs to do to use it, but also reduce overall complexity in the total system (including for the component designer). ] Instead of expecting it to be easy to find the right modularity, we should expect it to be hard; instead of insisting on a simple theory that explains everything, we should celebrate every small step towards better theories. This is what all practitioners facing empirical complexity in the real world end up doing. > I feel like my answers are quite trivial since nobody really knows how to design a good language, including me.