The Law of Conservation of Complexity | Hacker News Reader

The Law of Conservation of Complexity

nomodes.com

102 pointsangrygoat45 comments

Having non-modal interfaces seems simpler for the user in a simple application, sure. But when I consider all the power in the classic example of vi/vim command mode I'm unconvinced.

If you want that flexibility and power, the options must live somewhere. Dividing that into two mutually exclusive modes breaks up the complexity of the main interface. I need to know a handful of key combinations like ESC, i, r, h, j, k, l (or arrow keys on modern systems), :, w, q, s, d, g, G, v, V, /, ?, !, % to get a vast majority of daily tasks done. How many nested drop-down menus would I need to navigate or multi-modifier hotkeys must I remember to do the same thing just so I don't have to remember one bit (which mode I'm in) before hitting a key?

The human mind is actually very comfortable with modes. Work, home, visiting family, visiting friends. Cooking at home vs dining out vs ordering in vs baking vs grilling vs cooking a holiday feast vs catering in vs party snacks and drinks vs road trip snacks. Driving vs taxi vs riding a bike vs walking. Retail vs garage sales vs in-person auctions vs online auctions vs online fixed-price shopping. Lending libraries vs bookstores vs reading rooms vs newsstands vs books we own vs ebooks. Math vs prose vs poetry vs visual communication vs music. We pay attention to different things and follow different sets of rules in different circumstances all the time. Is it easier to remember all the rules for all scenarios at once or to switch contexts?

Developing muscle memory for Emacs is no harder than developing it for Vim, and since both involve rebinding annoying keys on the keyboard (mostly about whether Caps Lock becomes Esc or Ctrl) I prefer the editor with the more mature extension language.

Make Caps Lock both! I've got mine bound to be Esc on tap, Ctrl on a longer hold. Best thing I ever did for my pinky. (I'm an Emacs user, though I'm sure Vim users would benefit greatly as well.)

See, that's a reasoned argument of pros and cons. You didn't outright dismiss modes or dismiss a tool because it uses them. There's not a problem at all preferring a tool that's modal or one that's amodal. It seems a weird sort of zealotry to dismiss one or the other for that reason alone.

If you're looking to extend your editor a bunch then Emacs is great for that. Personally I primarily use a keyboard with no Caps Lock key so I don't worry about remapping it.

Alt+tab is mode change to an extent.

Mode and modeless are both sides of the same coin.

Or the same sides of different coins.

