
The Danger of “Simplicity” - emrehan
https://asthasr.github.io/posts/danger-of-simplicity
======
ds_
"Simple is often erroneously mistaken for easy. 'Easy' means 'to be at hand',
'to be approachable'. 'Simple' is the opposite of 'complex' which means 'being
intertwined', 'being tied together'" \-
[https://www.infoq.com/presentations/Simple-Made-
Easy/](https://www.infoq.com/presentations/Simple-Made-Easy/)

~~~
hzhou321
I am yet to appreciate Rich Hickey's now famous "Simple Made Easy". While I
agree with his points, I don't understand the significance of it. Simpler is
easier than complex, right? Even the title said "simple-made-easy". What is
the fuss about emphasizing "Simple is erroneously mistaken for easy"? They are
not the same, but they are intimately related. Or is this an emphasis on
relative vs absolute -- that relative simple can still be relatively not easy?

I don't think I misunderstood Rich Hickey, and I don't think I disagree. But I
don't understand why people quote the opening sentence and feel so significant
for them? To me, that is just a click-bate.

~~~
SuoDuanDao
My takeaway was that if we conflate the two, we tend to use familiar (easy)
tools to solve our problems, but that learning a new tool (hard) could result
in a simpler solution.

E.G, passing something to a legacy program in a language I'm unfamiliar with
from a program I wrote in a familiar language is easier than implementing my
solution in the legacy language, but it's not simpler.

The 'relative vs absolute' seems like a heuristic to distinguish the two.
Writing a solution in a different language is easier _to me_ , but I can tell
on an absolute level that there are more failure points to that approach.

~~~
zmmmmm
Nice explanation. Python is a great example of this IHMO. It is a real
struggle to get the Python programmers on my team to use any other language
than Python.

Why? Because it's easy for them. But the solutions they create with it are
highly suboptimal. They could be far more robust and expressed much more
concisely and directly in other languages with more powerful type systems and
better support for eg: functional concepts.

But they actually really think that because Python is easy for them, that it's
"simple". It's not: it's incredibly complex.

~~~
SuoDuanDao
Haha, I was thinking of that as I wrote it. My first language was C++ back in
the day, then I dabbled in various languages for a while, and finally really
dove into Python because there was a project I couldn't figure out how to
write any other way. If I had to work with one of the languages I learned
earlier, my first instinct would now be to write the solution in Python and
pass it to the legacy program. Perfect example of what the speaker is warning
of.

------
codingdave
The quote of "If I had more time, I would have written a shorter letter" has
been quoted so often that it is arguable who said it first, but it is
definitely at least a 300+ year old concept.

Simplicity takes effort. It takes time. And you often cannot write simple
software in the first version because you are designing it as you go.
Simplicity comes from maturity both in the product design and the development
staff, and is a long term goal.

It is not something that you achieve by critiquing individual PRs, but by
insightful long-term thought into how to solve your problem with your code,
and many refactors over time.

It is wise strive for simplicity in all code you write, but wiser to have the
patience to let it develop over the lifecycle of your product.

~~~
cytzol
> "If I had more time, I would have written a shorter letter"

I don't like seeing this quote in the context of programming.

Sure, they're both about writing, but in different settings. A person who
writes a letter has one goal: for the intent of the letter to be understood by
the recipient. However, a programmer writing code has _two_ goals: not only
for the intent of the code to be understood by future programmers, but also to
make the code _easy to change_ in response to unknown requirements without
causing any regressions.

The article is a bit all-over-the-place, but I do agree with it in general,
because I've seen far more bugs in production caused by _changing_ code than
by _adding_ it. Therefore, I would rather use a language with advanced
features I can use to make my code harder to change in the wrong way. I think
that if you phrase it like that, it makes it more acceptable to "avoid
simplicity".

~~~
karmakaze
I get what you mean but tend to think of them to be so.ilar with in a
different respect--that the concepts being expressed are clear. If the reason
why code is organized by n a certain way is clear along with its effect then
there would not be the motivation to stray from it. The problem is that often
the organization is the result of achieving multiple effects rather than
behaviorial factoring.

------
ken
> For example, dynamically typed languages like Python (or Ruby, Lisp, etc.)
> are easy and pleasant to write. They avoid the difficulty of convincing a
> compiler that you’ve written your code correctly, but they’re harder for a
> new team member to comprehend: you’re trading fluent writing for more
> laborious reading.

I feel like this misses the point of high-level languages. In my experience,
higher-level code is easier to read _and_ write. For one thing, there's simply
a lot less of it.

Lisp isn't more productive just because it's easier to "convince a compiler
that you've written your code correctly". After all, if you haven't written it
correctly, the _user_ will notice right away, too!

> Short functions, methods, and classes are quick to read, but must either be
> built of many lower-level functions or themselves comprise parts of larger
> compositions in order to accomplish anything. You’re trading away locality
> in favor of concision.

That's how languages work. You used the word "concision" rather than spelling
out what it means in tiny words, and count on us readers to know it, or look
it up. That's usually a win, especially if we have a standard set of words.

Again, this is where higher-level languages win big. You can encode higher-
level concepts. I can write MAP or FILTER and people know what they mean. Or
if my language doesn't have those, I can write them.

Just because you can explain something with lots of tiny words does not
necessarily make it easy for anyone to understand:
[https://www.muppetlabs.com/~breadbox/txt/al.html](https://www.muppetlabs.com/~breadbox/txt/al.html)

~~~
thomascgalvin
> _I feel like this misses the point of high-level languages. In my
> experience, higher-level code is easier to read and write. For one thing,
> there 's simply a lot less of it._

High level code shifts the burned of understanding the type system from the
author and the compiler to the reader.

Yes, there is more text to read in a strongly, strictly typed language, but
that extra syntax conveys a _lot_ of important information quickly and
cheaply, and this is information that the reader _will_ need to know.

The difference between:

    
    
        cat( first, second ){ ... }
    

And

    
    
        cat( first: LogEntry, second: LogEntry): void { ... }
    

Is immense. In the later case, I know exactly what this function wants me to
provide, what contracts the arguments must honor, and I know something about
what the function intends to do with those arguments; it's void, so there are
probably side-effects.

In the first case, I have to figure that out by reading the body of the
method. The signature _could_ tell me all of this, but it doesn't.

> _After all, if you haven 't written it correctly, the user will notice right
> away, too!_

My users are not paid well enough to debug my code for me.

~~~
sooheon
What's wrong with:

    
    
        (cat-logs [& entries] ...)
    

If we care about human understanding of the contract, types are no better than
names.

    
    
        reverse :: [a] -> [a]
    
        (reverse [xs] ...)

~~~
asdfasdfasdfa
Names can and do lie, types are checked by the compiler. Also in you example,
is an entry a string? a dict? its own class? who knows.

------
nnq
There was a wise thing along the lines of "to build a simpler system, start
with more powerful (and complex, by necessity) building blocks"... I think it
was Alan Kay who said this or something very similar.

Worst thing is that "simple" languages like Go force you to mix up "business
logic" with "plumbing/infra logic" with "error handling logic" if you try to
be idiomatic... I know that for security crucial code you might want to see
all error paths next to a piece of code, for for the _other majority of the
code_ I want error handling tucked away in different system, and also the
business logic factored out in some other very generic one that doesn't care
about actual implementation of infrastructure.

Sure, if _infrastructure IS your very product_ like Go's use case probably is,
then it probably makes sense to not have features for such separation.

~~~
Kye
I experienced a good example of this recently when trying to decide between
Bitwig and an upgrade of Ableton Live Lite to Suite.

Suite comes with a full-featured audio programming environment called Max for
Live. It has some high level devices for common functions, but you can go very
low level and make just about anything. The building blocks are all very
simple and basic: oscillators, math functions, routing, etc.

Bitwig's Grid takes a different approach with a small number of powerful
building blocks. The range of possibilities is smaller, but you can be more
productive if the thing you want to make is composable from the available
devices.

------
Kalium
I once worked on a system where the senior engineer on the project had a
dogmatic definition of simple.

It was an MVC web application. He insisted that having any form of flow
control or logic in views was too complex - it was simpler to regard all logic
as application logic and put it in the controller. This meant that instead of
one controller being able to drive multiple views, something as
straightforward as rendering a table a row at a time required a dedicated
controller action.

That engineer's definition of simplicity produced an explosion of complexity
in the codebase. That was when I came to understand that hand drills may be
simple, but power drills are _very_ useful.

~~~
tabtab
Yip, I've also encountered "architects" who obsess on certain things, and make
a mess in the process, at least something that is a "mess" to the majority of
coders.

One is left with a dilemma of complain harder or leave. Unfortunately, leaving
is probably the only way out. Often such people have "connections" and are
thus not correctable. They have outlier minds and want a system that models
their outlier brain even if multiple developers complain. Bail out.

------
brlewis
The article refers to "the much-abused YAGNI" and links to another blog post
that goes into detail. Apparently some people take YAGNI to mean never
anticipate anything. Is that your experience? I've always taken it as a tie-
breaker when you're unsure whether to anticipate or not, and I've had the
impression that others take it the same way.

Overall I like this article and the YAGNI one it links to.

~~~
ninkendo
I take YAGNI to mean not developing abstractions until you have enough use
cases to back them up.

If you don't have a reason _now_ to make an abstraction, don't do it yet. Wait
until you have at least 3 use cases where you're repeating yourself before you
come up with an abstraction that collapses them. You'll know better what the
right abstraction will be once you have those use cases... any abstraction you
come up with now is much more likely to be wrong. And a wrong abstraction is
much worse than repeating yourself.

Of course, if this is the umpteenth time you've done the same CRUD app that
wraps a relational database, go ahead and use the abstractions you know worked
before, because in that case, you've already seen the use cases before and you
have a better idea of what abstractions will work.

~~~
brlewis
[https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

------
anoplus
I think the confusion around simplicity is in what terms a thing is simple.

For example, 2 pieces of text can be simple in 2 different ways:

First text is long but uses fewer words in vocabulary. So it is "simple" in a
sense you need to learn only few words to read it.

Second text is short but uses richer vocabulary to describe things with fewer
words (syntactic sugar). It is "simple" in a sense you only need few words to
describe stuff, but more "complicated" because you need to learn more words.

"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to
implement.

~~~
collyw
>"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to
implement.

I was thinking something similar recently.

Good code should take the next developer less time / effort to understand it
than it took the original developer to write it (assuming similar levels of
ability).

~~~
bonoboTP
> the next developer

And that's often you, just in a few months' time.

~~~
collyw
True.

And as I mentioned in another comment, I learned the most by building a system
from scratch and maintaining git for 4 and a half years. If I couldn't
understand a bit of code that had written more or less straight away, then it
was usually time to refactor it.

------
api
Go's parsimony is about cognitive load. I've programmed for 30 years and am an
expert in complex languages like C++. I find that when I write Go my mind
spends far more time thinking about the problem than the language, which I
like.

The language is modern and powerful enough to spare the programmer from some
of the worst drudgery (unlike C) and is much more inherently safe, but it's
not a jungle gym of complicated constructs and difficult quasi-mathematical
concepts that (while interesting) detract from the task at hand.

------
ashton314
If Buttercup and Westley from _The Princess Bride_ were working on software,
the conversation might have gone something like this:

Buttercup: I balk at your complexity! Westley: Software is complexity! Anyone
who says otherwise is selling SaaS.

------
pron
> The complexity of software is an essential property, not an accidental one.
> Hence, descriptions of a software entity that abstract away its complexity
> often abstracts away its essence.

\- Fred Brooks, _No Silver Bullet_ , 1986

> Complexity _is_ the business we are in, and complexity is what limits us.

\- Fred Brooks, _No Silver Bullet Refired_ , 1995

------
breck
> The problem with these approaches is that “simplicity” never gets a rigorous
> definition

Last I counted there were 48 proposed methods of defining simplicity. I
created one as well and am biased and think it is the best way to rigorously
define simplicity/complexity:
[https://github.com/treenotation/research/blob/master/papers/...](https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.pdf)

------
Kivutar
"Perfection is achieved, not when there is nothing more to add, but when there
is nothing left to take away."

By simplicity, we mean frugality.

If you can implement something without adding a ton of dependencies,
abstraction layers, and design patterns, it will be easier to understand and
debug.

YAGNI is everything but abused.

------
csours
One analogy I like for software problems is knotted string. You approach the
problem, loosen some things up, try some approaches, and sometimes you get
lucky and shake things loose.

Other times, you have to cut the string and you lose fidelity in your
solution.

Other times, you can only move the problem around so it looks simple to the
user; there's still a knot there, but it may be hidden in the back end.

This isn't the only analogy, and it's incomplete, but I still like it.

------
kerblang
I classify easy/hard as

1) Concise vs. Verbose 2) Straightforward vs. Confusing 3) Flexible vs.
Inflexible 4) Efficient vs. Inefficient

