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

161–170 of 172 posts

Re: The Danger of “Simplicity”

#161

Post by sullyj3 »

rubinelli wrote: post #79
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.

It is easy to look back and say, "I should have made this modular," or "I should have isolated that external dependency." It is easier to see how another level of indirection would have saved you work after the fact, but maybe YAGNI was the right call at the time. That's the trap that Magic and poker players call results-oriented thinking: You got burned once by making the best decision available given the informatio…

When you look back, you're looking back from the particular world where X became a requirement. If instead, Y had become a requirement, you would be looking back wishing you had structured your code in some completely different way. YAGNI then applies to the extent that you can't predict which of X and Y it will be in advance.

Re: The Danger of “Simplicity”

#162

Post by sytelus »

Steve Jobs created many things and also destroyed a many. One of them is the openness of platforms and another is what I'd call delightful complexity. Simplicity is not always a joy and lot of overjealous wanna-be-Jobs seem to forget about that. I do want all those buttons and choices in my music app that let's me be expressive and opiniated about my taste. And I definitely want generics!

A bigger issue is that a many times simplicity for you is not simplicity for others. This often comes back to haunt you in software design. You might think that complex design is not good for you and you may strive to simplify internals even though it might make life awkward for users of your creation. I feel a lot of such decisions have been made in designing Go. Overjealous pursuit of simplicity has led its designer to keep compiler less complex, internally beutiful and work of art but at the expense of external usability for its users. This article captures the sentiment pretty well.

Re: The Danger of “Simplicity”

#163

Post by renox »

cytzol wrote: post #56
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,…

> "If I had more time, I would have written a shorter letter" I don't like seeing this quote in the context of programming. Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has two goals: not only for the intent of the code to be understood by future programmers, bu…

>> "If I had more time, I would have written a shorter letter" >I don't like seeing this quote in the context of programming.

Maybe you're overthinking it? Just yesterday I delivered a temporary fix with copy/pasted code inside because I didn't have the time to make the 'correct' code..

Re: The Danger of “Simplicity”

#164

Post by radicalbyte »

coldtea wrote: post #46
radicalbyte wrote: post #32

Earlier quoted context omitted.

It needs to be rephrased into this: "Watching this video will make you into a developer who is respected 10x more by their peers."

Would it?

No it's hyperbole.

However if you go from writing spaghetti code to something more structured (i.e. loosely coupled, however that is expressed in your language) then you're team mates will hate you less.

Re: The Danger of “Simplicity”

#165

Post by SuoDuanDao »

zmmmmm wrote: post #148
SuoDuanDao wrote: post #125

Earlier quoted context omitted.

My takeaway was that if we conflate the two, we tend to use familiar (easy) tools to solve our problems, but that learning a new tool (hard) could result in a simpler solution. E.G, passing something to a legacy program in a language I'm unfamiliar with from a program I wrote in a familiar language is easier than implementing my solution in the legacy language, but it's not simpler. The 'relative vs absolute' seems l…

Nice explanation. Python is a great example of this IHMO. It is a real struggle to get the Python programmers on my team to use any other language than Python. Why? Because it's easy for them. But the solutions they create with it are highly suboptimal. They could be far more robust and expressed much more concisely and directly in other languages with more powerful type systems and better support for eg: functional…

Haha, I was thinking of that as I wrote it. My first language was C++ back in the day, then I dabbled in various languages for a while, and finally really dove into Python because there was a project I couldn't figure out how to write any other way. If I had to work with one of the languages I learned earlier, my first instinct would now be to write the solution in Python and pass it to the legacy program. Perfect example of what the speaker is warning of.

Re: The Danger of “Simplicity”

#166

Post by chrisweekly »

hzhou321 wrote: post #134
chrisweekly wrote: post #130

Earlier quoted context omitted.

The way I see it, when there's already a lot of complexity inherent to the domain (eg, software design), it's nearly always much easier to add to the complexity than to find a way to reduce it.

