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

Re: Rob Pike: Simplicity Is Complicated [video]

#121

Post by AnimalMuppet » Thu, Dec 03, 2015, 6:00 PM UTC

catnaroek wrote: post #90

pron wrote: post #89

Earlier quoted context omitted.

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

But for writing actual programs, the complexity of using matters as much as the complexity of understanding.

(I recognize that this doesn't invalidate the point you are trying to make in the parent post. They aren't incompatible with human understanding. They're incompatible with writing programs in a reasonable amount of time, though.)

Re: Rob Pike: Simplicity Is Complicated [video]

#122

Post by AnimalMuppet » Thu, Dec 03, 2015, 6:02 PM UTC

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…

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

> Do you have a concrete example?

Brainfuck?

Re: Rob Pike: Simplicity Is Complicated [video]

#123

Post by lomnakkus » Thu, Dec 03, 2015, 6:21 PM UTC

catnaroek wrote: post #77

lomnakkus wrote: post #71

Earlier quoted context omitted.

> Reflection, downcasts and assigning `null` to pointers are completely opt-in in Java too. No, they're not -- not in the same sense, at least. A GADT/TypeFamily is going to be visible in the API. None of the things you mentioned are visible in the API. There's a HUGE difference.

> A GADT/TypeFamily is going to be visible in the API. Only works if you're never going to make abstract types. Which I guess is technically true in Haskell - the most you can do is hide the constructors of a concrete type. But the ability to make abstract types is very useful. Don't get me wrong, I love Haskell. It's precisely because I love Haskell that I hate it when they add features that make it as hard to reaso…

If a type is abstract then the rest is up to the implementation of functions that operate on the data type -- and that could be hiding all kinds of nastiness like unsafePerformIO and the like. Yet, we usually don't care about that because it's an implementation detail.

Am I missing some way to "abuse" GADTs/TFs to violate the abstraction boundary or something like that? (I seriously can't see what you think the problem is here. I mean, you can equally well abuse unsafeCoerce/unsafePerformIO to do all kinds of weird things to violate parametricity, so I don't see why GADTs/TFs should be singled out.)

Re: Rob Pike: Simplicity Is Complicated [video]

#124

Post by bjwbell » Thu, Dec 03, 2015, 6:27 PM UTC

pcwalton wrote: post #114

bjwbell wrote: post #110

Earlier quoted context omitted.

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

You're right, the comparison isn't as valid as I thought, rustfmt has improved impressively since I looked at it last. 'go fix' might be a better comparison, what's the Rust equivalent?

Re: Rob Pike: Simplicity Is Complicated [video]

#125

Post by themartorana » Thu, Dec 03, 2015, 6:28 PM UTC

BurningFrog wrote: post #116

themartorana wrote: post #85

Earlier quoted context omitted.

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

Mostly Python. It's a similar story to Dropbox, CloudFlare, etc.

Re: Rob Pike: Simplicity Is Complicated [video]

#126

Post by steveklabnik » Thu, Dec 03, 2015, 6:54 PM UTC

bjwbell wrote: post #124

pcwalton wrote: post #114

Earlier quoted context omitted.

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

You're right, the comparison isn't as valid as I thought, rustfmt has improved impressively since I looked at it last. 'go fix' might be a better comparison, what's the Rust equivalent?

We don't make breaking changes anymore, so the need for such a thing hasn't been enough for anyone to bother making it.

Re: Rob Pike: Simplicity Is Complicated [video]

#127

Post by catnaroek » Thu, Dec 03, 2015, 7:10 PM UTC

tel wrote: post #94

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

So I sort of agree with you here, but only as a partial converse: > If all the formal semantic models for a language are unwieldy then you've probably got a non-simple language. Now, "simplicity" is a mental construct, a language UX construct. To handle this, I think of "unwieldy" as a bit of a technical term. What does it mean to be unwieldy? It means that there is significant non-ignorable complexity. Significant h…

> Now, "simplicity" is a mental construct, a language UX construct.

My take on “simplicity” is very computational. To me, a programming language is a system of rules of inference, whose judgments are of the form “program is well-formed” (which covers syntax and type checking) and “program does this at runtime” (a reduction relation, a predicate transformer semantics, or whatever fits your language's dynamics best). Then, simplicity is just some measure of the language's size as a collection of rules of inference. Also:

0. Undecidable rules of inference (e.g., type reconstruction for a Curry-style System F-omega) are considered cheating. Undefined behavior (e.g., C and C++) is also considered cheating. Cheating is penalized by considering the entire language infinitely complex.

1. Languages (e.g., ML's module system) are allowed to be defined by elaboration into other languages (e.g., System F-omega). Elaboration into a language that cheats is considered cheating, though.

> To handle this, I think of "unwieldy" as a bit of a technical term. What does it mean to be unwieldy? It means that there is significant non-ignorable complexity.

I don't see any complexity as ignorable at all. I just see some complexity as worth the price - but you, the programmer, need to be aware that you're paying a price. For instance, the ease with which one can reason about Haskell programs (without the totally crazy GHC extensions) justifies the increased complexity w.r.t., say, Scheme.

> Significant here must be defined almost probabilistically, too. If there is significant complexity which is ignorable across 99/100 real-world uses of a language then it really should win some significant points.

This is ease of use, which is subject to statistical analysis; not simplicity, which is not.

Re: Rob Pike: Simplicity Is Complicated [video]

#128

Post by tel » Thu, Dec 03, 2015, 7:29 PM UTC

catnaroek wrote: post #127

tel wrote: post #94

Earlier quoted context omitted.

So I sort of agree with you here, but only as a partial converse: > If all the formal semantic models for a language are unwieldy then you've probably got a non-simple language. Now, "simplicity" is a mental construct, a language UX construct. To handle this, I think of "unwieldy" as a bit of a technical term. What does it mean to be unwieldy? It means that there is significant non-ignorable complexity. Significant h…

> Now, "simplicity" is a mental construct, a language UX construct. My take on “simplicity” is very computational. To me, a programming language is a system of rules of inference, whose judgments are of the form “program is well-formed” (which covers syntax and type checking) and “program does this at runtime” (a reduction relation, a predicate transformer semantics, or whatever fits your language's dynamics best). T…

I don't want to deny that those "quantitative" measures exist. I want to cast doubt that they're the dominant mechanism for modeling how real people think when they're accomplishing a task in a formal system.

Re: Rob Pike: Simplicity Is Complicated [video]

#129

Post by tel » Thu, Dec 03, 2015, 7:35 PM UTC

pron wrote: post #111

tel wrote: post #100

Earlier quoted context omitted.

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

I don't think at all that "value semantics" without any mention of complexity is an end in and of itself. Any sensible programmer will either (a) intentionally decide that performance is minimally important at the moment (and hopefully later benchmark) or (b) concern themselves also with a semantic model which admits a cost model.

Or, to unpack that last statement, simulate the machine instructions.

I'm never one to argue that a single semantic model should rule them all. Things are wonderful then multiple semantic models can be used in tandem.

But while I'd like to argue for the value of cost models, at this point I'd like to also fight for the value-based ones.

Totality is important not because it has a practical effect. I vehemently agree with how you are arguing here to that end.

It's instead important because in formal systems which ignore it you completely lose the notion of time. Inclusion of non-termination and handling for it admits that there is at least one way which we are absolutely unjustified in ignoring the passage of time: if we accidentally write something that literally will never finish.

It is absolutely a shallow way of viewing things. You're absolutely right to say that practical termination is more important that black-and-white non-termination.

But that's why it's brought up. It's a criticism of certain value-based models: you guys can't even talk about termination!

And then it's also brought up because the naive way of adding it to a theorem prover makes your logic degenerate.

Re: Rob Pike: Simplicity Is Complicated [video]

#130

Post by pron » Thu, Dec 03, 2015, 7:59 PM UTC

tel wrote: post #129

pron wrote: post #111

Earlier quoted context omitted.

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

I don't think at all that "value semantics" without any mention of complexity is an end in and of itself. Any sensible programmer will either (a) intentionally decide that performance is minimally important at the moment (and hopefully later benchmark) or (b) concern themselves also with a semantic model which admits a cost model. Or, to unpack that last statement, simulate the machine instructions. I'm never one to…

> And then it's also brought up because the naive way of adding it to a theorem prover makes your logic degenerate.

Well, I'd argue that disallowing non-termination in your logic doesn't help in the least[1], so you may as well allow it. :) But we already discussed in the past (I think) the equivalence classes of value-based models, and I think we're in general agreement (more or less).

[1]: There are still infinitely many different ways to satisfy the type a -> a (loop once and return x, loop twice, etc. all of them total functions), and allowing (and equating) all of them loses the notion of time just as completely as disallowing just one of them, their limit (I see no justification for assuming a "discontinuity" at the limit).