The important thing about these 4 is _they get along horribly_. The most
concise solution is often confusing, inflexible, and/or inefficient in many
respects. I should also note that straightforward-confusing is the hardest one
to measure objectively.

------
mbostleman
The two perspectives that I often find at opposite poles when proposing
simplicity is that of the developer vs. that of the user. Generally what's
simple for the user drives less simple solutions for the developer and vice
versa. It's not always possible, but when it is, I strive to find the solution
that ends up being dead simple for both.

~~~
hinkley
I really noticed this when I caught business folks conflating the two.

Often the more easily you can describe the situation, the more code it takes
to make it Just Work.

Simple for the user is harder for me.

~~~
mbostleman
Exactly

------
haolez
I’m starting to think that I’m in the minority that agrees with most (if not
all) Go’s design decision and appreciate Rob Pike’s stewardship so far.

~~~
cytzol
I'm in the opposite camp from you — I like generics, lack of null, and syntax
highlighting — but that's fine! I don't think this is something we have to
'agree' or 'disagree' with. It simply means that you're within Go's target
market. If you want to use a simple language, and the software you're writing
works just fine without these features in your code, then of course it's OK to
jettison them and stick with the simple language. I need those features
because of the software I write, so I need to stick with a more feature-ful
language.

Acting like there needs to be some 'one true way' when we're writing
completely different pieces of software is how pointless internet arguments
get started.

