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

131–140 of 152 posts

Re: Rob Pike: Simplicity Is Complicated [video]

#131

Post by catnaroek »

tel wrote: post #92
pron wrote: post #87

Earlier quoted context omitted.

> 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 "effec…

Purity can be defined very nicely against the arrows in a compositional semantics of a language and then effects follow as reasons for impurity. This is absolutely just a choice. It all ends up depending upon how you define equality of arrows. You could probably even get weirder notions of purity if you relax equality to a higher-dimensional one. So, it's of course arbitrary in the sense that you can just pick whatev…

I don't agree with pron overall, but he does have a point. Termination and algorithmic complexity do matter, and the techniques Haskell programmers advocate for reasoning about programs have a tendency to sweep theese concerns under the rug. This is in part why I've switched to Standard ML, in spite of its annoyances: No purity, higher kinds, first-class existentials or polymorphic recursion. And no mature library ecosystem. But I get a sane cost model for calculating the time complexity of algorithms. And, when I need laziness, I can carefully control how much laziness I want. Doing the converse in Haskell is much harder, and you get no help whatsoever from the type system.

As an example, consider the humble cons list type constructor. Looks like the free monoid, right? Well, wrong. The free monoid is a type constructor of finite sequences, and Haskell lists are potentially infinite. But even if we consider only finite lists, as in Standard ML or Scheme, the problem remains that, while list concatenation is associative, it's much less efficient when used left-associatively than when used right-associatively. The entire point to identifying a monoid structure is that it gives you the freedom to reassociate the binary operation however you want. If using this “freedom” will utterly destroy your program's performance, then you probably won't want to use this freedom much - or at least I know I wouldn't. So, personally, I wouldn't provide a Monoid instance for cons lists. Instead, I would provide a Monoid instance for catenable lists. [0]

By the way, this observation was made by Stepanov long ago: “That is the fundamental point: algorithms are defined on algebraic structures.” [1] This is the part Haskellers acknowledge. Stepanov then continues: “It took me another couple of years to realize that you have to extend the notion of structure by adding complexity requirements to regular axioms.” [1]

Of course, none of this justifies pron's suspicion of linguistic models of computation.

[0] http://www.westpoint.edu/eecs/SiteAssets/SitePages/Faculty%2...

[1] http://stlport.org/resources/StepanovUSA.html

Re: Rob Pike: Simplicity Is Complicated [video]

#132

Post by pron »

catnaroek wrote: post #131
tel wrote: post #92

Earlier quoted context omitted.

Purity can be defined very nicely against the arrows in a compositional semantics of a language and then effects follow as reasons for impurity. This is absolutely just a choice. It all ends up depending upon how you define equality of arrows. You could probably even get weirder notions of purity if you relax equality to a higher-dimensional one. So, it's of course arbitrary in the sense that you can just pick whatev…

I don't agree with pron overall, but he does have a point. Termination and algorithmic complexity do matter, and the techniques Haskell programmers advocate for reasoning about programs have a tendency to sweep theese concerns under the rug. This is in part why I've switched to Standard ML, in spite of its annoyances: No purity, higher kinds, first-class existentials or polymorphic recursion. And no mature library ec…

> Of course, none of this justifies pron's suspicion of linguistic models of computation.

Of course. :)

But my view stems from the following belief that finally brings us back to your original point and my original response: there can be no (classical) mathematical justification to what you call linguistic models of computation because computation is not (classical) math, as it does not preserve equality under substitution. The implication I draw from this is not quite the one you may attribute to me such as an overall suspicion, complete rejection or dismissal of those models, but the recognition that their entire justification is not mathematical but pragmatic, and that means that the very same (practical) reasons that might make us adopt the (leaky) abstraction of those models, might lead us to adopt (or even prefer) other models that are justified by pragmatism alone -- such as empirical results showing a certain "affinity" to human cognition -- even if they don't try to abstract computation as classical math.

Re: Rob Pike: Simplicity Is Complicated [video]

#133

Post by catnaroek »

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…

If Go works for you, all the more power to you.