Which is why Jef Raskin in his system and interface designs tried to avoid having the concept of separate applications at all (instead of installing different applications, you'd install commands, which could be used from anywhere in the system): https://en.wikipedia.org/wiki/Archy#Commands

There is a formal theory of modes, so to speak: Hierarchical State Machines (HSMs).

A HSM has, or can have, a considerably simpler description that the equivalent FSM, because the equivalent FSM will have to duplicate all the states that are hierarchically shared in the HSM.

Some info here: https://en.wikipedia.org/wiki/UML_state_machine#Hierarchical...

Seems to overlook the concept of essential vs incidental complexity. Most processes I have seen in practice have huge amounts of incidental complexity.

I prefer to think about it from a different point of view: processes always grow in complexity until reasonably intelligent people can't understand them any more. It takes incredible discipline for anything to be maintained in a "simple" state below that threshold because reasonable people will all agree that adding some more complexity at that point has a low cost compared to the value generated. For this reason, most things in the world sit at that threshold of complexity where they are just comprehensible but still annoying complex when you first encounter them.

The “Original Formulation” uses “irreducible complexity”. Isn’t that the same thing?

Complexity is not conserved. It is a bound. A solution can not be simpler than the problem, when both are viewed holistically and complexity is properly understood. (Yeah, I'm handwaving, but at least I acknowledge it. I don't want to write twelve paragraphs defining "complexity" right now, because my real point is....)

But the solution sure can be more complicated than the problem.

Fred Brooks wrote a book about complexity, accidental and essential. Essential complexity is the lower bound to which you refer, and the hard limit that prevents major advances in programmer productivity.

https://en.wikipedia.org/wiki/No_Silver_Bullet

That is more or less what TFA says: "Every application has an inherent amount of irreducible complexity." "Irreducible" means a bound, but it does not mean a constant.

The name is misleading to a scientist, who has a specific understanding of what "conservation" means. And in particular, a very specific notion of what a "conservation law" is. Which this does not follow.

Getting past the name, it's a useful adage. But the name adds unneeded complexity, placing a burden on people who are forced to learn a different intention for a well-understood term.

If the complexity is truly irreducible, is it possible to truly hide it from the user either?

Continuing to handwave, if the system as a whole is something like "user complexity + program complexity >= problem complexity", you can indeed hide it from the user in many cases by pulling it into the program itself. Otherwise, programs would have no utility at all. That's essentially their whole purpose, is to pull it away from the user by putting it in the program.

Probably not, but you are pointing out kind of an oddity in the adage. Complexity should always live on the side of the developer, not the user. Any design choice that says, "We could figure out how to do this, but we didn't, so we'll make the user do it for us" is just outright bad. That's not an adage; that's just an injunction not to be a bad designer.

What's more interesting is that even within the domain of the user space, there is an irreducible complexity. You can push it around, but you can't make it go away. Figuring which users you will inconvenience, how often, and how bad it will be -- that's the artistry.

You can replace a hard disk with a solid state drive, and most users would not notice a thing except it might be a bit faster and less noisy. An enormous amount of complexity is hidden behind a simple interface.

Isn't that the distinction between accidental and essential complexity? A solution cannot be simpler than the essential complexity of the problem, but it can surely be more complex by adding accidental complexity.

This is kind of a word game though. As soon as you find a way to lower complexity it becomes the new essential complexity until someone lowers it again.

Are you arguing there is no such thing as essential complexity? In that case it would be possible to compress any program down to one bit, without moving the complexity elsewhere.

>A solution can not be simpler than the problem.

Problem: (4 primitives)

  1 + 1 + 1 + 1

Solution (one primitive):

If amount of primitives defines complexity you are wrong.

What's going on here is that you are using a different definition of complexity to construct your statement above. Most humans intuitively recognize your statement along with mine.

The issue here is that before we can even talk about complexity we have to come up with a formal definition that fits all forms of our intuition about what complexity actually is. Otherwise all arguments can become circular and pointless as everyone is talking about different things.

What is the formal definition of complexity? What is the thing that is being preserved here?

I disagree with the above.

If you're listing 1 + 1 + 1 + 1 as 4 primitives (I think it's actually more once you include the primitive of addition), I don't think that 4 is the solution. The solution is a written up program that works on any integer that when run this particular sequence produces the value 4. And that solution/program is significantly more complex than 1+1+1+1.

Or alternatively if you say the program can't run on any other values, just that specific one so you can hardcode the result of the program to be "4", then I'd argue there initially aren't 4 primitives. there is one single primitive the entire entity "1+1+1+1" which is equivalent in inherent complexity to the primitive "4". Regardless of how complex we choose to represent it (ie with more characters or fewer), conceptually it's a single "primite" value input and it produces a single primitive value output.

This another definition issue. Traditionally a solution is defined as that expression reduced to the simplest possible form. Your definition of solution is more describing the process of reduction.

How about this. The problem is:

Create a solution that is equivalent in value but has 7 primitives. (Using your definition of "primitive" to include operators).

  1 + 1 + 1 + 1

Under both definitions of "solution" and under my example definition of "complexity" the statement that the solution cannot be simpler than the problem does not hold.

Problems like find every permutation of a string "abcdefg" has solutions more complex than the problem. Disregarding definitions I believe your intuition is a bit off here.

I agree it's a definition issue, but I believe it's your intuition that's steering you wrong. You're using a mathematical definition for a non-math domained problem. The domain of discussion is software. The quote from the article is:

Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?

In this case, I believe it's clear that the "problem" are the provided requirements of the software, and the "solution" is the union of the user's required knowledge, the application complexity and the relevant complexity of platform the app is running.

In this domain, "4" is not a well formed problem. Produce a program that when given "4" returns "4" is well formed. Produce a program that when given any integers and arithmetic primitives produces a reduced value is well formed.

