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

131–140 of 172 posts

Re: The Danger of “Simplicity”

#131

Post by Dylan16807 »

thwarted wrote: post #77
heinrich5991 wrote: post #28

Earlier quoted context omitted.

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

What rhetoric? Are you confusing this with "the 10x programmer" meme? Claims of becoming a 10x better programmer aren't claims about making one a 10x programmer. The former is about relative self-improvement and motivationally hyperbolic; the latter is about relative comparison to others, is often used negatively to belittle, and is detrimentally hyperbolic.

> motivationally hyperbolic

It's such a ridiculously high number that it ceases to be motivational.

Re: The Danger of “Simplicity”

#132

Post by divan »

jolmg wrote: post #126
divan wrote: post #124

There is a lot of noise in the article (like mentioning Rob Pike's take on syntax highlighting), but mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles. Could've been a single tweet. Attempt to explain the dangers of simplicity is lost in vague sentences like "Rust has different concept of simplicity -> Rust authors wanted to protect from memory errors" or TBU (True But Useless) phr…

> mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles The mentions of Rust, Haskell, and Go are limited to a single section of the article, so I'm not sure what you're talking about. Most of the article seems to stay abstract with concrete cases brought as examples.

I might be biased, as I had to read every Go rant back then when writing a "How to complain about Go" article, and this is clearly the same narrative.

Author did a good job to hide it, but if you look closer you'll see indirect Go mentioning throughout the whole article:

- "“What do you mean, you think Go’s error handling is bad? It’s simple!”"

- How can we articulate a position more powerful than “syntax highlighting is juvenile?” - "Go’s error handling has become a meme,"

- "The creators of Go have said, sometimes in pejorative terms,1 that “average programmers” have difficulty understanding complex languages,"

- "It’s inflammatory, but the article “Why Go’s design is a disservice to intelligent programmers” is worth reading just for the quotes from Rob Pike."

Re: The Danger of “Simplicity”

#133

Post by F-0X »

jackpirate wrote: post #104
hzhou321 wrote: post #95

Earlier quoted context omitted.

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…

Modules are "simpler" than vectors because they have fewer axioms, but they are also much harder to understand. For example, not all modules have a basis, which can make them much harder to work with. For background on the math, see: https://math.stackexchange.com/questions/137442/a-module-wit...

Interesting analogy, but it's a little off.

The main reason modules are interesting is not as a generalisation of vector spaces, but because they are helpful in studying rings. Kernels of ring homomorphisms are ideals, which in general are not subrings, but they are modules - and of course every ring is a module over itself. So to study a ring R it pays off to instead study R-modules, since working with them is... you guessed it! Simpler.

Re: The Danger of “Simplicity”

#134

Post by hzhou321 »

chrisweekly wrote: post #130
hzhou321 wrote: post #95

Earlier quoted context omitted.

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…

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" and "whole" can also be swapped with "now" and "future". "now" is here but "future" is uncertain.

Re: The Danger of “Simplicity”

#135

Post by BenoitEssiambre »

I like to take an information theoretic, model-problem fit stance on simplicity. It's useful to reason about it in terms of overfitting vs underfitting, over-abstraction vs under-abstraction, high resolution fit vs low resoltion fit, and in terms of cross entropy between the knowledge embedded into a software system and the information relevant to solve the corner cases of the problems (https://medium.com/@b.essiambre/product-market-crossfit-c09b...). Well tuned knowledge is not an easy thing.

Re: The Danger of “Simplicity”

#136

Post by asdfasdfasdfa »

sooheon wrote: post #129
thomascgalvin wrote: post #122

Earlier quoted context omitted.

> I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. High level code shifts the burned of understanding the type system from the author and the compiler to the reader. Yes, there is more text to read in a strongly, strictly typed language, but that extra syntax conveys a lot of important informatio…

What's wrong with: (cat-logs [& entries] ...) If we care about human understanding of the contract, types are no better than names. reverse :: [a] -> [a] (reverse [xs] ...)

Names can and do lie, types are checked by the compiler. Also in you example, is an entry a string? a dict? its own class? who knows.

Re: The Danger of “Simplicity”

#137

Post by hzhou321 »

SuoDuanDao wrote: post #125
hzhou321 wrote: post #95

Earlier quoted context omitted.

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…

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…

Thanks. I think I understand the background much better now. When we think easy, we always take the "my" and "now" perspective. When we think simple, we often take the wholesome point of view. Thus the need for differentiation.

Re: The Danger of “Simplicity”

#138

Post by ellius »

hzhou321 wrote: post #95
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/

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…

Simple is easier than complex the same way that exercise is easier than chronic obesity. If you have the discipline to do the obvious that's great, but it takes willpower to create or do the simple thing. Oftentimes it's easier or more expedient to do the lazier easy thing in the moment, but you pay for it down the road. For example: I notice I'm doing the same calculation twice on the front and back end of my application. The "simple" thing to do would typically be to extract that logic to one place so that you don't end up having to modify it in two/five/twelve places down the road. But I'm already halfway through writing it, and the simplification will involve some non-trivial refactoring, so I take the easy route and write the same logic twice. It's easy for now, but will be complex when I have to change it down the road.

Re: The Danger of “Simplicity”

#139

Post by Ma8ee »

hinkley wrote: post #117
Ma8ee wrote: post #49

Earlier quoted context omitted.

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

'You' being personified here, rather than the general you. Straightforward tends to suggest we don't have to have a bunch of meetings about it, because the right person either has the knowledge or we know precisely where to get it.

It depends on the context. I had the math professor lecturing her students in mind.

Re: The Danger of “Simplicity”

#140

Post by ellius »

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

Not to nitpick too hard, but I'm pretty confident we know that was Pascal. The rest are misattributions.
Post reply on HN