~~~
meddlepal
The problem is not all of us get to choose the language we work in and
sometimes someone picks a language for all the wrong reasons and then you're
stuck with it because a rewrite is costly and usually not an option.

So these debates do have some merit.

~~~
cytzol
You're right, and that is unfortunate. But "people sometimes make the wrong
decisions" is a much tougher nut to crack!

I agree that we should have these debates — but on a "is this language
acceptable for my use case" level, not a "is this language acceptable for
_any_ use cases" level.

------
panpanna
Let me answer this once and for all:

> What are we optimizing for?

You mean who are we optimizing for. For the guy who has to understand and
maintain this code 2 years from now. (This guy could in fact be you yourself).

Thats why I like Go. And C, now that I think about it...

~~~
ken
I agree with the first part -- which is why I _don 't_ like low-level
languages like C.

I can't count the number of times I've encountered old C code that uses
pointers and bytes and arrays, and I discover a bug, and on further inspection
I can't even figure out what they were trying to do. It's all just pointers
and bytes and arrays. The language is too low-level to encode _intent_ ,
except at the lowest level, so you're putting all your trust in comments.

~~~
clarry
Functions are the basic abstraction in C. They are good for describing intent.
Likewise, structs are good for giving pointers and bytes meaning.

Pointers and bytes and arrays are the least of all my problems in dealing with
old C code.

