Rob Pike: Simplicity Is Complicated [video] • Hacker News Board

Re: Rob Pike: Simplicity Is Complicated [video]

#21

Post by catnaroek » Thu, Dec 03, 2015, 6:49 AM UTC

knucklesandwich wrote: post #10

I strongly disagree with this notion of "simplicity" as being attributable to scarcity of language features. Some of the languages that I felt were the easiest to use had quite a number of language features, but had simple semantics . I think Rich Hickey nailed this in his "Simple Made Easy"[1] talk. Complexity is not about additivity, it's about entanglement. [1] http://www.infoq.com/presentations/Simple-Made-Easy

> Complexity is not about additivity, it's about entanglement.

This. And nothing reflects entanglement better than a formal semantics. English (or any other natural language) always lets you sweep it under the rug. The only objective measure of simplicity is the size of a formal semantics.

I expand on this here: https://www.reddit.com/r/programming/comments/3sstis/for_bet...

Re: Rob Pike: Simplicity Is Complicated [video]

#22

Post by catnaroek » Thu, Dec 03, 2015, 6:50 AM UTC

i_s wrote: post #18

bjwbell wrote: post #12

Earlier quoted context omitted.

How do you have a large set of language features with them not interacting? In Java, serialization and generics interact with practically everything. In C++, RAII interacts with exceptions, which is the point but isn't exactly pleasant.

Most people consider garbage collection to be a net win in terms of simplicity. Have you thought about why? Not every feature interacts with other features in complicated and error prone ways.

You mean “ease of use”, not “simplicity”. Simplicity is the lack of (Kolmogorov) complexity.

Re: Rob Pike: Simplicity Is Complicated [video]

#23

Post by [deleted] » Thu, Dec 03, 2015, 6:53 AM UTC

catnaroek wrote: post #21

knucklesandwich wrote: post #10

I strongly disagree with this notion of "simplicity" as being attributable to scarcity of language features. Some of the languages that I felt were the easiest to use had quite a number of language features, but had simple semantics . I think Rich Hickey nailed this in his "Simple Made Easy"[1] talk. Complexity is not about additivity, it's about entanglement. [1] http://www.infoq.com/presentations/Simple-Made-Easy

> Complexity is not about additivity, it's about entanglement. This. And nothing reflects entanglement better than a formal semantics. English (or any other natural language) always lets you sweep it under the rug. The only objective measure of simplicity is the size of a formal semantics. I expand on this here: https://www.reddit.com/r/programming/comments/3sstis/for_bet...

[deleted]

Re: Rob Pike: Simplicity Is Complicated [video]

#24

Post by bjwbell » Thu, Dec 03, 2015, 6:59 AM UTC

i_s wrote: post #18

bjwbell wrote: post #12

Earlier quoted context omitted.

How do you have a large set of language features with them not interacting? In Java, serialization and generics interact with practically everything. In C++, RAII interacts with exceptions, which is the point but isn't exactly pleasant.

Most people consider garbage collection to be a net win in terms of simplicity. Have you thought about why? Not every feature interacts with other features in complicated and error prone ways.

That's why I said large set. I haven't thought about garbage collection enough to have any insight on it.

Re: Rob Pike: Simplicity Is Complicated [video]

#25

Post by placeybordeaux » Thu, Dec 03, 2015, 7:06 AM UTC

i_s wrote: post #14

This talk has a lot of very weak points. He made the claim that more features hurt readability (~6:10), because when you are reading you have to waste time thinking about why the programmer chose the set of features he did to write the code. To make that kind of claim without qualifications is just ridiculous - if it were true, why add any feature to a programming language at all? Especially if one believes readabili…

That one part was a weak part. If he claimed that having less features helps writeability I would have completely agreed though. It might take more writing to accomplish what you want, but frequently the choices you are making are a lot simpler, so you spend less time on them and more time just writing the code that you need to write.

Re: Rob Pike: Simplicity Is Complicated [video]

#26

Post by lomnakkus » Thu, Dec 03, 2015, 7:11 AM UTC

pcwalton wrote: post #20

threatofrain wrote: post #19

