The Danger of “Simplicity”
asthasr.github.io
The Danger of “Simplicity”
1–10 of 172 posts
Re: The Danger of “Simplicity”
#2TFA 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.
Re: The Danger of “Simplicity”
#3There 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.
Re: The Danger of “Simplicity”
#4TFA 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.
I’ve actually been writing a post about just this concept. When I think simple, I think solving the problem in a way that adds value and doesn’t have unnecessary overhead. I think it’s important to highlight the differences between simple, complex, and complicated (like from the Zen of Python). The basic idea is that if possible you want a simple program, but most problems aren’t that’s simple. So the solution needs to be complex with lots of parts. Those parts can and should be simple though. Complicated means adding things that don’t any value. Maybe it’s using containers on a CRUD app that doesn’t need it because it looks good on a resume.
Re: The Danger of “Simplicity”
#5"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/
Re: The Danger of “Simplicity”
#6TFA 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.
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.
Re: The Danger of “Simplicity”
#7I 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.
Re: The Danger of “Simplicity”
#8"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/
wouldn't say simple is the opposite of complex though? especially when talking about software systems or other systems in general. what i am thinking is that some complex systems can be made of very simple components.
the best example is our complex brain being made of simpler components working together. maybe the opposite of complex is chaotic? i don't know...
Re: The Danger of “Simplicity”
#9"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/
If you haven't seen this talk; watching it will make you a 10x better programmer. This is what I take for my definition of complex and it applies broadly in a very practical manner.
Re: The Danger of “Simplicity”
#10I 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 wor…
>"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).