And in both cases the solution/program to produce that is at minimum equally complex as the requirements description (if it were rigorously defined).

Or put in mathematical terms, the proof of a theorem/statement cannot be any less complex than the theorem/statement itself. The closest you can get is a trivial theorem/statement whose proof is of equal complexity to itself.

And back to the original post, it is handwavingly saying that every proof has some level of irreducible complexity. It is either captured in the complexity of poof itself, the complexity of the proof system / axiomatic-system being used or (here is were the analogy breaks down a bit) in the required user's knowledge.

>Or put in mathematical terms, the proof of a theorem/statement cannot be any less complex than the theorem/statement itself. The closest you can get is a trivial theorem/statement whose proof is of equal complexity to itself.

I don't think this analogy is apt. The domain of all problems and all associated solutions which programming covers includes proving theorems but this does not fill the entire set of all problem and solution pairs.

A problem could be: given axiom A and axiom B what are 100 theorems that you could generate that utilizes one axiom or the other or both? This is analogous to my reversal of the addition problem. The solution is not deterministic and is not irreducible.

In your vernacular you use the term well-formed without fully defining it. Intuitively I think by well-formed you mean deterministic and irreducible.

The domain of all problems and solutions includes "well formed" as a subset but encompasses much more than that. Programming is able to generate "1 + 1 + 1 + 1" from 4 and simply because it is 100% possible to write a program that does this, therefore the context of the discussion includes problems and solutions that are not well formed.

Your intuition is wrong in the sense that you believe all problems and solutions have to be "well-formed." They do not.

What you call the problem is actually the specification of the solution, which is the point. What you call the solution is another representation of the solution, but lacks the specification, so you _cannot_ use it to show that it _is_ a solution.

https://news.ycombinator.com/item?id=22378553

> What is the formal definition of complexity?