I think that code readability is different from system comprehensibility, and that readability is merely a subfactor to comprehensibility. Readability often means the time it takes for me to grok a function, module, or unit of code, and often what fits on my eyeball. System comprehensibility is how long it takes for me to learn the minimal set of atoms in order for me to comprehend an entire system. Rob Pike criticiz…

> I would also say that although I might lose some performance advantages with a functional approach, the improvement to system comprehension means better human optimization of distributed multi-core contexts. You don't even need to bring in parallelism for functional approaches to gain in performance. Here's an example (in Rust) of how you'd implement collecting an iterator into a vector using the "machine simple" a…

An excellent example. This is also one of those things that is hard to profile away, because it essentially leads to a very flat profile because you're probably forgetting to use with_capacity()/reserve() all over the place not just in single very-costly cases[1]. So you end up wasting, say, 1% CPU time all over the place... add up enough of these time-wasters and soon you're going to be wasting significant amounts of CPU time for no good reason.

Obviously, this kind of thing isn't a magic bullet, but in general I'd say the key for any kind of program is to express your intent at the highest level possible. This benefits both optimization and human readers! (That obviously means that the programming language must support such abstraction in a non-leaky way.)

[1] Which would show up prominently on a profile.

Re: Rob Pike: Simplicity Is Complicated [video]

#27

Post by justicezyx » Thu, Dec 03, 2015, 7:15 AM UTC

pcwalton wrote: post #20

threatofrain wrote: post #19

I think that code readability is different from system comprehensibility, and that readability is merely a subfactor to comprehensibility. Readability often means the time it takes for me to grok a function, module, or unit of code, and often what fits on my eyeball. System comprehensibility is how long it takes for me to learn the minimal set of atoms in order for me to comprehend an entire system. Rob Pike criticiz…

> I would also say that although I might lose some performance advantages with a functional approach, the improvement to system comprehension means better human optimization of distributed multi-core contexts. You don't even need to bring in parallelism for functional approaches to gain in performance. Here's an example (in Rust) of how you'd implement collecting an iterator into a vector using the "machine simple" a…

Array copying is on amortized...

Re: Rob Pike: Simplicity Is Complicated [video]

#28

Post by bjwbell » Thu, Dec 03, 2015, 7:18 AM UTC

i_s wrote: post #14

This talk has a lot of very weak points. He made the claim that more features hurt readability (~6:10), because when you are reading you have to waste time thinking about why the programmer chose the set of features he did to write the code. To make that kind of claim without qualifications is just ridiculous - if it were true, why add any feature to a programming language at all? Especially if one believes readabili…

Some history might help. Go was created largely as a reaction to writing server side C++. I have sympathy after writing but mostly reading C++ code bases. I swore never again.

I react in horror to the features being added to CUDA and SyCL to make them closer to C++.

I still hate C++ with a passion, grepping around in gecko is much harder than servo.

Re: Rob Pike: Simplicity Is Complicated [video]

#29

Post by serge2k » Thu, Dec 03, 2015, 7:20 AM UTC

threatofrain wrote: post #19

I think that code readability is different from system comprehensibility, and that readability is merely a subfactor to comprehensibility. Readability often means the time it takes for me to grok a function, module, or unit of code, and often what fits on my eyeball. System comprehensibility is how long it takes for me to learn the minimal set of atoms in order for me to comprehend an entire system. Rob Pike criticiz…

> tradeoffs between machine simplicity and system comprehensibility

I honestly have no idea what this even means.

Re: Rob Pike: Simplicity Is Complicated [video]

#30

Post by omaranto » Thu, Dec 03, 2015, 7:20 AM UTC

placeybordeaux wrote: post #25

i_s wrote: post #14

This talk has a lot of very weak points. He made the claim that more features hurt readability (~6:10), because when you are reading you have to waste time thinking about why the programmer chose the set of features he did to write the code. To make that kind of claim without qualifications is just ridiculous - if it were true, why add any feature to a programming language at all? Especially if one believes readabili…

That one part was a weak part. If he claimed that having less features helps writeability I would have completely agreed though. It might take more writing to accomplish what you want, but frequently the choices you are making are a lot simpler, so you spend less time on them and more time just writing the code that you need to write.

"If he claimed that having less features helps writeability I would have completely agreed though."

I suspect most people disagree with you and think, for example, that the features in high level languages make it easier to program in those languages than in low level ones.