When I tried Go, things went like this: First, I deliberately wrote a program with a data race, which the data race detector didn't detect. Then, I honestly tried to write a race-free program, and again the data race detector didn't complain. A couple of hours later, I realized that the second program also contained a data race.

Re: Rob Pike: Simplicity Is Complicated [video]

#134

Post by catnaroek »

pron wrote: post #132
catnaroek wrote: post #131

Earlier quoted context omitted.

I don't agree with pron overall, but he does have a point. Termination and algorithmic complexity do matter, and the techniques Haskell programmers advocate for reasoning about programs have a tendency to sweep theese concerns under the rug. This is in part why I've switched to Standard ML, in spite of its annoyances: No purity, higher kinds, first-class existentials or polymorphic recursion. And no mature library ec…

> Of course, none of this justifies pron's suspicion of linguistic models of computation. Of course. :) But my view stems from the following belief that finally brings us back to your original point and my original response: there can be no (classical) mathematical justification to what you call linguistic models of computation because computation is not (classical) math, as it does not preserve equality under substi…

> because computation is not (classical) math

Of course, computation is more foundational. It's mathematics that's just applied computation.

> as it does not preserve equality under substitution

You just need to stop using broken models.

> but the recognition that their entire justification is not mathematical but pragmatic

I don't see a distinction. To me, nothing is more pragmatic to use than a reliable mathematical model.

> the (leaky) abstraction of those models

Other than the finiteness of real computers, what else is leaky? Mind you, abstracting over the finiteness of the computer is an idea that even... uh... “less mathematically gifted” languages (such as Java) acknowledge as good.

> such as empirical results showing a certain "affinity" to human cognition

Experience shows that humans are incapable of understanding computation at all. But computation is here to stay, so the best we can do is rise to the challenge. Denying the nature of computation is denying reality itself.

Re: Rob Pike: Simplicity Is Complicated [video]

#135

Post by pron »

catnaroek wrote: post #134
pron wrote: post #132

Earlier quoted context omitted.

> Of course, none of this justifies pron's suspicion of linguistic models of computation. Of course. :) But my view stems from the following belief that finally brings us back to your original point and my original response: there can be no (classical) mathematical justification to what you call linguistic models of computation because computation is not (classical) math, as it does not preserve equality under substi…

> because computation is not (classical) math Of course, computation is more foundational. It's mathematics that's just applied computation. > as it does not preserve equality under substitution You just need to stop using broken models. > but the recognition that their entire justification is not mathematical but pragmatic I don't see a distinction. To me, nothing is more pragmatic to use than a reliable mathematica…

> You just need to stop using broken models.

No computation preserves equality under substitution. If your model assumes that equality, it is a useful, but leaky abstraction.

> Other than the finiteness of real computers, what else is leaky?

The assumption of equality between 2 + 2 and 4, which is true in classical math but false in computation (if 2+2 were equal to 4, then there would be no such thing as computation, whose entire work is to get from 2 + 2 to 4; also, getting from 2+2 to 4 does not imply the ability to get from 4 to 2+2).

> Experience shows that humans are incapable of understanding computation at all.

Experience shows that humans are capable of creating very impressive software (the most impressive exemplars are almost all in C, Java etc., BTW).

Re: Rob Pike: Simplicity Is Complicated [video]

#136

Post by slowmovintarget »

catwell wrote: post #61
LaPingvino wrote: post #2

There are several points where he won't mention the language. Which languages do you think he meant?

Probably C++ or Java (Go was written to replace them at Google).

The first mention sounded like C++. For verbosity (second mention), I'd guess Java. The third mention sounded like JavaScript where he said something to the effect of unexpected tangling, but those are guesses based on what Google uses and Rob's brief description.

Re: Rob Pike: Simplicity Is Complicated [video]

#137

Post by catnaroek »

pron wrote: post #135
catnaroek wrote: post #134

Earlier quoted context omitted.

> because computation is not (classical) math Of course, computation is more foundational. It's mathematics that's just applied computation. > as it does not preserve equality under substitution You just need to stop using broken models. > but the recognition that their entire justification is not mathematical but pragmatic I don't see a distinction. To me, nothing is more pragmatic to use than a reliable mathematica…

