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

101–110 of 122 posts

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

#101

Post by djur »

smegel wrote: post #63
rdiddly wrote: post #53

Earlier quoted context omitted.

In terms of programmer time/effort, using .Get() is simpler. In terms of program speed/optimization, the answer depends on how .Get() is implemented.

Writing simple programs that meets requirements should be your goal. Premature optimization is the root of all evil.

Selecting appropriate data structures and algorithms for a problem is not optimization. It's one of the basic skills and responsibilities of a programmer. That's why the bulk of the first volume of Knuth's _The Art of Computer Programming_ is about data structures.

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

#102

Post by rjeli »

JBiserkov wrote: post #71
gue5t wrote: post #25

Earlier quoted context omitted.

How is a for-loop not a fold?

A fold is usually restricted to a combining function of 2 arguments - accumulated-so-far and current item. A for-loop's body has no such restrictions, it can access any number of neighbor elements if the algorithm so requires. a[i] = a[i-1] * a[i+1]

A for loop is a fold over the local context and the index

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

#103

Post by vvanders »

hasenj wrote: post #93
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…

Rule 5 is where dynamic languages usually utterly fail.

C# is one of the few ones to have value types, but yeah in general they really suck for controlling memory access patterns and layout.

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

#104

Post by gavinpc »

hasenj wrote: post #93
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…

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 powerful in a way, because of the impossibility of typing everything. This means it's likely to get things like variadic generics or higher-kinded types long before C#, since (1) in C# everything has to be typed down to the smallest particle (so it's much harder to add features), and (2) changes to the CLR would be needed.

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

#105

Post by pdpi »

winterlight wrote: post #51
whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

Ironically, in that situation, using a list might end up being more efficient due to cache locality. Or not. That's why measuring is so important, since performance can be a very counterintuitive subject. Hard-data should always prevail over theory and guesswork.

Vector or array? Sure. List is worst of both worlds

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

#106

Post by inimino »

eternalban wrote: post #52
threatofrain wrote: post #37

The sum of these rules seem to imply that it's difficult to theoretically model programming, so always wait for your program to be fully written so you can perform some brute force empiricism -- and only then think about performance.

It is not true that you can not "theoretically" (read: based on formal reasoning) model program performance. You don't need to run a program to determine that an O(n^2) approach will be slower than an O(log n) algorithm. You do not need to run a program to determine the impact of optimizing a bit of your para code; you can get fairly good sense using Amdahl's law. Etc. Like his creation, the Go language, Rob Pike's r…

> You don't need to run a program to determine that an O(n^2) approach will be slower than an O(log n) algorithm.

That depends on N and on the constant factors. Which means testing still might surprise you.

More to the point, if the O(n^2) algorithm is simpler and leaves you more time for profiling and fixing actual performance issues after the code works, you may end up with faster code by doing the dumb thing.

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

#107

Post by inimino »

fergazen wrote: post #6

These are not "Rules of Programming", but are excellent "Guidelines for Performance". Having 30yrs under my belt I have come to all the same conclusions as Rob Pike over my years, so these are very deserving of some serious contemplation for those with In my current job we have lots of large and often 'sparsely populated' objects which means basically you can never count on any of the properties you were hoping would…

I'm wondering what on earth "large and often sparsely populated objects" has to do with functional programming, could you elaborate on that?

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

#108

Post by kornish »

analog31 wrote: post #77
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."

I wrote in Pascal for many years. Trust me, I can design data structures that will baffle the greatest scholars of the ages. ;-) I found one of my old codes, a few months ago, and I'm still trying to figure out what possessed me to write it.

Is that better than the alternative, though, which is not designing data structures?

Essential complexity [1] is still complexity. It has to exist somewhere; you just get to choose how to move it around.

[1]: http://wiki.c2.com/?EssentialComplexity

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

#109

Post by tatterdemalion »

jzelinskie wrote: post #88
tatterdemalion wrote: post #49

Earlier quoted context omitted.

Or Go.

In Go, it's idiomatic to use map[T]struct{} for a HashSet. In fact, the compiler optimises struct{} so that it doesn't even allocate.

This is also how HashSet is implemented in Rust (internally its a HashMap, and zero sized structs are optimized out just like Go).

But by providing a set type, Rust is able to provide for users various set operations which Go requires you to write by hand. It becomes hard to argue that a set is simpler than a slice when you have to write your own methods dealing with union, disjunction, intersection, difference, subsets/supersets, etc every time.

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

#110

Post by lngnmn »

> Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

This is especially beautiful insight giving that it has a parallel with molecular biology - proteins and other molecular structures dominate. Enzymes are made of "standard" proteins to transform particular molecular structures.

This, BTW, is also related to usually overlooked the "code is data" principle.

To be a good programmer one has to know molecular biology 101. It seems like good guy (John McCarthy, MIT Wizards, Bell labs and Erlang guys) did.

Post reply on HN