------
kyancey
I agree with the author that the simplicity of learning the language is not
the only type of simplicity. There are other types of simplicity like the
simplicity of how consistent the language is. For instance, I've felt for some
time that Python has become too complex. I started out quite simple, and there
are now like 3-4 different ways to write a method signature.

------
sytelus
Steve Jobs created many things and also destroyed a many. One of them is the
openness of platforms and another is what I'd call _delightful complexity_.
Simplicity is not always a joy and lot of overjealous wanna-be-Jobs seem to
forget about that. I do want all those buttons and choices in my music app
that let's me be expressive and opiniated about my taste. And I definitely
want generics!

A bigger issue is that a many times simplicity for you is not simplicity for
others. This often comes back to haunt you in software design. You might think
that complex design is not good for you and you may strive to simplify
internals even though it might make life awkward for users of your creation. I
feel a lot of such decisions have been made in designing Go. Overjealous
pursuit of simplicity has led its designer to keep compiler less complex,
internally beutiful and work of art but at the expense of external usability
for its users. This article captures the sentiment pretty well.

------
starbugs
I don’t think it’s a good idea to introduce complexity to the definition of
simplicity and I think this is what the author is trying to do.

It’s completely backwards. The whole point of calling for simplicity is to
make you think about whether there is a simpler way to express yourself that
still solves the problem at hand. This might be a hard task, but it’s not a
complex one.

