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

141–150 of 172 posts

Re: The Danger of “Simplicity”

#141

Post by carapace »

Recognizing simplicity requires familiarity with complexity.

- - - -

FWIW, Category Theory provides a mathematical formalism for determining when your system is "as simple as possible, but no simpler".

- - - -

> “average programmers” have difficulty understanding complex languages

That's not pejorative IMO, that's practically tautological: If "average programmers" have difficulty understanding a language, isn't that an indicator that it might be too complex? Anyhow, trawling though e.g. Stackexchange provides adequate evidence, IMO. Or a thread about Haskell with all the people complaining about how hard it is to understand FP, etc.

Re: The Danger of “Simplicity”

#142

Post by ellius »

nnq wrote: post #3

There was a wise thing along the lines of "to build a simpler system, start with more powerful (and complex, by necessity) building blocks"... I think it was Alan Kay who said this or something very similar. Worst thing is that "simple" languages like Go force you to mix up "business logic" with "plumbing/infra logic" with "error handling logic" if you try to be idiomatic... I know that for security crucial code you…

Funny enough, one of my favorite talks argues the opposite. "Constraints Liberate, Liberties Constrain." I won't attempt to summarize but it's well worth a watch.

Re: The Danger of “Simplicity”

#143

Post by carapace »

tempguy9999 wrote: post #128
hzhou321 wrote: post #113

Earlier quoted context omitted.

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…

( FWIW Algolia can search comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... )

Re: The Danger of “Simplicity”

#144

Post by mbostleman »

hinkley wrote: post #120
mbostleman wrote: post #97

The two perspectives that I often find at opposite poles when proposing simplicity is that of the developer vs. that of the user. Generally what's simple for the user drives less simple solutions for the developer and vice versa. It's not always possible, but when it is, I strive to find the solution that ends up being dead simple for both.

I really noticed this when I caught business folks conflating the two. Often the more easily you can describe the situation, the more code it takes to make it Just Work. Simple for the user is harder for me.

Exactly

Re: The Danger of “Simplicity”

#145

Post by NoodleIncident »

hzhou321 wrote: post #137
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…

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.

I might be wrong, but I think the word you meant by "wholesome" is actually "holistic"

Re: The Danger of “Simplicity”

#146

Post by jahaja »

cytzol wrote: post #48
haolez wrote: 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 si…

This. So much. I would really hope that folks could accept that different languages have different objectives, and that this is good. The problem I've seen is that there's always a feature creep by folks that like more expressiveness; "This is a solved problem and not an issue at all! You must make it a part of the language!". So there's some kind of inherent pursuit of conformity given enough adoption.

Re: The Danger of “Simplicity”

#147

Post by msla »

jolmg wrote: post #121
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…

> Problem: Software

> Complex and Easy: Graphical User Interface

> Simple and Hard: Command-Line Interface

GUIs are easy for the specific things the programmers made easy, and potentially impossible for everything else. The moment you want something the developers didn't put in the GUI, there's no recourse other than writing your own tool.

Command lines are harder to begin with, but modern command lines give you a gentler ramp up to writing your own tools.

Re: The Danger of “Simplicity”

#148

Post by zmmmmm »

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…

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

But they actually really think that because Python is easy for them, that it's "simple". It's not: it's incredibly complex.

Re: The Danger of “Simplicity”

#149

Post by zmmmmm »

tabtab wrote: post #114
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…

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…

One of the reasons I hover in the space of semi-functonal languages like Groovy and Scala. Because as much as I love concisely expressing a piece of complex logic as a composition of reduces, folds, maps etc., being able to easily and naturally break out of that to execute a piece of imperative code in the middle of it is still regularly a life saver to me and often an order of magnitude clearer than the pure functional solution to a reader.

Re: The Danger of “Simplicity”

#150

Post by zmmmmm »

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

> If we care about human understanding of the contract, types are no better than names.

That depends on your familiarity with the code though. Yes if you are deeply familiar with the code you probably know what data type an "entry" is. But come to it cold and trying to reverse engineer code like that in the middle of a complex system to understand it is frightening (at least, in my experience).

Post reply on HN