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

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

51–60 of 332 posts

Re: Rob Pike’s Rules of Programming (1989)

#51

Post by mywittyname »

dnautics wrote: post #27
mywittyname wrote: post #11

> "write stupid code that uses smart objects". Writing stupid code is actually really difficult. For me, it takes a little bit of iterating before I know just the right place to insert stupid.

Do you use TDD? I'm not religious about it in general, but when I'm lost, confused, and easily distracted, I start with TDD to write the dumbest possible code.

No.

It's really an issue of not being sure at first what needs to be flexible & data-driven vs handled in code. If make everything data driven, then it becomes this horrible mess where your input is basically a program and your actual code ends up being a terrible interpreter.

I tend to just build things bottom-up, and start with a small bit of functionality, then when I have enough small bits, I bolt them together and decide what I need to abstract at that point, do refactoring on the smaller bits and provide data to them from the caller. Then repeat that continuously until I have all of the functionality I need.

It might be different for other people, but I need to have working code before I can it abstract.

Re: Rob Pike’s Rules of Programming (1989)

#52

Post by _urga »

nix23 wrote: post #47
sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

That's a bit broad i think, talking about pure speed of your task you are right, talking about energy consumption then it's not always the case. Or small but often repeated task should be optimized no mater if they are bottlenecks, when the system grows they will become bottlenecks, optimize like a Vulcan is what my boss once said...be logical and nothing else (my interpretation)

"optimize like a Vulcan"... classic!

Re: Rob Pike’s Rules of Programming (1989)

#54

Post by nix23 »

chubot wrote: post #46
NewEntryHN wrote: post #42

Earlier quoted context omitted.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

Except that there are infinite such non-bottlenecks, and all the effort you spend on there is effort not spent on the real bottlenecks. In other words, all engineering is time- and cost-constrained. Anybody can build a good chair for $10,000 or a good PC for $100,000. Doesn't mean it's good engineering.

>not spent on the real bottlenecks

BE LOGICAL! Of course you first fix the big bottlenecks.

>good PC for $100,000. Doesn't mean it's good engineering.

Of course it is...or can you gold platter a pc case?

Re: Rob Pike’s Rules of Programming (1989)

#55

Post by lliamander »

skybrian wrote: post #38
lliamander wrote: post #9

Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…

But adding floating point numbers isn't associative, in general. Sometimes you need to do it the right way to avoid catastrophic cancellation. I guess the key is to know how to deal with things that are only mostly true.

That's true about floating point numbers. I assume that depending upon the context, it may not be a big issue (e.g. GPU compute)?

In any case, the point Stepanov was making is that if you want to be able to use a certain algorithm, then you have to make a choice to represent your data in a way that enables that algorithm, and the way you know whether the structure is appropriate for that algorithm is the algebraic properties of the structure.

Re: Rob Pike’s Rules of Programming (1989)

#56

Post by dllthomas »

kens wrote: post #39
lliamander wrote: post #9

Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…

In case you've wondered what a monoid is, that's a monoid. Something with an associative operation (and an identity), so you can do the operation on chunks in parallel, like addition.

Every monoid is a semigroup, but it's only a monoid if there is also a value that serves as an identity.

Re: Rob Pike’s Rules of Programming (1989)

#57

Post by ChrisMarshallNY »

I've always taken a very practical, results-oriented approach to software development.

That makes sense, to me.

One of the first things that we learned, when optimizing our code, was to use a profiler.

Bottlenecks could be in very strange places, like breaking L2 caches. That would happen when data was just a bit too big, or a method was called; forcing a stack frame update.

We wouldn't see this kind of thing until we looked at a profiler; sometimes, a rather advanced one, provided by Intel.

Re: Rob Pike’s Rules of Programming (1989)

#58

Post by mamcx »

chubot wrote: post #13
jonfw wrote: post #2

"Write stupid code that uses smart objects" That's a good one. It's amazing how much complexity can be created by using the wrong abstractions.

FWIW I find this is especially important for compilers and interpreters. It's not an exaggeration to say that such programs are basically big data structures, full of compromises to accomodate the algorithms you need to run on them. For example LLVM IR is just a big data structure. Lattner has been saying for awhile that a major design mistake in Clang is not to have its own IR (in the talks on the new MLIR project).…

> FWIW I find this is especially important for compilers and interpreters.

Totally. I'm building a relational language and start to get very obvious why RDBMS not fit certain purity ideals of the relational model (like all relations are sets, not bags).

I'm stuck in deciding which structures provide by default. Dancing between flat vectors or ndarrays or split between flat vectors (columns), and HashMaps/BTree with n-values (this is my intuition now).

--- > I added some nice properties that algebraic data types in some language don't have, e.g. variants are "first class" unlike in Rust.

This sound cool, where I can learn about this?

Re: Rob Pike’s Rules of Programming (1989)

#59

Post by dllthomas »

lliamander wrote: post #44
kens wrote: post #39

Earlier quoted context omitted.

In case you've wondered what a monoid is, that's a monoid. Something with an associative operation (and an identity), so you can do the operation on chunks in parallel, like addition.

Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).

While true, that's too strict. An Abelian group (like any group) needs inverses. You get distributed computation if you've got an Abelian semigroup.

Re: Rob Pike’s Rules of Programming (1989)

#60

Post by nurettin »

These rules look silly when you know that your tight loop that waits for IO or redundantly computes things needs caching. No, you don't need to measure that, and you know that your tight loop function is going to be the bottleneck. Everyone knows that.

Now it does make sense when you introduce an entire constraint library instead of looping over 3-4 variables with a small search space. But again, you know it is a small search space. You know you don't have to optimize it.

I really don't get these rules.

Edit: Go ahead and roast me, but keep in mind I've probably been there and back.

Post reply on HN