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

Re: Rob Pike: Simplicity Is Complicated [video]

#111

Post by pron » Thu, Dec 03, 2015, 5:04 PM UTC

tel wrote: post #100

pron wrote: post #97

Earlier quoted context omitted.

> A much more foundational difference of opinion about purity arises from whether or not you allow termination. Termination or non-termination? One of the (many) things that annoy me about PFP is the special treatment of non-termination, which is nothing more than unbounded complexity. In particular, I once read a paper by D.A. Turner about Total Functional Programming that neglected to mention that every program eve…

Non-termination, my bad! And of course that's true! Trivially so, though, in that we could do the same by picking the counter to be 10 instead of 2^1000, since we don't appear to care about changing the meaning of the program. If we do, then we have to consider whether we want our equality to distinguish terminating and non-terminating programs. If it does distinguish, then non-terminating ones are impure. Now, what…

> If we do, then we have to consider whether we want our equality to distinguish terminating and non-terminating programs.

But this is what bugs me. As someone working on algorithms (and does not care as much about semantics and abstractions), the algorithm's correctness is only slightly more important than its complexity. While there are (pragmatic) reasons to care about proving partial correctness more than total correctness (or prioritizing safety over liveness in algorithmists' terms), it seems funny to me to almost completely sweep complexity -- the mother of all effects, and the one at the very core of computation -- under the rug. Speaking about total functions does us no favors: there is zero difference between a program that never terminates, and one that terminates one nanosecond "after" the end of the physical universe. Semantic proof of termination, then, cannot give us any more useful information than no such proof. Just restricting our computational model from TM to total-FP doesn't restrict it in any useful way at all! Moreover, in practical terms, there is also almost no difference (for nearly all programs) between a program that never terminates and one that terminates after a year.

Again, I fully understand that there are pragmatic reasons to do that (concentrate on safety rather than liveness), but pretending that there is a theoretical justification to ignore complexity -- possibly the most important concept in computation -- in the name of "mathematics" (rather than pragmatism) just boggles my mind. The entire notion of purity is the leakiest of all abstractions (hyperbole; there are other abstractions just as leaky or possibly leakier). But we've swayed waaaay off course of this discussion (entirely my fault), and I'm just venting :)

Re: Rob Pike: Simplicity Is Complicated [video]

#112

Post by luckydude » Thu, Dec 03, 2015, 5:08 PM 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…

As someone maintaining an 18 year old code base, I've long held the same opinions as Rob. I often describe myself as the dumbest person on my team and then go on to say how fortunate it was that I was here first. All my smart people need to dumb stuff down enough that I can understand it. Which means we have a prayer of supporting it.

Obviously I can't force everything through that filter, some problems require complex solutions.

Hacker News is full of really bright people who like the expressiveness of Haskell et al. So it's not surprising that Rob's not going over well here. Just saying that us dumb people really appreciate his efforts.

Re: Rob Pike: Simplicity Is Complicated [video]

#113

Post by pcwalton » Thu, Dec 03, 2015, 5:18 PM UTC

EdiX wrote: post #43

catnaroek wrote: post #21

Earlier quoted context omitted.

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

> nothing reflects entanglement better than a formal semantics A formal semantics is just a way to translate from one formalism to another. It's rather obvious that choosing the target formalism determines how simple the language will appear, when you talk about "formal semantics" you should specify "which one": operational? denotational? axiomatic? Stricly speaking a compiler or an interpreter represents a formal se…

> For example, in your reddit post you claim that := is problematic, and indeed its semantics is tricky and often trips beginners (and even experienced!) programmers. However := semantics is not actually that complicated "define every variable that isn't defined inside the current scope, otherwise assign them" and the errors stem from the fact that people assume that the scope lookup for := is recursive, which would arguably result in a more complicated formal semantics.

Clearer examples of unnecessary complexity in Go would be the function-scoped nature of "defer" (implicit mutable state is much more complicated than block scoping) and the inconsistent behavior of "nil" with the built-in collections (reading from a nil map returns zero values, but reading from a nil slice panics).

Re: Rob Pike: Simplicity Is Complicated [video]

#114

Post by pcwalton » Thu, Dec 03, 2015, 5:22 PM UTC

bjwbell wrote: post #110

kibwen wrote: post #108

Earlier quoted context omitted.

