A Note on Essential Complexity

---

Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things.. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.

Interviewer: You're kidding?

Stroustrup: Not a bit of it. In fact, there was another problem.. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do.

Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.

Interviewer: I don't believe you said that ...

Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.

Interviewer: So how exactly did you do it?

Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.

...

Interviewer: Yes, but C++ is basically a sound language.

Stroustrup: You really believe that, don't you? Have you ever sat down and worked on a C++ project? Here's what happens: First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding. God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other. I think the word 'synergistic' was specially invented to twist the knife in a project manager's ribs.

Interviewer: I have to say, I'm beginning to be quite appalled at all this. You say you did it to raise programmers' salaries? That's obscene.

Stroustrup: Not really. Everyone has a choice. I didn't expect the thing to get so much out of hand. Anyway, I basically succeeded. C++ is dying off now, but programmers still get high salaries — especially those poor devils who have to maintain all this crap. You do realise, it's impossible to maintain a large C++ software module if you didn't actually write it?

Nothing a "IF version is NULL THEN version = 1" can't fix ;)

Architecture emerges as the holistic shape of the design, the pattern of patterns, the bones of the system. It's possible to have architecture that reduces complexity by reducing scope and forcing apt compartmentalization into reusable, composable bits. One could perhaps even argue that GoF's Design Patterns attempts to commoditize the language to achieve greater degree of simplicity... but let's not.

I have trouble distinguishing architecture from design here. Imagine a kitchen with many cabinets, all alike. Some cupboards open by pulling a handle, some open when you push the handle, others swing up, or you must unscrew the handle. This is horrible and unintuitive, and surprising. Good architecture like good design eschews surprises (as in shock) and provides intuition by weaving consistency through the system. You build an expectation that things behave a certain way, and they do.

I would posit that good architecture, like good design, does not introduce complexity, rather the complexity is present regardless, and they delete layers of uncertainty and facilitate the necessary clarity to bring the overall objective into focus.

Perhaps there is a complexity cost introduced by adhering to a design or pattern or architecture, but if it's not outweighed by the credit it provides, offsetting overall complexity, then it's bad.

Your observation about path-dependency is on the money most certainly.

> awesome designers are great at predicting where the architecture will be and at forward-provisioning it.

And this matches the No Silver Bullet conclusion.

I'm not convinced of the latter. More architecture = more complexity in both short and long term, everything else being equal.

That is, if you can meet the required feature set with LESS architecture, it will be simpler both short and long term, compared to more architecture (which, since it's not essential for meeting the feature set, it would be adding abstractions and YAGNI features).

To quote a quote from the article: "In my experience most of the complexities which are encountered in systems work are symptoms of organizational malfunctions."

Simple is also relative though. No point preparing for Google scale, when there's less than 10 users a month. But, if the objective is something like discord, real time comms, then it'd be simpler to start with the correct language and framework for that use case.

I disagree with this. It's overwhelmingly more difficult to design something simple, or modify it so that it stays simple. Coming up with complex solutions is easy, the cost is the time and resources it takes to deal with that monster. Somebody has to read all that, walk through all that, and machine all that, and assemble all that.

Much of progress comes from figuring out simple solutions to problems, which frees up time and resources for other things. It must, in the end take less effort to make and operate the machine than doing it by hand, no matter how much it may seem to the contrary, because otherwise it wouldn't be worth it.

> Strictly following Moseley and Marks’s definition, the fact that we can get the user (or the customer, or the product owner) to accept a change of requirements, implies that the removed complexity wasn’t essential in the first place.

Practical example of my abstract description.

User does not want cdn-cached, region-distributed, lambda-backed resizing and validating image services, usage of the latest image compressing formats with fallback for the older browsers with performance dashboats of speed of loading. User wants to see their profile photo on profile page. Showing that photo is an essential complexity as it comes from the end user needs.

We can do a lot of that discarding of excess by realizing that there's the data that's read, the rules applied, and the data that's written. Everything else is ephemeral and plumbing. Looking at a process that way, and seeing the amount of complexity/abstractions one can ask what all that really necessary? Does it pay for itself in some way? It has to justify its existence beyond implementing the needed process.

I question the value of frameworks sometimes[0].

[0] https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-f...

Secondly, we may want to keep software on a complexity level understandable by humans, in order to not become completely dependent on the software engineering AIs.

Thirdly, the same effect that we observe with software written by humans getting to complex to understand by any human, is likely to also occur with AIs of any given capacity. AIs will have to take care, just like humans have to, that the complexity doesn’t grow to exceed their abilities to maintain the software. The old adage “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” probably also applies to AIs.

The essential complexity of software doesn’t depend on whether a human or an AI writes it. AIs may be able to handle more accidental complexity, but it’s unclear if that is an actual benefit under the cost arguments mentioned above. So maybe it will only be useful to create and maintain software with more essential complexity than humans can handle. The question is if we want to depend on such software.

Each level throws away a lot of the effort of the preceding layer.

E.g. after heroic engineering for the OS and memory management systems to present the illusory abstraction of a flat memory address space to the runtime, it almost immediately chops it up into smaller independent "packets" that don't interact directly.

Or the whole storage <-> memory <-> slow cache <-> fast cache <-> register divide.

I think we should be building processors that are made of tens of millions of very simple processors, each with their own memory and with dedicated "network on chip"-like communication electronics. These processors would directly map to language structures like objects/structs/functions.

Essentially flattening the stack so that there is just one level between language and silicon.

But IMO this necessary to fully debug it, unless you can prevent all leaky abstractions.