Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Note on Essential Complexity

olano.dev

Post reply on HN
Print view View original

41–50 of 51 posts

Re: A Note on Essential Complexity

#41

Post by facundo_olano »

worstspotgain wrote: post #27

There's a lot to like in this article, but I would go a step further with its meta-abstractions. At complexity 0, there is no software to be written. In essence, complexity and the software itself are closely related, akin to the relationship between compression and AI. The article's thesis is that minimizing complexity is what engineering is about. That means we're kind of minimizing the total amount of software we…

I really like this metaphor of provisioning architecture and staying clear of dead ends. I'd say dead ends come not just from bad quick design decisions but also from wrong predictions (in the scenario you describe where it's hard to tell what the long term looks like ---which is most of the times).

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

And this matches the No Silver Bullet conclusion.

Re: A Note on Essential Complexity

#42

Post by rikthevik »

tristramb wrote: post #19
smallstepforman wrote: post #11

Complexity builds rockets with thrust vectoring and lands modules on the moon, simplicity is good for fire crackers. Once you scale past simple prototypes, you need performance and new features. And the architecture stops being simple and complexity eventually creeps in. I’ve implented 4 iterations of a product from scratch, and eventually they all get complex, even though each one started out with the goal of being…

The vast complexity of the 21st Century has still not managed to land a single person on the Moon.

> has still not managed to land a single person on the Moon.

How about, "has still not _decided_ to land a single person on the Moon."

Re: A Note on Essential Complexity

#43

Post by lucianbr »

djeastm wrote: post #33
loldot wrote: post #32

Earlier quoted context omitted.

There's a lot of people that like complexity because it makes them feel like they are doing rocket science, but in fact they are replacing a spreadsheet. Most problems on earth do not have the same complexities as those in space. Sometimes the space solution is really nice and simple though, like velcro or using a pencil instead of a fancy pen.

If the problem you're solving isn't sufficiently complex, there's probably already a solution out there and you're re-inventing the wheel.

You're arguing that every single company should be a monopoly, and nobody should ever try to compete with an existing one. Never improve anything either, unless you can do 10 times better, and only if the 10x is very complicated. Makes zero sense.

Re: A Note on Essential Complexity

#44

Post by flakiness »

Dan Luu wrote a piece called "Against essential and accidental complexity".

https://danluu.com/essential-complexity/

Basically what he says is that an essential-looking complexity can be solved by the technical advances.

And I like his take more than the ones that cite this quarter century-old piece as if it were a bible, even if there is a truth in it.

Re: A Note on Essential Complexity

#45

Post by [deleted] »

layer8 wrote: post #5
boznz wrote: post #2

Humans simply cannot keep the whole stack for a complex system in memory, that is why we abstract layers with APIs etc and generally specialize on one layer only. My (Sci-Fi) book postulated that an AGI (a real AGI, after all it was Sci-Fi) would simply discard everything the humans wrote and rewrite the complete stack (including later on the Hardware and ISA) in machine code without anything unnecessary for the task…

While AIs are able to keep more in their “mind” at the same time than humans, there is still a cost to consider (e.g. token limit). If software requires more effort to change (adding a feature, fixing a bug) due to spaghetti architecture, then that will also add to the cost. Secondly, we may want to keep software on a complexity level understandable by humans, in order to not become completely dependent on the softwa…

[deleted]

Re: A Note on Essential Complexity

#46

Post by metadat »

boznz wrote: post #17
metadat wrote: post #6

Earlier quoted context omitted.

I checked out your book link https://rodyne.com/?p=1252 >, is there a preview chapter or two somewhere? That's cool you wrote a compelling sci-fi but my list is competitive :)

I doubt the first two or three chapters will do it justice. I have put a free to download link on the bottom of that page for the complete book as an ePub, I will keep the link valid for a few days. Enjoy.

Wow that's generous and kind of you, thanks!

Re: A Note on Essential Complexity

#47

Post by boznz »

CRConrad wrote: post #35
boznz wrote: post #17

Earlier quoted context omitted.

I doubt the first two or three chapters will do it justice. I have put a free to download link on the bottom of that page for the complete book as an ePub, I will keep the link valid for a few days. Enjoy.

From your page: > I have to buy the sequel, then another, then wait, or in some cases wait forever and hope the author, or I, don’t die before finishing it! So, how old are you -- got burned by A Song of Ice and Fire, or by The Wheel of Time? :-) Oh yeah, and: Thanks for the download!

Those are the ones most people who started reading fantasy in the last century remember. I started reading in 1979 and there are quite a few other good unfinished series out there.

There are also quite a few modern ones which start awesome, then fizzle out into never-ending soap operas once the author realizes they are on the gravy train and those are even more disappointing IMHO.

Books need endings :)

Re: A Note on Essential Complexity

#48

Post by kashyapc »

JonChesterfield wrote: post #25
kashyapc wrote: post #4

A well-written article. On a similar theme of essential vs. accidental complexity: FWIW, I summarised a talk gave by Paolo Bonzini (a Linux/KVM/QEMU maintainer) here in the past: https://lwn.net/Articles/872321/ -- A QEMU case study in grappling with software complexity Although it was in context of QEMU, the lessons from it can be applied to many other projects.

Thanks for this. Lessons from reality hit harder than from theory. I'm amused to learn that the distinction between essential and accidental was first described by Aristotle given that millennia later people are still struggling with the notion.

Yeah, I didn't know it either that it was Aristotle until I started researching for the article! :-)

Re: A Note on Essential Complexity

#49

Post by worstspotgain »

xyzzy_plugh wrote: post #39
worstspotgain wrote: post #27

There's a lot to like in this article, but I would go a step further with its meta-abstractions. At complexity 0, there is no software to be written. In essence, complexity and the software itself are closely related, akin to the relationship between compression and AI. The article's thesis is that minimizing complexity is what engineering is about. That means we're kind of minimizing the total amount of software we…

I like this, but I have trouble with relating architecture to complexity. The "generally" qualifier serves as an apt escape hatch but permit me to ignore that for a moment. 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…

Agreed, and well put. I should have emphasized the role of uncertainty in the architecture/complexity relationship.

In your example, you have a minimum of 4 cabinets. If you start out with N>=4, architecture and complexity are inversely related (to a point of course.) They are sometimes directly related when 1We're predicting the future path of N. Adding a subsystem and a formal internal API when N=1 is being bullish on N, trading the present for the future and expecting a good rate of return.

Re: A Note on Essential Complexity

#50

Post by thomastjeffery »

Programming answers two questions: "what?" and "how?".

The essential complexity is the inherent incompatibility of any given answer. Every answer must be written in a specific implementation. Once you have written your answer, you have cemented it into its environment. We can't answer answers. Technically we can, but it tends to be a huge undertaking.

Each answer to "what?" and "how?" has a special property: it is context-free. We have to choose a specific "context-free grammar" to write it in, but the answer itself can be fully expressed there. That means that every implementation that answers the same question must be somehow equivalent. That equivalence is, unfortunately, lost at time of writing.

---

We need to take a step back, and recognize the ultimate question: "why?".

The very questions "what?" and "how?" belong to the answer to "why?". If we could just write the reason why, we could compile that answer into a complete collection of compatible whats and hows.

That's the trickiest part of all, because the answer to "why?" is context-dependent. We can't write the answer to "why?" in any programming language, because that category of language cannot express context-dependence. That means we can't write a parser for it, let alone compile.

Solve natural language processing, and we solve incompatibility.

Post reply on HN