Hacker News Reader

Comment by bottled_poe | Hacker News Reader

Sorry to be pedantic, but.. Like most articles on this topic, this one fails to distinguish between complex and complicated. Some problems are inherently complex, and attempting to model those in a “simpler” way can actually be a mistake. Complicated software, however, is almost always bad, as it implies that there is room for simplification. Identifying where it makes sense to simplify and where not to is mastery and there are no global rules for how to achieve this, only experience. Software should be as simple as possible, but no simpler.

View on HN

Looking at the dictionary for both words:

https://www.merriam-webster.com/thesaurus/complicated

https://www.merriam-webster.com/thesaurus/complex

... And they literally have the same first definition! Your point is not very clear to me. Can you please help me understand better what you meant here?

In Clojure-land, we always like to distinguish between "accidental" and "essential" complexity as per https://github.com/papers-we-love/papers-we-love/blob/master...

"Accidental" complexity is "your fault" because "you" introduced it into the problem. For example, you need to use some mutable variables and that is making it harder to reason about some code. It would be "simpler" to use immutable values which are closer to pure mathematics and simpler, but you need maximum performance and most hardware is better optimized for mutable state in the extreme case.

"Essential" complexity is part of the problem and can't be reduced away as per current knowledge. For example, you need to know a fair bit of mathematics to be able to understand general relativity.

Complex is used in the sense that you have to consider multiple things (such as constraints, logic, etc) in order to come up with a working solution. You cannot really escape from a complex problem because you have to satisfy all of its needs.

On the other hand, 'complicated' here is probably meant in the sense that you have a solution for your problem, but that might not be the simplest solution to the problem. In other words, you have satisfied all of the problem's needs but the solution itself is going to be hard to understand for anyone other than the person implementing it. You generally want to avoid such situations.

The webster definitions don't mean the same thing because the definitions are overly broad.

If you took another look at that TERRIBLE resource, convoluted and byzantine (and probably more) have the exact same definition. Complicated and convoluted do not mean the same thing.

I agree it does not seem to be the best resource. Do you know of a dictionary that provides better definitions?

Checking the Oxford English Dictionary (https://www.oed.com), and taking the first non-obsolete definition for each adjective:

Complex: Consisting of or comprehending various parts united or connected together; formed by combination of different elements; composite, compound. Said of things, ideas, etc.

Complicated: Consisting of an intimate combination of parts or elements not easy to unravel or separate; involved, intricate, confused.

Thank you for that recommendation!

I was able to access it via my public library login. Very neat.

It's basically inherent complexity and accidental complexity. You have to live up to the first, while try to minimize the latter.

At least that's how I read OP.

I guess a generous reading of "complex" versus "complicated":

Complex - a plain adjective. It's just how the thing is.

Complicated - past tense of the verb "to complicate," used as an adjective. Somebody made this complicated.

But yeah, I still prefer thinking of inherent and accidental complexity. Expresses the actual idea directly.

To not invent new ambiguities I would phrase this succinctly as the solution having intrinsic complexity vs extrinsic complexity.

I think your example of accidental complexity is actually essential complexity. The requirement to use mutable variables and mess with memory is part of the complexity of problem space, not an accident.

Language is not what is written in some dictionary, it is what people use to communicate. I've seen complex vs. complicated distinction (meaning inherent complexity vs. accidental complexity) used in software-related discussions.

Yes, and where to place that simplicity

A DSL is simple to use, but complexity has moved to the compiler

An assembly is complex to use, but the compiler is simple

Part of the answer is in expressivity -- in breaking down problems into simpler, combinable parts. Like Unix pipes or lego

But as expressivity increases, the number of combinations increases and hence complexity itself increases

At one limit atoms are the simplest unit, and programmers can combine them to create any known physical object

At the other limit, we have a one key keyboard that can only do one job and be programmed no other way

Both extremes are extremely simple in their own way, and show us that neither language expressivity, nor even language simplicity is a true savior

To expound:

An emergency shutdown system wants a language comprised of a single big red button

My lunch wants a language of nutrients and flavors for the VM of my tounge and stomach to trigger the happy(); syscall to my brain

-- The best language, and even simplicty itself, must be viewed from both your current position and end goal

Part of the answer is in expressivity -- in breaking down problems into simpler, combinable parts. Like Unix pipes or lego

But as expressivity increases, the number of combinations increases and hence complexity itself increases.

This is first hard lesson learned for those that approach the challenge of achieving simplicity. The first idea one has is ‘I’ll break everything into the smallest little parts’, and suddenly you have a thousand little parts.

Sony products were considered extremely fragile because they were constructed out of tons of small parts. If you dropped it once, every little piece would fall off. Compare that to the Mac unibody.

Nice. I used to think that creating the smallest services, function, methods, etc would produce the easier software to deal with from the programmer perspective. But turns out you will end with many interfaces to keep when perhaps you just needed one

Is there any books that touch in this subject directly?

Reply on news.ycombinator.com