------
nottrobin
I think this piece risks being interpreted as saying that simplicity is not
important.

The fact that simplicity is hard to achieve will be obvious to anyone who has
ever truly tried to achieve it.

Personally I would worry far more about people thinking simplicity is a fools
errand and so not trying hard enough to achieve it, rather than people
thinking it might be easier than it is.

------
ftvy
TFA seems to build upon confusion of how "simplicity" is defined.

It's easier to compare it against "complexity" which is the sum of parts; e.g.
a complex machine, so "simplicity" must be attributed to an atomic design of
"the smallest part which cannot be broken any further"; i.e. think of a simple
machine like a lever.

~~~
mbrock
I think Ousterhout’s pragmatic definition of complexity is the best one when
discussing actual code bases: complexity is anything that makes the system
hard to change, taking into account how often the relevant part needs to
change.

~~~
frou_dh
Hard to change is subjective. Maybe something you found hard to change, your
colleague would have no trouble with. And vice versa.

~~~
mbrock
Yeah, with this definition, complexity is something you notice as a working
team, not something you can directly measure with syntactic criteria (of
course syntactic criteria may correlate with the complexity).

------
Roark66
I'm usually in favor of the good old KISS principle, but I've experienced few
situations where "simple" ready made solutions were chosen on the basis of few
demos showing "how simple it is to use this or that feature" over writing in-
house scripts in general purpose language like python. In all of those
unrelated situations there was trouble later when it transpired that indeed it
is simple to use feature A, B and C that works exactly as original author's
wanted, but the moment you want to tweak something manipulating the whole
thing is terribly inefficient, and/or complex. In the end tweaking those
simple ready made solutions required more work than re implementing the whole
thing from scratch would take in the first place...

------
ajbonkoski
I would define simplicity as "the approach that minimizes cognitive load while
meeting all other objectives"

I would hope that people with the same objectives would agree on simplicity
for that domain.

Examples:

Need a lot of machine control, direct memory control (page alignment, cache
alignment, shared memory, numa, etc) interact with system calls directly,
interact with hardware, and security is not important in the domain (e.g.
private hpc cluster behind a firewall)

C is probably the simplest

Need to quickly prototype something medium sized that involves non-trivial
data structures or needs to interact with an http server. And you don't care
about performance.

Something like Python is probably simplest

Etc etc etc

By contrast.. try doing the former with Python, Java, etc and see how much
additional cognitive load you have to add.. ever try the later with C.. no
fun.

~~~
zmmmmm
> I would define simplicity as "the approach that minimizes cognitive load
> while meeting all other objectives"

That's one dimension of simplicity, but it doesn't take into account some of
the other benefits of simplicity, such as, eg: robustness. Another definition
would be "the approach that minimizes the total number of possible
interactions" (akin to "moving parts" in a physical machine). In that sense,
the fewer total possible interactions, the fewer places something can break.
There might be MORE cognitive load to a human in direct sense, but the system
is far more constrained to only do the "right thing".

I sometimes think of the generalization of it being "the approach that
minimises the total state space of the system, including the brain of the
human trying to understand it".

------
BenoitEssiambre
I like to take an information theoretic, model-problem fit stance on
simplicity. It's useful to reason about it in terms of overfitting vs
underfitting, over-abstraction vs under-abstraction, high resolution fit vs
low resoltion fit, and in terms of cross entropy between the knowledge
embedded into a software system and the information relevant to solve the
corner cases of the problems ([https://medium.com/@b.essiambre/product-market-
crossfit-c09b...](https://medium.com/@b.essiambre/product-market-
crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667)).
Well tuned knowledge is not an easy thing.

