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

151–160 of 172 posts

Re: The Danger of “Simplicity”

#151

Post by zmmmmm »

ajbonkoski wrote: post #103

I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives" I would hope that people with the same objectives would agree on simplicity for that domain. Examples: Need a lot of machine control, direct memory control (page alignment, cache alignment, shared memory, numa, etc) interact with system calls directly, interact with hardware, and security is not important in t…

> I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives"

That's one dimension of simplicity, but it doesn't take into account some of the other benefits of simplicity, such as, eg: robustness. Another definition would be "the approach that minimizes the total number of possible interactions" (akin to "moving parts" in a physical machine). In that sense, the fewer total possible interactions, the fewer places something can break. There might be MORE cognitive load to a human in direct sense, but the system is far more constrained to only do the "right thing".

I sometimes think of the generalization of it being "the approach that minimises the total state space of the system, including the brain of the human trying to understand it".

Re: The Danger of “Simplicity”

#152

Post by jolmg »

msla wrote: post #147
jolmg wrote: post #121

Earlier quoted context omitted.

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

Same is true with the other examples, I believe. Simpler tools tend to be the more versatile ones.

Re: The Danger of “Simplicity”

#153

Post by ken »

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…

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 programmer, I don't think so. (I don't think I've ever been accused of that!) 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.

I find C (and imperative languages in general) harder to write and debug. Am I "doing it wrong"? I've found C hard to work with since around 1990 when I first tried to learn it.

Re: The Danger of “Simplicity”

#154

Post by ken »

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…

In a higher-level language, I tend to have a "cat" which is generic-by-default. In a functional language, functions tend to have no side effects. What exactly is the purpose of specialization here, or mutation?

Arguments like this against Lisp tend to invent examples like this which sound reasonable in a Java program but don't exactly make sense in Lisp.

Yes, static type systems can be handy if your program is based on the concept of defining new types and mutating them through new specialized methods. None of the programs I write are like that. That's not the only way to write a program.

Re: The Danger of “Simplicity”

#156

Post by codygman »

hu3 wrote: post #112
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.

Depends on who's opinion we're talking about. In general, Go community is satisfied with its direction according to 2018 survey: https://blog.golang.org/survey2018-results In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

> In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

How do you know the harsh critics of Go you read barely used Go at all? What things did harsh critics try to build with Go that it wasn't aimed for, and/or what is the most frequent wrong thing those critics try to build with Go?

Re: The Danger of “Simplicity”

#157

Post by Ma8ee »

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…

In all your examples, the complexity is hidden in the underlying technology, which I think makes them less than ideal. Sewing with a sewing machine is usually both less complex and simpler than sewing by hand. If you count the complexity of the hardware and the operating system and compiler, nothing in development is simple.

For me the dichotomy is better is better illustrated by: I need to create a new class that, with a few exceptions, does exactly what an existing class already does.

The easy way is to copy the existing class and make the small necessary changes in the copy. The simple way would be to refactor and put all the differences in delegates.

Re: The Danger of “Simplicity”

#158

Post by jolmg »

Ma8ee wrote: post #157
jolmg wrote: post #121

Earlier quoted context omitted.

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…

In all your examples, the complexity is hidden in the underlying technology, which I think makes them less than ideal. Sewing with a sewing machine is usually both less complex and simpler than sewing by hand. If you count the complexity of the hardware and the operating system and compiler, nothing in development is simple. For me the dichotomy is better is better illustrated by: I need to create a new class that, w…

> both less complex and simpler

Did you mean "easier"? Because complex and simpler are antonyms, so it seems kind of redundant to use both words.

> the complexity is hidden in the underlying technology

The complexity is there. Maybe not all get involved with it, but it's still there.

> Sewing with a sewing machine is usually [simpler] than sewing by hand

The technology is more complex. The operation is maybe on par, though I would think it's also more complex. I may be biased in that I've hand-stitched many times and I find it super-simple, but I'm still a bit intimidated at the prospect of learning the basic use of a sewing machine. For very basic hand-stitching, you just put the thread through the needle, and the needle through the clothes in some pattern. That's it. For the sewing machine, I guess you have to lead the thread through some parts of the machinery, select some stuff through the knobs, etc. I think there certainly is a need to know a bit on the construction and workings of the sewing machine to be able to fix issues that arise.

> If you count the complexity of the hardware and the operating system and compiler, nothing in development is simple.

Complex and simple are relative terms, after all. If you refer to the last example of CLI vs GUI, they both involve the OS and compiler, etc. so that cancels out and we can refer to one as simpler or more complex than the other just based on the differences. Now, if you compare software development to making a sandwich, then sure, nothing in software development is as simple as making a sandwich.

> The easy way is to copy the existing class and make the small necessary changes in the copy. The simple way would be to refactor and put all the differences in delegates.

I agree to that, and that also aligns with the examples I gave. The complexity is mainly in how the thing is constructed. Duplicated code adds complexity to how the program is constructed. When you want to make a change to the common code, you have to make the change twice, maybe with a few differences. That makes development of the program also more complex.

It's the same as a sewing machine, or a stick blender with chopper attachment. Their construction and maybe operation is more complex than their counterparts.

Re: The Danger of “Simplicity”

#159

Post by simplify »

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

In a higher-level language, I tend to have a "cat" which is generic-by-default. In a functional language, functions tend to have no side effects. What exactly is the purpose of specialization here, or mutation? Arguments like this against Lisp tend to invent examples like this which sound reasonable in a Java program but don't exactly make sense in Lisp. Yes, static type systems can be handy if your program is based…

In TypeScript I define new types (aliases) and update them without mutation nor methods. It's a pleasure.

Re: The Danger of “Simplicity”

#160

Post by hzhou321 »

NoodleIncident wrote: post #145
hzhou321 wrote: post #137

Earlier quoted context omitted.

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"

You are right, I just grabbed the words by the sound of it.

A better word is subjective and objective. Easy is a subjective word, while simple is an objective one.

Post reply on HN