Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

Post reply on HN
Print view View original

61–70 of 172 posts

Re: The Danger of “Simplicity”

#61

Post by cytzol »

meddlepal wrote: post #54
cytzol wrote: post #48

Earlier quoted context omitted.

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

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.

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.

Re: The Danger of “Simplicity”

#64

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

Re: The Danger of “Simplicity”

#65

Post by ninkendo »

brlewis wrote: post #38

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.

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.

Re: The Danger of “Simplicity”

#66

Post by collyw »

codingdave wrote: post #12

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

Agreed. I learned the most working with a system I built from scratch and managed for 4 and a half years. You can't blame other people when you have built it yourself. You see what areas of code constantly needed updating, and where you could have improved the design. With any luck you will be given enough time to refactor it and improve it.

Re: The Danger of “Simplicity”

#67

Post by loquor »

ds_ wrote: 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/

On a related note, the late Patrick Winston strongly states in his MIT AI Course that simple is not the same as trivial. Simplicity is powerful.

Simple points may sound trivial and obvious, but simple things can add up to make something magnificent.

Re: The Danger of “Simplicity”

#68

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

Re: The Danger of “Simplicity”

#69

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

Re: The Danger of “Simplicity”

#70

Post by pixelrevision »

ajdegol wrote: post #9
ds_ wrote: 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.

Was 100x for me. My boss unfortunately did not agree with me.
Post reply on HN