Blog:
This blog discusses ideas, drafts and papers about the whole spectrum of systems theory and anything else that concerns the WissTec R&D Services UG.04.7.2020 - Principles of Good Design 1:
The Bane of Sophisticated Simplifications:
(By Eike Scholz) This discussion will start with a very abstract definition, that is explained and exemplified later:
- A sophisticated simplification, is a simplification of a subsystem, that leaves a systems complexity unchanged or makes it worse.
In this series I will discuss practices of good design, that seem implicitly understood by experienced hackers but seldom discussed explicitly. Eric has the habit do doing these kind of posts and trying to find better wordings for actually anything that interests him. However, this series is focused on general systems design. I will also add some historical posts, when I think that what once was well understood and is still of importance, is crowded out by the "zeitgeist". Sophisticated simplifications are, for experienced systems designers, a well known pitfall, but seldom seem to be discussed in explicitly. They are the primary reason why my Metacore programming language development does take so long - soon 2 decades. In that case the objective is to design a simple, safe, close to the metal, real time, general purpose functional programming languages, that is expressive and easy to read. I will not finish that project, if I can not find satisfying tradeoffs for the design choices. There are enough finished programming languages out there to use, that do not really satisfy me. I do not need to write my own variant of such a language. That said, I will use programming language design, as main example to discuss what sophisticated simplifications are in the context of complex systems design. Even a simple programming language compiler or interpreter is a complex system. However, you might argue that a simple lisp interpreter is not really complex. This leads directly to one of the core problems of sophisticated simplifications: A high abstraction level can make system designs tidy and clear, but hide underlying complexities. For example, every typical lisp requires garbage collection (gc), which in it self is a non trivial subsystem. Further, the gc removes control of the memory handling algorithms "away" from the programmer. If the programmers objective is to do some hard real-time programming having gc is usually a sophisticated simplification. The programmer has to rewrite time critical code to bypass the gc algorithms in that case, and the overall system becomes complexer and not simpler. As a side note, it is also possible to estimate the overall general design competence of software project management, by evaluating their decision to use a specific programming language, before having done their due diligence with respect to the design objectives. Also, if your programmers are unable to switch programming languages as required, they have not yet reached the high tier programming competence levels. However, there are still tradeoffs to consider and common general purpose languages will do the job sufficiently fine in many cases. I think this competence evaluation can be generalized to the general case of systems design, where the tools to use are decided before doing an minimal amount of due diligence with respect to the design objectives. Anyway, back to the topic. A programming language compiler/interpreter is a good example of a system of several subsystems which should be as simple as possible. However, there is, in general, some kind of minimal complexity that is required to solve any kind of problem. There are even formalized measures for this, for example the Kolmogorov complexity. The central problem of designing a complex system is the inability to mentally handle the complete system as a hole and then trying to archive overall clarity and simplicity by making clear and simple subsystems. Assuming, that simple and clear subsystems will created a simple and clear overall system is a fallacy of composition. In particular, for the Metacore programming language example, I am always working on subsystems and try to make them as simple as possible. For example by minimizing a Kolmogorov complexity of the type system by trying to find a minimally short implementation. Then I often find an elegant simplification of this subsystem to realize later, that the used simplification shift complexity from one subsystem to an other without helping to make the language simpler as a whole. There is an associated design pitfall of trying to solve "concealed" hard or insolvable problems. For example, the hardest problem for Metacore's design, was to find a good tradeoffs regarding safety and real-time/close-to-the metal objectives. For years I just was not able to find a sufficient garbage collector or manual memory management algorithm to provide sufficient capabilities. After years of tinkering forth and linear lisp pointed me into the right direction. Sadly, there does not seem to be a general method of avoiding sophisticated simplifications. You just have to tinker with the design alternatives and hit your head, until you realize and clearly see why, what you are trying to solve can not be solved at all or not efficiently. For example, by realizing, that you are implicitly trying to solve the halting problem, which actually seems to be a common problem for complex systems designs. Touring complete subsystems can easily accidentally be specified, which has known implications for the design of secure systems. Other typical instances of the problem of sophisticated simplifications include shifts between syntactical/interface simplicity and semantic/internal simplicity. If you are interested in writing a formal academic paper on that topic with me, please let me know. I have some ideas on how to formalize the above ideas.