------
z3t4
My take on simplicity is how strong the abstraction layers are. Using a web
framework to show "hello world" versus making a video card driver and make it
show "hello world" on the screen.

A world class athlete makes something hard look easy. So just because the code
looks simple, doesn't mean it is easy.

Remember when you first learned how to code, or learned some new concept, and
now you can't remember what was so difficult about it?

Just one line of code might touch several computers, hardware components, with
several software layers. Everything has to go right, all the way down to
atomic level. Nothing is simple. It just appears to be simple through strong
abstraction layers.

------
carapace
Recognizing simplicity requires familiarity with complexity.

\- - - -

FWIW, Category Theory provides a mathematical formalism for determining when
your system is "as simple as possible, but no simpler".

\- - - -

> “average programmers” have difficulty understanding complex languages

That's not pejorative IMO, that's practically tautological: If "average
programmers" have difficulty understanding a language, isn't that an indicator
that it might be too complex? Anyhow, trawling though e.g. Stackexchange
provides adequate evidence, IMO. Or a thread about Haskell with all the people
complaining about how hard it is to understand FP, etc.

------
tabtab
There are several key "rules of thumb" to keep in mind, and they are often
contradictory. Knowing how to weigh them well against each other takes
experience in both the domain and IT in general.

Another rule of thumb to add is "don't obsess on a _single_ rule of thumb;
they are all important."

In my experience "keep it approachable" often overrides "less code" and DRY.
Maintenance staff changes and you probably cannot control the quality of the
next maintainer such that if your code requires an abstraction guru to figure
out, you may put your org in a difficult spot.

~~~
gambler
_> There are several key "rules of thumb" to keep in mind, and they are often
contradictory._

Rules of thumb in software engineering is bullshit masquerading as wisdom.
Don't keep them in mind. They will hog your cognitive bandwidth which you
could use to actually reason about problems.

Real engineering involves balancing tradeoffs. To balance them, you need to
understand what they are. Sloganistic "rules of thumb" do not help with that
at all.

For example: YAGNI. "Your ain't gonna need it." It could be used to advocate
for deferring a decision for which you don't have enough info _or_ it could be
used to advocate for ignoring a critical design flaw that's guaranteed to bite
you in the ass later on.

Good engineers don't spew out slogans. They explain their reasoning.

~~~
tabtab
Re: "For example: YAGNI. "Your ain't gonna need it." It could be used to
advocate for deferring a decision for which you don't have enough info..."

Another rule of thumb is "know your domain".

Re: "Good engineers don't spew out slogans. They explain their reasoning."

That is true, but it's also good to have summary reminders. People won't
remember most 2 hour lectures unless refreshed over time, and rules of thumb
are one way to do this without re-attending the same 2 hour lecture over and
over. In the ideal world they'd re-attend the full lectures (or close to) to
get a refresh, but that's not the way most humans do things.

------
gatestone
"There are two ways to design a system: make it simple enough to be obviously
right, or make it complex enough not to be obviously wrong" \-- Charles Hoare

------
theaeolist
Simplicity cannot be a goal in itself. Is the dashboard of a F35 worse than
the dashboard of a car -- because it's less simple? It's the same thing with
programs and programming languages. Computers are universal devices, they can
be F35s or just basic cars. The important thing is 'fit for purpose', which is
more elusive and not so amenable to simplistic ideological statements.

~~~
chasd00
i can't remember the author but there was a disucssion on usenet about comm.
protocols years ago and someone said "it's not finished when there's nothing
left to add, it's finished when there's nothing left to take away". To me,
that's what simple means and i think it also equally applies to "fit for
purpose". A perfect fit for purpose is an implementation with nothing left to
take away. I feel like when you someone sees a perfect fit for purpose they
would also think "this is really simple" whether it be an F-35 dashboard,
nuclear reactor control room, or the controls on a lawn mower.

edit: after thinking about this for a few min. there's larger than normal
holes in my point heh. However, i really like OPs point.