> You just need to stop using broken models. No computation preserves equality under substitution. If your model assumes that equality, it is a useful, but leaky abstraction. > Other than the finiteness of real computers, what else is leaky? The assumption of equality between 2 + 2 and 4, which is true in classical math but false in computation (if 2+2 were equal to 4, then there would be no such thing as computation…

> The assumption of equality between 2 + 2 and 4, which is true in classical math but false in computation

Using Lisp syntax, you are wrongly conflating `(+ 2 2)`, which is equal to `4`, with `(quote (+ 2 2))`, which is obviously different from `(quote 4)`. Obviously, a term rewriting approach to computation involves replacing syntax objects with syntactically different ones, but in a pure language, they will semantically denote the same value.

Incidentally:

0. This conflation between object and meta language rôles is an eternal source of confusion and pain in Lisp.

1. Types help clarify the distinction. `(+ 2 2)` has type `integer`, but `(quote (+ 2 2))` has type `abstract-syntax-tree`.

> very impressive software

For its lack of conceptual clarity. And for its bugs. I'm reduced to being a very conservative user of software. I wouldn't dare try any program's most advanced options, for fear of having to deal with complex functionality implemented wrong.

Re: Rob Pike: Simplicity Is Complicated [video]

#138

Post by catnaroek »

ZenoArrow wrote: post #99
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 you want an alternative explanation for simplicity, I'd say simplicity implies flexibility. Designing a simple implementation of something means that it is as close to the essence of what you've designed it for, and by doing so you've made it more universal, and therefore more flexible/adaptable.

This would work if compilers were written in simple languages, and if target languages themselves were simple. In other words, in a parallel universe.

Re: Rob Pike: Simplicity Is Complicated [video]

#139

Post by tbrownaw »

lomnakkus wrote: post #26
pcwalton wrote: post #20

Earlier quoted context omitted.

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

Not really... the wasted time is still all malloc() / realloc() / whatever under array.push(), and a half-decent callgraph profiler will catch that. array.push() will score far higher than it ought to, and the bulk of its time will be the reallocation.

Source: I've used oprofile, and later perf, to hunt exactly this kind of performance bug.

.

Of course, fixing a pervasive issue like that is much more tedious than just finding it. :-(

Re: Rob Pike: Simplicity Is Complicated [video]

#140

Post by pron »

catnaroek wrote: post #137
pron wrote: post #135

Earlier quoted context omitted.

> You just need to stop using broken models. No computation preserves equality under substitution. If your model assumes that equality, it is a useful, but leaky abstraction. > Other than the finiteness of real computers, what else is leaky? The assumption of equality between 2 + 2 and 4, which is true in classical math but false in computation (if 2+2 were equal to 4, then there would be no such thing as computation…

> The assumption of equality between 2 + 2 and 4, which is true in classical math but false in computation Using Lisp syntax, you are wrongly conflating `(+ 2 2)`, which is equal to `4`, with `(quote (+ 2 2))`, which is obviously different from `(quote 4)`. Obviously, a term rewriting approach to computation involves replacing syntax objects with syntactically different ones, but in a pure language, they will semanti…

> Using Lisp syntax, you are wrongly conflating `(+ 2 2)`, which is equal to `4`

It is not equal to 4; it computes to 4. Substituting (+ 2 2) for 4 everywhere yields a different computation with a different complexity.

> but in a pure language, they will semantically denote the same value.

The same value means equal in classical math; not in computation. Otherwise (sort '(4 2 3 1)) would be the same as '(1 2 3 4), and if so, what does computation do? We wouldn't need a computer if that were so, and we certainly wouldn't need to power it with so much energy or need to wait long for it to solve the traveling salesman problem.

> For its lack of conceptual clarity. And for its bugs.

That's a very glass-half-empty view. I for one think that IBM's Watson and self-driving cars are quite the achievements. But even beyond algorithmic achievements and looking at systems, software systems that are successfully (and continuously) maintained for at least a decade or two are quite common. I spent about a decade of my career working on defense software, and that just was what we did.

Post reply on HN