Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

21–30 of 172 posts

Re: The Danger of “Simplicity”

#21
post #14
post #8

Earlier quoted context omitted.

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...

Simple systems can indeed be made of complex components; however it is a measure of interconnectedness. The key concept is that we can only hold a finite amount of complexity in our heads at any one time, and so if we can minimise that we can be more efficient and effective. The analogy is a lego castle vs a wool castle. A lego brick is very simple and contained, and from this you can build wonderful structures; in a…

And the Lego analogy works in particularly nicely considering just how much effort, precision and design work needs to go in to making the blocks simple [0]. This is a nice analogy for how keeping software components simple and making them interface cleanly is a difficult task.

[0] https://en.wikipedia.org/wiki/Lego#Design

Re: The Danger of “Simplicity”

#22
post #7

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 wor…

I don't think there is a confusion around simplicity. It just seems like strawman blog filler and this article is no different.

Re: The Danger of “Simplicity”

#23
post #3

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…

> error handling tucked away in different system I'm not sure that can ever be done. I agree Go could use some syntactic around error handling but I think even modern software is incredibly flaky and Go is a step in the right direction.

It's tiring to think about all the failure cases but it might lead to a world where the ATM gives me money instead of Windows BOD.

Re: The Danger of “Simplicity”

#24
post #7

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 wor…

What you are describing here is approaching usability. And when it comes to usability simplicity doesn't matter on its own, there are four other things to always keep in mind together with simplicity: consistency, flexibility, universality and familiarity. And then understanding what users need your piece of text for applying those concept to come up with the best balance to make users think and learn as little as possible throughout the whole lifecycle of the use.

Take, for example, familiarity. If you use a richer vocabulary that your users already familiar with, they certainly wouldn't need to learn more words and the piece with richer vocabulary would be easier for them to go through, than the longer piece with poorer vocabulary.

Simple doesn't mean more usable, but it's a pretty straightforward concept to understand, there is no confusion around it.

Re: The Danger of “Simplicity”

#25
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.

Re: The Danger of “Simplicity”

#26
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.

Re: The Danger of “Simplicity”

#27
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...

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.

Re: The Danger of “Simplicity”

#28
post #9
post #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/

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.

>watching it will make you a 10x better programmer.

That sounds wrong. Can we drop this rhetoric?

Re: The Danger of “Simplicity”

#29
post #9

Earlier quoted context omitted.

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.

>watching it will make you a 10x better programmer. That sounds wrong. Can we drop this rhetoric?

It's obviously hyperbole.

Re: The Danger of “Simplicity”

#30
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...

Post reply on HN