Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

41–50 of 172 posts

Re: The Danger of “Simplicity”

#41
> 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

Re: The Danger of “Simplicity”

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

Simplicity is often a matter of perspective, a function of a certain perception of a complex subject and the set of expectations that go with this perception. There is no absolute in analysis and in modelling synthetic propositions from the atoms used by the particular analysis.

(E.g., we may analyse and model an action in terms of verb-noun or of noun-verb, with major differences in what may be perceived as "simple" in the respective model.)

Re: The Danger of “Simplicity”

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

Re: The Danger of “Simplicity”

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

Re: The Danger of “Simplicity”

#45
post #40

What’s the point being argued here? Seems to go all over the place. Seems like it’s a rant mainly about semantics.

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.

Re: The Danger of “Simplicity”

#48
post #17

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.

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.

Re: The Danger of “Simplicity”

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

"It is straightforward to show that..." means that you could probably do it with your current knowledge, but it will take 6 dense pages, four false starts and about a week of focused work.
Post reply on HN