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

111–120 of 122 posts

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

#111

Post by millstone »

gavinpc wrote: post #104
hasenj wrote: post #93

Earlier quoted context omitted.

Rule 5 is where dynamic languages usually utterly fail.

In twenty-five years as a working programmer, I have fallen in love with a piece of technology four times: Emacs (on my third attempt), Tup (the build system by Mike Shal), React... and now TypeScript. I've been using it full-time for a few weeks now, and I can't imagine going back. If you like rule 5... you'll heart TypeScript. Edit : I also spent ~12 years writing C# which is good. But TypeScript is actually more p…

When you say "going back" - going back to what? I mean, is a language where all array keys are strings really the best platform for higher-kinded types?

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

#112

Post by dvirsky »

Rule 3 is even more important today, with modern CPU cache. Running a simple O(n) scan of a (small-ish) bunch of integers (and often strings) will be significantly faster than storing them in some map or even binary search in some cases.

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

#113

Post by freyir »

glangdale wrote: post #79

Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't. Rule 2 only applies if you can just decide that your current level of performance is "pretty great" and then parachute away to another project. Otherwise if you find that, instead of 1 hot spot taking 80% of your time, you have 5 warm spots taking 16% of your time, you have 5…

In this context, a "buggier" algorithm is one that is more prone to bugs.

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

#114

Post by glangdale »

freyir wrote: post #113
glangdale wrote: post #79

Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't. Rule 2 only applies if you can just decide that your current level of performance is "pretty great" and then parachute away to another project. Otherwise if you find that, instead of 1 hot spot taking 80% of your time, you have 5 warm spots taking 16% of your time, you have 5…

In this context, a "buggier" algorithm is one that is more prone to bugs.

I can grasp the underlying point here (more code and more complex code both increase the chance you'll have a bug).

Again, this seems a bit like the assumption behind Rule 2 - that the time spent in figuring out the complex algorithm and ensuring it is bug free is not worth spending (just like saying "oh, it's not worth smashing a hot spot if it's only 20%). This will frequently be true, but not always. I suspect that most people would be happier to use OS schedulers, TCP implementations and compilers (to name a few things) written by people who don't get to "parachute out" when the easy solutions are exhausted.

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

#115

Post by mac01021 »

punnerud wrote: post #76

A prox what was said in the book Rework; If we add 1000 more professors and expand to more cities Harvard/MIT/Stanford would be a better school. Everyone laught of this, why do we still think it is a good thing for a company? Start small, fix while you go and keep a customer focus (not growth focus in both company size and software complexity)

I can't speak for Harvard/MIT/Stanford, but the top-tier administrators at my state's flagship university would probably love to be able to engage in that kind of expansion.

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

#116

Post by baq »

drostie wrote: post #8

I think #5, which is probably going to be thought of as great wisdom for our age, is secretly an empty tautology. That is, my amateurish work in schemas and validating data structures and type systems has led me to think that there is a somewhat hard-to-see but extremely-important bijection between data structures and the control structures that consume them. (In many ways this is theoretically a non-issue as there a…

algorithms + data structures = programs. literally the title of a classic CS book.

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

#117

Post by gavinpc »

millstone wrote: post #111
gavinpc wrote: post #104

Earlier quoted context omitted.

In twenty-five years as a working programmer, I have fallen in love with a piece of technology four times: Emacs (on my third attempt), Tup (the build system by Mike Shal), React... and now TypeScript. I've been using it full-time for a few weeks now, and I can't imagine going back. If you like rule 5... you'll heart TypeScript. Edit : I also spent ~12 years writing C# which is good. But TypeScript is actually more p…

When you say "going back" - going back to what? I mean, is a language where all array keys are strings really the best platform for higher-kinded types?

Going back to untyped JS of course. It's not about having "the best" platform for types—that's just the point. TypeScript's system is incomplete, but it's plenty good enough to dramatically improve the experience. The tooling is now much more powerful. The type contracts also provide a whole new channel of formal communication between team members, not to mention unknown users if you're developing libraries. And it's just way more fun. It's a rewarding challenge to write the most expressive types that you can for the problem you're solving. But you don't have to. If you want to start by writing data types and then fulfilling them, you can. If you want to start by writing code and then typing it, you can. It's brilliantly designed to fit with all kinds of idiomatic JavaScript. The language server provides fast incremental compilation and integrates easily with all major editors. Structural typing means you can define types in-place and conform to interfaces that haven't been written yet. The type system's features are impressive and growing, including generics (with constraints and defaults), tagged unions, mapped types, guard conditions and flow control analysis.

It's not "the best" of both worlds, but it is both worlds. What other language is as "gelatinous" as JavaScript [0] but still gives you state-of-the-art type inference when you want it? Hack? [1] I don't know, but it's the same value proposition.

[0] https://news.ycombinator.com/item?id=13942674

[1] http://hacklang.org/

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

#118

Post by hyperpape »

khedoros1 wrote: post #47
hyperpape wrote: post #10

"Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Everything about reading this quote depends on what you think a "speed hack" is. Without practical agreement on that, you'll get a lot of people arguing past each other.

I'd say "a modification to the code designed to speed up that section of code". Are there other reasonable definitions? I thought it was pretty clear that the rule could be accurately paraphrased as "Don't optimize a section for speed until you're sure that's where it's needed."

Maybe. But are you saying you can't pull a method invocation you know will return the same value every time outside of a loop without profiling? I doubt Rob Pike believes that. Which leaves us with saying this is a rule of thumb, or what a speed hack is requires more commentary.

I'm ok with a rule of thumb. I just want to point out that they leave a lot of room for disagreement and that the most important part may end up being how you apply the rule in particular cases.

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

#119

Post by kazinator »

jonahx wrote: post #4

Torvalds version of rule 5: “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Brooks's version: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."

Unfortunately, it is nonsense, in large part.

Not all algorithms are obvious from a picture of the data structure, otherwise we wouldn't need computer science at all.

No, you won't spontaneously invent a minimax search with alpha-beta pruning if you're just show the picture of the game tree with board positions.

Some of the "low-hanging fruit" is obvious, but that's about it.

In the other direction, some algorithms are abstract; the same structure will work for more than one data structure. Sometimes the process is important, not the low level representational pieces. E.g. "map reduce".

Gee, don't show me "map reduce"; I need to see the servers and requests! No wait, I mean linked lists and atoms, ...

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

#120

Post by diedyesterday »

Programming language 'sages' tend to blurt out these generalizations, although they are based on insights which are only PARTIALLY determinant.

Many advanced ('fancy', if you will) algorithms are based on mathematical proofs and relations, which are seldom obvious. Some of them have taken hundreds of years to reach proof and be capable of being used as a theorem.

If all we needed were 'obvious' algorithms we would have hardly solved any real-world non-rudimentary problems with computation.

Post reply on HN