In re: that question I found "Introduction to Cybernetics" by Ashby to be very stimulating. (PDF freely available from here: http://pespmc1.vub.ac.be/ASHBBOOK.html )

Doesn't P=NP say otherwise? Given the solution, the problem becomes polynomial time to verify. Hindsight 2020

I think the comment was a little tongue-in-cheek -- like FizzBuzz is a problem without much inherent complexity, but you can certainly you make an overly complex solution: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

The solution can sometimes be simpler than the problem, if the problem is redefined so that it isn't as complex. Quite often this is the case when tunnel-visioned on a particular process and focusing on how to do that thing. Stepping back and thinking about why or what the end goal actually is, and then doing something else, is often the only real way to meaningfully reduce complexity.

I think there is another kind of conservation that occurs in our desire for complexity. Something about human natures forces lots of people to feel uncomfortable with giving up control, so we strive to exercise it in other places. Successful platforms, whether they be convenience systems like Netflix or Amazon, or software paradigms have always traded some new interface for unstated (and probably unknown) complexity elsewhere. I think the most apt example these days is probably Docker & K8s and the deluge of systems and tools required to make that all work well in a team setting.

There are other good adages that are worth reading about such as "Ashby's Law of Requisite Variety"[1], and the "Complexity Paradox"[2] which I think can apply generally here, if you synthesize the themes out.

[1] https://www.edge.org/response-detail/27150

[2] https://www.asktog.com/columns/011complexity.html

A good tonic for everyone who wants to simplify the solution by cutting bits off the problem, making a solution which is simple, easy-to-understand, and incomplete. If your program stops doing something, some other program has to do it, and that complexity must be considered as well.

“Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?”

The JavaScript ecosystem is a good/bad example of this. Seemingly simple applications are pushing complexity to thousands of simple npm libraries.

The applications become simpler but the linking and composition of 3rd party libraries gets out of control.

At the core of it; abstractions reduce complexity, but only to a point...

For people who don't know it, please look up "Kolmogorov complexity".

It seems to me that the irreducible complexity of a task is just what the user has to deal with to do it. If the application or platform could deal with that complexity for the user then it was reducible by definition.

No mentioning of the classic from the 70's: Systemantics :-)

https://en.wikipedia.org/wiki/Systemantics

First define complexity formally before attaching the word "Law" to a fuzzy concept.

A more accurate way to frame this is, complexity tends to be conserved. There is no proof or scientific evidence that states that this is a law.

Understanding this is the essence of abstraction.

Simplicity is the ultimate sophistication.-- leonardo da vinci

The idea of simplicity and unity is an important guiding ideology of scientific research. It can be found from the knowledge of various disciplines: the more universally applicable a unified theory, the simpler it is, and the more basic it is, the greater it is.

[The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model ](https://github.com/linpengcheng/PurefunctionPipelineDataflow), based on the philosophy of Taoism and the Great Unification Theory, In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from Lisp language-level code and data unification to system engineering-level software and hardware unification. Whether it is the appearance of the code or the runtime mechanism, it is highly consistent with the integrated circuit system. It has also been widely unified with other disciplines (such as management, large industrial assembly lines, water conservancy projects, power engineering, etc.). It's also very simple and clear, and the support for concurrency, parallelism, and distribution is simple and natural.

There are only five basic components:

1. Pipeline (pure function)

2. Branch

3. Reflow (feedback, whirlpool, recursion)

4. Shunt (concurrent, parallel)

5. Confluence.

The whole system consists of five basic components. It perfectly achieves unity and simplicity. It must be the ultimate programming methodology.

In addition, the IT industry is still a very young and immature discipline. The current software engineering is still at the level of manual workshops. Pure function pipeline data flow brings large industrial production theory and methods to software engineering. It incorporates IT industry into modern large industrial production systems, This is an epoch-making innovative theory and method.

The modern society is an information society, IT controls everything, penetrates everything. In my opinion, the development of IT is exactly the same as the development of modern large-scale industrial production systems. With the development of the IT industry, With the development of the IT industry, data standard systems will be widely established, improved and interconnected at the international, national, industrial and enterprise levels, It will be precisely standardized to every smallest part. pure function pipeline data flow will become the basic theory and Methods have become increasingly important, and have become the ultimate standard method for entering textbooks and industry.

The key to the industrialization of the IT industry is to establish a complete standard system like the traditional industry. software is the pipeline for producing products (data), which is no different from traditional industrial production lines. Therefore, the software production method will adopt enterprise management ideas, develop software into something similar to a traditional industrial assembly line, input standardized raw materials (data), output standardized products (data), and store them in a warehouse (database).

From the perspective of large industrial production theory, standardizing the input raw materials (data) and output products (data) has the following advantages:

- Fairness

- Neutrality

- Fungibility

- Standard, Data standards (data interfaces, data specifications) are better than code interfaces.

- Interconnectedness

- Combination, Data combination is better than code (function) combination.

- Simplicity

- Predictability, because the system architecture and set-up methods are simple and uniform, very clear, so its evolution and direction of development are predictable.

- Reliability

- Unity

- Easy to expand

- Easy to parallel, Can linearly scale up production (performance).

- Observable, easy to debug, and verifiable.

- Clarity, non-IT practitioners can understand.

It can refer to the theory of integrated circuits, business management and other disciplines. The role of the standard system can be seen from the great progress of social productivity after the traditional industry has entered the era of large industrial production from the era of manual workshops.

This method has been applied to 100,000 lines of code-level pure clojure project, which can prove the practicability of this method.

> Simplicity is the ultimate sophistication.-- leonardo da vinci

Doesn't sound like da Vinci. In what context did he state that?

modify:

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

      ---- Alan Perlis, Epigrams in Programming.

           the first recipient of the Turing Award (1966)

           A founding father of Computer Science as a separate discipline

When the solution is simple, God is answering.

Everything should be as simple as possible, but not simpler.

Most of the fundamental ideas of science are essentially simple, and may, as a rule, be expressed in a language comprehensible to everyone.

If you can't explain it simply, you don't understand it well enough.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

      ---- Albert Einstein

           The greatest folk scientist in history :-)

           A professional clerk in the patent office
 
           An amateur physicist

I don't dispute simplicity is a good thing. I'm just wary about fake quotes since it is really a distortion of history.

Simplicity does not mean easy.It is actually a systems engineering.It is difficult to design a complex system into a simple and smooth pipeline system.

Reply on news.ycombinator.com