I enjoyed reading this essay by @Paul W Homer posted inside a thread: http://theprogrammersparadox.blogspot.com/2007/12/nature-of-simple.html We often talk of simplicity but what exactly is it?

In any comparison of multi-dimensional things, we cannot easily pin one up against the other.

It also connects with what @Ivan Reese was saying about incidental complexity: https://twitter.com/spiralganglion/status/1198636841831825408

Lots to think about in that article. He’s using a mathematical approach to come up with an improved definition of simplicity and I like the projection idea. The example with how many files you create to separate 300 functions in a library reminds me of something else: if you look at the problem as three layers of abstraction — 1 library, 12 modules, 300 functions — the developer he describes clearly values a flatter hierarchy with only two layers and thinks that is simpler. He also mentions a usual approach would be to have 12 files for each module with functions grouped by how they relate to each other, likely causing different files to have a different number of functions. This reminds me of Christopher Alexander’s fundamental properties of wholeness, in particular the one called Layers of Scale. In architecture Alexander proposed that for a building structure to feel whole, it needs visible layers in gradually increasing or decreasing scales — a hierarchy, but not just any hierarchy, but each layer in the hierarchy has elements that are roughly similar in size (or complexity). This ties into complexity research and The Architecture of Complexity, why we see hierarchical structure everywhere, where it comes from, and why it’s so common in biological systems. I also like to connect that to my favorite linguist Lakoff and the container and part-whole kinesthetic image schemas that are building blocks of our cognition, how we make sense of our environment, and how we metaphorically structure the concept of hierarchy in our minds. And it ties into other cognitive science, like the famous 7+–2 study, which has turned out to be not quite exact, but the overall idea that we have limited capacity of what we can keep in our working memory still holds, and it is likely what causes us to want more structure after we accumulate too many things at once, and then we like to add another layer and stick them in categories. Think of when you make a list (shopping list items, to dos, articles to read, etc.); at some point you want tags or categories or directories to “keep a better overview”. In programming we create hierarchies all the time. Often we don’t try to keep the things we stick into categories similar enough to achieve well-balanced layers of scale. A function can be a one-liner or several screens long, often you find both kinds in the same project. Classes or types can have few or many methods. Data types can have few or many properties. And how many files do we want in our projects. We have a strong sense for hierarchy, but we don’t care as much about scale. I wonder what would happen if we changed that. (That’s another attempt at explaining something that ties together too many separate disciplines and is probably still hard to understand if you haven’t read the same papers I read. I’m trying to get better at explaining these things without the need to have all that context, so any questions or feedback what needs further clarification is much appreciated.)

I wasn’t really aiming for ‘mathematical’, but at some point I started making a distinction between ‘formal’ and ‘informal’ systems, primarily relying on rigor. That is, the only things that are valid in a formal system are formalized, where as on the informal side, something can be both valid and unknown. With that breakdown I started seeing mathematics as formal systems that in the case of something like economics, are being using to explain relationships in informal ones. Software is similar in that the business rules are messy informality but we try to model these within a rigorous Turing-complete system, so mismatches are common.