------
lurker5000
Here's a few more if anyone is compiling a list:

Dieter Rams -- [https://www.vitsoe.com/gb/about/good-
design](https://www.vitsoe.com/gb/about/good-design) John Maeda --
[http://lawsofsimplicity.com/](http://lawsofsimplicity.com/)

------
lurker5000
Here's a few more if anyone is compiling a list:
[https://www.vitsoe.com/gb/about/good-
design](https://www.vitsoe.com/gb/about/good-design)
[http://lawsofsimplicity.com/](http://lawsofsimplicity.com/)

------
kresten
What’s the point being argued here? Seems to go all over the place.

Seems like it’s a rant mainly about semantics.

~~~
brlewis
I took the point to be that there isn't always a clear "simpler" way to
implement something, and that when someone is hesitant to accept what to you
is the obvious simple solution, listen to their concerns.

Mainly this comes from the 2nd paragraph.

------
EricE
Heh

“I apologize for such a long letter - I didn't have time to write a short
one.”

― Mark Twain

------
austincheney
Simplicity is objectively measurable. Here is a practical suggestion, though
directly applied to mechanical engineering is readily adaptable to application
design.

[https://www.sciencedirect.com/science/article/pii/S235197891...](https://www.sciencedirect.com/science/article/pii/S2351978918302361)

One way to think about simplicity is to accomplish the greatest number of
business objectives with the fewest number of abstractions. As others have
said, that isn't easy. It takes increased effort to achieve simple.

~~~
sabas123
The metric chosen here is still arbitrary, why would the number of interfaces
be more important than the number of the amount of interconnected interfaces?
It is still subjective and hence simplicity is still subjective too

~~~
austincheney
When a metric is quantifiable with numbers it is objective. It may not be the
best tool for the job or even valid at all, but it is still objective.

Subjectivity, on the other hand, means to prioritize a content or bias above
its measures.

~~~
sabas123
The problem is that no matter which metric you choose, I can pick another one
leading me to have opposite outcomes in a manner that you cannot argue with.
The importance of your objective metric will still be subjective based on how
important I think each metric system is. Making the entire thing subjective.

~~~
austincheney
You are confusing cause and effect. The measure itself is the objective part.
What you do or what you believe from that number is the subjective part.

If objectivity were important to you then you would use _many_ measures.

------
divan
There is a lot of noise in the article (like mentioning Rob Pike's take on
syntax highlighting), but mostly it seems to be a "I like Rust and Haskell,
and don't like Go" type of articles. Could've been a single tweet.

Attempt to explain the dangers of simplicity is lost in vague sentences like
"Rust has different concept of simplicity -> Rust authors wanted to protect
from memory errors" or TBU (True But Useless) phrases like "every choice has a
cost"/"everything is a tradeoff".

~~~
jolmg
> mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of
> articles

The mentions of Rust, Haskell, and Go are limited to a single section of the
article, so I'm not sure what you're talking about. Most of the article seems
to stay abstract with concrete cases brought as examples.

~~~
divan
I might be biased, as I had to read every Go rant back then when writing a
"How to complain about Go" article, and this is clearly the same narrative.

Author did a good job to hide it, but if you look closer you'll see indirect
Go mentioning throughout the whole article:

\- "“What do you mean, you think Go’s error handling is bad? It’s simple!”"

\- How can we articulate a position more powerful than “syntax highlighting is
juvenile?” <\- refers to the Rob Pike's opinion about syntax highlight

\- "Go’s error handling has become a meme,"

\- "The creators of Go have said, sometimes in pejorative terms,1 that
“average programmers” have difficulty understanding complex languages,"

\- "It’s inflammatory, but the article “Why Go’s design is a disservice to
intelligent programmers” is worth reading just for the quotes from Rob Pike."

------
teucris
quote of the month: “Code, in itself, is not an asset. A solved problem is an
asset.”

------
slowenough
The link about Go with quotes by Rob Pike lets me think that maybe Abc.xyz
made Go like they did because they wanted to be able to have some sort of AI
generate code eventually.

------
tw1010
Thought this was gonna be a cybertruck jab.