Writing tooling for C++ is difficult because of how entangled all the language's features are (and its wonky grammar certainly doesn't help). In addition C++'s type system is probably even weaker than Go's, having inherited a lot of slop from C. That said, if you're talking about source code formatters, I'm pretty sure that clang-format predates gofmt (and surely clang-format was not the first automatic source code f…

I'm thinking more of difficulty in writing rustfmt compared to gofmt. There's other examples like go-oracle or goimports which as far as I know don't have Rust equivalents. How useful the extra tooling is, I don't really know.

> I'm thinking more of difficulty in writing rustfmt compared to gofmt.

The extra stuff that rustfmt does stems from the fact that rustfmt wants to aesthetically format code well, matching the style that the community had settled on prior to its introduction (e.g. avoiding long lines, lining up parameters), while gofmt is fine with less aesthetically pleasing code (long lines, all parameters on one line) as long as the implementation of gofmt remains simple. There's nothing stopping anyone from implementing a bare-bones rustfmt in the style of gofmt and trying to push its style onto the community, but Nick had different goals.

Re: Rob Pike: Simplicity Is Complicated [video]

#115

Post by pcwalton » Thu, Dec 03, 2015, 5:24 PM UTC

weitzj wrote: post #46

bjwbell wrote: post #5

Earlier quoted context omitted.

Wrong C++. maybe that's why he didn't say, it's all of them (for an approximate value of all).

Rust

How about asking him, instead of speculating here?

Re: Rob Pike: Simplicity Is Complicated [video]

#116

Post by BurningFrog » Thu, Dec 03, 2015, 5:27 PM UTC

themartorana wrote: post #85

catnaroek wrote: post #64

Earlier quoted context omitted.

> This is a classic example of worse-is-better. C won over Lisp, not because “worse is better”, but because the C's advantages over Lisp (performance on cheap machines) were more pronounced than the other way around (“safety” achieved by means of lots of runtime checking - by no means was it possible to statically rule out errors). Lispers fancy their language of choice the pinnacle of computer science, but the falsi…

"...Go doesn't do enough for the programmer" Seems like a "boo Go" echo chamber in here, but as someone that moved their entire backend infrastructure to Go, the offering was so compelling it was worth going against common wisdom and actually rewriting huge pieces of infrastructure code. And I'm hardly alone - many huge companies felt the same value proposition and made the same decisions. Go isn't perfect for many t…

> as someone that moved their entire backend infrastructure to Go

What did you move from?

Re: Rob Pike: Simplicity Is Complicated [video]

#117

Post by pcwalton » Thu, Dec 03, 2015, 5:27 PM UTC

bjwbell wrote: post #58

Peaker wrote: post #47

Earlier quoted context omitted.

Go is a simple language, with 1970's features. It is very easy to implement, and leaves a lot of the complexity (null pointers, generics, etc) to the user instead of solving it in the language. This is a classic example of worse-is-better. An MIT-style language would be Rust, which indeed struggled to get to v1.0 and Go vs. Rust plays out quite similarly to what worse-is-better would predict.

There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.

> An advantage of Go over Rust is easier tooling due to a simpler language

I'm curious how "tooling" is easier in Go than in Rust. To my mind, dynamic tooling (instrumentation, profiling, debugging, etc.) is much easier in Rust than in Go, because Rust uses the OS facilities and looks much like native code, while Go's runtime reinvents the world.

This is in fact what we've seen—Rust didn't have to write custom profilers, custom debuggers, language-specific race detectors, and so on, because the native system tools work just fine.

(NB: I'm not saying Go made the wrong decision with a userland scheduler; I'm objecting to the idea that it's somehow simpler to do that. It's much more complex.)

Re: Rob Pike: Simplicity Is Complicated [video]

#118

Post by pcwalton » Thu, Dec 03, 2015, 5:32 PM UTC

Peaker wrote: post #47

chubot wrote: post #8

From reading the abstract, it sounds like this addresses precisely the topic of "Worse is Better" [1]. There are frequent misunderstandings of this essay -- the argument isn't as coarse as "crappy software wins", or "release early and often". The tradeoff is: do you want a simple interface (MIT style) or a simple implementation (NJ style)? If you want a simple interface, you have to hide a bunch of complexity underne…

Go is a simple language, with 1970's features. It is very easy to implement, and leaves a lot of the complexity (null pointers, generics, etc) to the user instead of solving it in the language. This is a classic example of worse-is-better. An MIT-style language would be Rust, which indeed struggled to get to v1.0 and Go vs. Rust plays out quite similarly to what worse-is-better would predict.

> An MIT-style language would be Rust, which indeed struggled to get to v1.0 and Go vs. Rust plays out quite similarly to what worse-is-better would predict.

Not having to implement a userland OS scheduler, a production-quality garbage collector, and an industrial-strength compiler backend from scratch strikes me as a fairly New Jersey-style approach, don't you think?

(I think this whole "Rust vs. Go" as "MIT vs. New Jersey" argument is pretty silly. There are many factors going into why Go released 1.0 before Rust did, and both communities have consensus that you shouldn't treat Rust vs. Go as a horse race anyway.)

Re: Rob Pike: Simplicity Is Complicated [video]

#119

Post by bjwbell » Thu, Dec 03, 2015, 5:53 PM UTC

pcwalton wrote: post #117

bjwbell wrote: post #58

Earlier quoted context omitted.

There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.

> An advantage of Go over Rust is easier tooling due to a simpler language I'm curious how "tooling" is easier in Go than in Rust. To my mind, dynamic tooling (instrumentation, profiling, debugging, etc.) is much easier in Rust than in Go, because Rust uses the OS facilities and looks much like native code, while Go's runtime reinvents the world. This is in fact what we've seen—Rust didn't have to write custom profil…

I should have been more specific by tooling. I meant source code manipulation and analysis, go-oracle and goimports are a couple. There's many more in the go community.

Are they useful, I'm not sure. They feel useful but I have little trust in my judgment. When I switched back in the day from VS to emacs I didn't seem to miss all of the refactoring tools VS provided.

Re: Rob Pike: Simplicity Is Complicated [video]

#120

Post by AnimalMuppet » Thu, Dec 03, 2015, 5:59 PM UTC

fauigerzigerk wrote: post #95

pron wrote: post #75

Earlier quoted context omitted.

> The only objective measure of simplicity is the size of a formal semantics. If we accept that, then simplicity alone is not a desirable goal. Something may well be formally simple but at the same time incompatible with human cognition. Indeed, that may not be objective, but since when do we value things only by objective measures? That the only objective measure of simplicity may be the size of formal semantics doe…

>If we accept that, then simplicity alone is not a desirable goal Or maybe simplicity in terms of the formal semantics is a desirable goal, but not the simplicity of the language alone. At the end of the day, what determines mental load is the complexity of solving a particular problem using a particular language. I don't think this simplicity follows from the simplicity of the language itself. There may not even be…

In general, the simpler the language, the more complex the code to implement the solution in that language, and so the harder it is to understand the code. But the more complex the language, the simpler (and easier to understand) the code, but the language itself is harder to understand. It's almost like you want the language to have the square root of the complexity of the problem.

(This is in general. The big way around this is to pick a language that is well-suited for your particular problem.)