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

121–130 of 172 posts

Re: The Danger of “Simplicity”

#121

Post by jolmg »

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/

Problem: Finely chopping food

Complex and Easy: Stick blender with chopper attachment.

Simple and Hard: Knife and cutting board.

-

Problem: Making a drawing

Complex and Easy: Computer and printer

Simple and Hard: Paper and pencil

-

Problem: Sewing lots of clothes (perfect stitches)

Complex and Easy: Sewing machine

Simple and Hard: Thread and needle

-

Problem: Software

Complex and Easy: Graphical User Interface

Simple and Hard: Command-Line Interface

Re: The Danger of “Simplicity”

#122

Post by thomascgalvin »

ken wrote: 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…

> 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 information quickly and cheaply, and this is information that the reader will need to know.

The difference between:

    cat( first, second ){ ... }
And

    cat( first: LogEntry, second: LogEntry): void { ... }
Is immense. In the later case, I know exactly what this function wants me to provide, what contracts the arguments must honor, and I know something about what the function intends to do with those arguments; it's void, so there are probably side-effects.

In the first case, I have to figure that out by reading the body of the method. The signature could tell me all of this, but it doesn't.

> After all, if you haven't written it correctly, the user will notice right away, too!

My users are not paid well enough to debug my code for me.

Re: The Danger of “Simplicity”

#123

Post by masswerk »

astrobe_ wrote: post #102
masswerk wrote: post #42

Earlier quoted context omitted.

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

> Simplicity is often a matter of perspective Complexity was formally defined by Kolmogorov, using with Turing machines even. Hence, Simplicity is also objectively defined.

Referring to the above example of verb-noun vs noun-verb grammar: take for example the infinitive verb form. With the former (verb-noun) it's just the verb devoid of any context, simplicity in its purest, which is also, why and how it's listed in a lexicon. Looking at this from the noun-verb perspective, you've to construct a hypothetical minimal viable object, which will be also – as you want to keep things simple – the object every other object inherits from, the greatest common denominator of any objects that may appear in your system. By this, you arrived at the most crucial architectural questions of your system and its reach and purpose. While it's still about simple things, neither the task nor the definitions derived from the process will be simple at all. Nor is there a universally accepted simple answer, as a plurality of object oriented approaches may testify for. The question is on an entirely different scale and level for the two approaches. On the other hand, for a verb-noun approach, similar may appear for anything involving relations, which are already well defined in an object oriented approach. And, as you've arrived at these simple fundamentals of simplicity in your system, what may be simple or not in your systems will depend on the implicit contracts included in these definitions and how well they stand the test of time and varying use and purpose.

Re: The Danger of “Simplicity”

#124

Post by divan »

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) phrases like "every choice has a cost"/"everything is a tradeoff".

Re: The Danger of “Simplicity”

#125

Post by SuoDuanDao »

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…

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 like a heuristic to distinguish the two. Writing a solution in a different language is easier to me, but I can tell on an absolute level that there are more failure points to that approach.

Re: The Danger of “Simplicity”

#126

Post by jolmg »

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.

Re: The Danger of “Simplicity”

#128

Post by tempguy9999 »

hzhou321 wrote: post #113
tempguy9999 wrote: post #100

Earlier quoted context omitted.

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

Until you find a good example, I challenge your understanding :) Similar to my response to another comment, I suspect there is a switching of subjects. It starts with a problem, and the subject is a solution to the problem. Simpler solution is easier to understand and manage. A more complex solution is more difficult. Is there a counter example? Try not to switch out the subject here. For example, one may propose to…

I don't deny your right to challenge, but tight now I can't give an example. I've just gone through months of my posts looking for one particular post that might clarify but I can't find it. Not being able to search your own comments is frustrating. I'll have a muse overnight.

sorry!

Found it (thanks google): https://news.ycombinator.com/item?id=20591621 Simplicity was staring me in the face, it took weeks to find it.

Re: The Danger of “Simplicity”

#129

Post by sooheon »

thomascgalvin wrote: post #122
ken wrote: 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…

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

Re: The Danger of “Simplicity”

#130

Post by chrisweekly »

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…

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.
Post reply on HN