Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

91–100 of 172 posts

Re: The Danger of “Simplicity”

#91
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/

The speaker is Clojure creator Rich Hickey, but the talk is about a mental model for thinking about complexity.

Inherent complexity involves tradeoffs.

Incidental complexity you can fix for free.

"And because we can only juggle so many balls, you have to make a decision. How many of those balls do you want to be incidental complexity and how many do you want to be problem complexity?"

The article is about the former. I bet the latter dominates day-to-day line-of-business coding.

Highly recommend the talk, as other have said.

Re: The Danger of “Simplicity”

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

Re: The Danger of “Simplicity”

#93
post #52

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

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…

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.

Re: The Danger of “Simplicity”

#94
post #72

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

> ...concision

Wrapping up important concepts under good names is clearly a good idea. But on the other end of the spectrum, factoring out a single line from 2 methods and giving it a bad name does far more harm than good. Probably 90% of DRY I come across is this bad kind, I would guess because refactoring for better semantic clarity takes much more effort than just factoring out the common stuff under a different name. I think this downside doesn't get nearly enough airtime as it should.

Re: The Danger of “Simplicity”

#95
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/

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.

Re: The Danger of “Simplicity”

#96
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/

Later in the talk, he draws a distinction between inherent complexity (the focus of the article) and incidental complexity (which you can fix without tradeoffs). Tradeoffs can be critically important, but the latter kind of complexity probably dominates my day-to-day life. I find this oddly encouraging, in a free-lunch sort of way.

"And because we can only juggle so many balls, you have to make a decision. How many of those balls do you want to be incidental complexity and how many do you want to be problem complexity?"

Watch the talk.

Re: The Danger of “Simplicity”

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

Re: The Danger of “Simplicity”

#98

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

This is such a well written comment. Often what starts as 'simple' turns into spaghetti complex over time due to the lack of foresight. It's a hard task job and requires a lot of experience to create systems that are simple to understand and to ensure the integrity of the system isn't lost when new things are added on top of them. Foresight into what might be realistically added in future is what seniority enables.

Re: The Danger of “Simplicity”

#99
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/

I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" She really wanted to drill the idea into our heads that just because you know exactly how to do something, doesn't mean that it will be quick or easy to accomplish. Like, for a schoolchild, long division. The rules are simple, but given big enough numbers you'll probably mess up at least once. And th…

https://arxiv.org/abs/0707.4166 is nice

Re: The Danger of “Simplicity”

#100
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/

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

> Simpler is easier than complex, right?

Well, no. Complexity has an obvious price but simplicity does too. You have to work for simplicity, even fight for it. Think of code; it just somehow becomes more complex. You have to work to pare it back to what's needed.

I can't think ATM of better examples (and you deserve some), but no, simplicity does not come easy.

A nice phrase I came across: "elegance is refusal".

Post reply on HN