Your answer makes sense and is illuminating. It is not easy to keep it simple. The problem here is not that "simple is not easy", it is rather "picking partial and sacrificing/neglecting whole". Since one is only part of a team and a part of the whole design/develop/use circle, the "whole" problem is not (necessarily) "my" problem, therefore it is easy to pick a simple and easy solution from "my" perspective. The "my…

Good points!

"Parts:whole"?

That's where "local complexity : global simplicity" tradeoffs come into play; well-defined boundaries (coherent interfaces) are key to striking the right balance.

"Now:future"?

Yeah, YAGNI (You Ain't Gonna Need It") and STTCPW (Simplest thing that could possibly work) are good rules of thumb.

Finally, as for "not my problem"?

IMHO (and IME, 21yrs in the industry), that's a dangerously myopic stance. Those who make the effort to expand their perspective beyond the scope of their immediate tasks and responsibilities are those whose skills, powers, value and influence show commensurate growth. By all means, be a good team player and do your (current) job to the best of your abilities, which includes efficiency and ergonomics and awareness of available shortcuts. But if you do this for too longbe aware of the compounding effects, not only on the larger system's technical debt, but also the limits this may be placing on your career.

Re: The Danger of “Simplicity”

#167

Post by MaxBarraclough »

Ma8ee wrote: post #49
leggomylibro wrote: post #18

Earlier quoted context omitted.

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.

Like the joke about writing math textbooks.

Forgotten the proof? Not a problem. The proof of this is elementary and is left as an exercise for the reader.

Re: The Danger of “Simplicity”

#168

Post by sabas123 »

austincheney wrote: post #73
sabas123 wrote: post #58

Earlier quoted context omitted.

The metric chosen here is still arbitrary, why would the number of interfaces be more important than the number of the amount of interconnected interfaces? It is still subjective and hence simplicity is still subjective too

When a metric is quantifiable with numbers it is objective. It may not be the best tool for the job or even valid at all, but it is still objective. Subjectivity, on the other hand, means to prioritize a content or bias above its measures.

The problem is that no matter which metric you choose, I can pick another one leading me to have opposite outcomes in a manner that you cannot argue with. The importance of your objective metric will still be subjective based on how important I think each metric system is. Making the entire thing subjective.

Re: The Danger of “Simplicity”

#169

Post by collyw »

bonoboTP wrote: post #118
collyw wrote: post #10

Earlier quoted context omitted.

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

> the next developer And that's often you, just in a few months' time.

True.

And as I mentioned in another comment, I learned the most by building a system from scratch and maintaining git for 4 and a half years. If I couldn't understand a bit of code that had written more or less straight away, then it was usually time to refactor it.

Re: The Danger of “Simplicity”

#170

Post by tabtab »

ken wrote: post #153
tabtab wrote: post #114

Earlier quoted context omitted.

Re: "Lisp isn't more productive just because..." Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates: https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?GreatLispWar I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "r…

Do you mean the first question literally? My salary has never been well correlated with my productivity. Figuratively, in the sense of "if Lisp allows you to be so concise, why aren't your programs small?", I can report that in every case where I ported a program to or from Lisp, the Lisp version was significantly shorter than the non-Lisp implementation. So I'd say, "it is". As for whether I'm just an amazing progra…

Re: "My salary has never been well correlated with my productivity."

I'm thinking more from the owner's perspective. If they hired a bunch of Lisp programmers, then they'd produce more software with fewer programmers (if the productivity claims were correct). They'd then get rich and expand, and other companies would take notice and copy.

Re: "I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it."

There seem to be niches were it works out well, but it has stayed niches since the invention of Lisp. After 50+ years of not catching on in the mainstream, you have to wonder about real-world market fit.

Re: "I find C (and imperative languages in general) harder to write and debug."

C is a relatively low-level language, mostly designed for hardware speed instead of programmer speed. Thus, it's not the best specimen of imperative languages to compare with.

But in general such seems to be subjective: people give widely varying anecdotes. Those who like Lisp dialects gravitate toward them and those who don't go elsewhere.

Post reply on HN