Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike: Simplicity Is Complicated [video]

thedotpost.com

Post reply on HN
Print view View original

81–90 of 152 posts

Re: Rob Pike: Simplicity Is Complicated [video]

#81

Post by catnaroek »

pron wrote: post #80
catnaroek wrote: post #35

Earlier quoted context omitted.

> How do you have a large set of language features with them not interacting? The ability to write interesting programs in a language comes from the interaction between its features. The real problem is features that interact in unpleasant ways , which almost always results from a lack of foresight on the language designer's part. > In C++, RAII interacts with exceptions, which is the point but isn't exactly pleasant…

> The interaction between control effects (of which exceptions are a particular case) and substructural types (of which C++'s RAII is a very broken particular case) is certainly nontrivial A nitpick, but what constitutes an effect is rather arbitrary. An effect in the PFP sense is not an operational definition (other than IO) but a linguistic one. This is why I think that handling errors well, handling mutation well…

I was talking only about control effects, not I/O or mutation. Control effects are basically stylized uses of continuations, with less insanity involved.

Re: Rob Pike: Simplicity Is Complicated [video]

#82

Post by pron »

catnaroek wrote: post #81
pron wrote: post #80

Earlier quoted context omitted.

> The interaction between control effects (of which exceptions are a particular case) and substructural types (of which C++'s RAII is a very broken particular case) is certainly nontrivial A nitpick, but what constitutes an effect is rather arbitrary. An effect in the PFP sense is not an operational definition (other than IO) but a linguistic one. This is why I think that handling errors well, handling mutation well…

I was talking only about control effects, not I/O or mutation. Control effects are basically stylized uses of continuations, with less insanity involved.

I understand. I just said that classifying non-linear transfer of control (whether exceptions or proper continuation) as an effect at all is quite arbitrary, and is just a common usage in the PFP world.

Of course, substructural types are also a language concept (that does indeed interact badly with non-local jumps), which is why I said it was a nitpick about the use of the word "effect".

Re: Rob Pike: Simplicity Is Complicated [video]

#83

Post by catnaroek »

pron wrote: post #82
catnaroek wrote: post #81

Earlier quoted context omitted.

I was talking only about control effects, not I/O or mutation. Control effects are basically stylized uses of continuations, with less insanity involved.

I understand. I just said that classifying non-linear transfer of control (whether exceptions or proper continuation) as an effect at all is quite arbitrary, and is just a common usage in the PFP world. Of course, substructural types are also a language concept (that does indeed interact badly with non-local jumps), which is why I said it was a nitpick about the use of the word "effect".

> I just said that classifying non-linear transfer of control (whether exceptions or proper continuation) as an effect at all is quite arbitrary, and is just a common usage in the PFP world.

What exactly makes it arbitrary? It's pretty sensible, even if you don't have substructural types.

> Of course, substructural types are also a language concept (that does indeed interact badly with non-local jumps)

Control effects and substructural types don't interact “badly”. They just require care if you want them together. If you desugar control effects into delimited continuations (that is, normal higher-order functions), it becomes clear as daylight how to correctly handle their interaction with substructural types.

Re: Rob Pike: Simplicity Is Complicated [video]

#84

Post by tome »

catnaroek wrote: post #48
Peaker wrote: post #44

Earlier quoted context omitted.

How do GADTs or type families weaken parametricity?

Without either GADTs or type families, two types `Foo` and `Bar` with mappings `fw :: Foo -> Bar` and `bw :: Bar -> Foo` that compose in both directions to the identity, are “effectively indistinguishable” from one another in a precise sense. If you have a definition `qux :: T Foo`, for any type function `T` not containing abstract type constructors, you can construct `justAsQuxxy :: T Bar` by applying `fw` and `bw`…

Are you saying something like "All type constructors are functorial Hask^n x Hask^op^m -> Hask"?

Re: Rob Pike: Simplicity Is Complicated [video]

#85

Post by themartorana »

catnaroek wrote: post #64
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.

> 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 things, but where it's placed itself - among often headless networking infrastructure projects and backends, it's exceedingly good at what it offers.

Edit: had repeated myself.

Re: Rob Pike: Simplicity Is Complicated [video]

#86

Post by catnaroek »

tome wrote: post #84
catnaroek wrote: post #48

Earlier quoted context omitted.

Without either GADTs or type families, two types `Foo` and `Bar` with mappings `fw :: Foo -> Bar` and `bw :: Bar -> Foo` that compose in both directions to the identity, are “effectively indistinguishable” from one another in a precise sense. If you have a definition `qux :: T Foo`, for any type function `T` not containing abstract type constructors, you can construct `justAsQuxxy :: T Bar` by applying `fw` and `bw`…

Are you saying something like "All type constructors are functorial Hask^n x Hask^op^m -> Hask"?

It's something weaker. Consider the groupoid of Haskell types and isomorphisms. Without GADTs and type families, all type constructors of kind `* -> *` are endofunctors on this groupoid.

Note 1: And there are higher-kinded analogues, but I hope you get the idea from this.

Note 2: There are also exceptions, like `IORef` and friends.

Re: Rob Pike: Simplicity Is Complicated [video]

#87

Post by pron »

catnaroek wrote: post #83
pron wrote: post #82

Earlier quoted context omitted.

I understand. I just said that classifying non-linear transfer of control (whether exceptions or proper continuation) as an effect at all is quite arbitrary, and is just a common usage in the PFP world. Of course, substructural types are also a language concept (that does indeed interact badly with non-local jumps), which is why I said it was a nitpick about the use of the word "effect".

> I just said that classifying non-linear transfer of control (whether exceptions or proper continuation) as an effect at all is quite arbitrary, and is just a common usage in the PFP world. What exactly makes it arbitrary? It's pretty sensible, even if you don't have substructural types. > Of course, substructural types are also a language concept (that does indeed interact badly with non-local jumps) Control effect…

> What exactly makes it arbitrary?

The word effect in the PFP world denotes anything that a language-level function does which may affect other functions and is not an argument or a return parameter. That definition is not valid outside of PFP/LC, because it defines as effects as things that are indistinguishable from non-effects in other models of computation. E.g. it calls assignments to certain memory cells "effects" while assignments to other memory cells non-effects.

Again, my (very minor) point is that the word "effect" as you use it simply denotes a PFP linguistic concept rather than an essential computational thing. The only reason I mention it is that the word "effect" has a connotation of something that's real and measurable beyond the language. That's true for IO and time (computational complexity, which, interestingly, is not generally considered an effect in PFP), but not true for jumps (or continuations) and mutation.

> delimited continuations (that is, normal higher-order functions)

Again, you are assuming PFP nomenclature. Delimited continuations do not require language-level functions at all, and higher-order functions can be defined in terms of delimited continuations just as the opposite is true. Delimited continuations are no more higher-order functions than higher-order functions (or monads, rather) are delimited continuations. PFP is not the only way to look at abstractions and not the only fundamental nomenclature.

Re: Rob Pike: Simplicity Is Complicated [video]

#88

Post by catnaroek »

pron wrote: post #75
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...

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

Agreed. Otherwise, Forth and Scheme would've taken over the world.

> Something may well be formally simple but at the same time incompatible with human cognition.

Do you have a concrete example?

> (if we wish to view simplicity as possessing a positive value that implies ease of understanding).

I don't particularly fetishize simplicity. What I want is the least effort path to writing correct programs. The following features help:

0. Simplicity - smaller formal systems have less room for nasty surprises.

1. Using the right tool for resource management - sometimes it's a garbage collector, sometimes it's substructural types.

2. Typeful programming - it's an invaluable tool for navigating the logical structure of the problem domain.

Re: Rob Pike: Simplicity Is Complicated [video]

#89

Post by pron »

catnaroek wrote: post #88
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. Agreed. Otherwise, Forth and Scheme would've taken over the world. > Something may well be formally simple but at the same time incompatible with human cognition. Do you have a concrete example? > (if we wish to view simplicity as possessing a positive value that implies ease of understanding). I don't particularly fetishize simplicity. What I want i…

> Do you have a concrete example?

Off the top of my head, and since we're talking about computation, I'd say SK combinator calculus. Or Church numerals.

> Typeful programming

It is, but it can also be a hindrance. Finding the sweet spot is a matter for empirical study.

Re: Rob Pike: Simplicity Is Complicated [video]

#90

Post by catnaroek »

pron wrote: post #89
catnaroek wrote: post #88

Earlier quoted context omitted.

> If we accept that, then simplicity alone is not a desirable goal. Agreed. Otherwise, Forth and Scheme would've taken over the world. > Something may well be formally simple but at the same time incompatible with human cognition. Do you have a concrete example? > (if we wish to view simplicity as possessing a positive value that implies ease of understanding). I don't particularly fetishize simplicity. What I want i…

> Do you have a concrete example? Off the top of my head, and since we're talking about computation, I'd say SK combinator calculus. Or Church numerals. > Typeful programming It is, but it can also be a hindrance. Finding the sweet spot is a matter for empirical study.

> I'd say SK combinator calculus. Or Church numerals.

They're a PITA to use, but not because they're hard to understand.

Post reply on HN