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

Rob Pike’s Rules of Programming (1989)

cs.unc.edu

Post reply on HN
Print view View original

411–420 of 483 posts

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

#411

Post by jltsiren »

danielmarkbruce wrote: post #407
cjwoodall wrote: post #385

Earlier quoted context omitted.

Rule 3 is still very much real. Fancy fast algorithms often have other trade-offs. The best algorithm for the job is the one that meets all requirements well... Big-O is one aspect, data is another, determinism of the underlying things that are needed (dynamic memory allocation, etc) can be another. It is important to remember that the art of sw engineering (like all engineering) lives in a balance between all these…

Sure but the default (and usually correct) assumption when working at google (as an example) is basically "all numbers are big", so you you have to cluey about algorithms and data structures and not default to brute forcing something. At 99% of shops it should be the other way around .

Even when you are working with large numbers, most numbers are usually small. Most of the code is probably not dealing with the large things, and a large thing may consist of a large number of instances that are individually small.

I've personally found it useful to always have concrete numbers in mind. An algorithm or data structure designed for N will probably be fine for N/10 and 10N, but it will often be inefficient for N/1000 or 1000N.

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

#414

Post by bsder »

IvyMike wrote: post #373

Once upon a time in the 90's I was at work at 2am and I needed to implement a search over a data set. This function was going to be eventually called for every item, thus if I implemented it as a linear search, it would be n^2 behavior. Since it was so late and I was so tired, I marked it as something to fix later, and just did linear search. Later that week, now that things were working, I profiled the n^2 search. T…

The problem with O(n^2) algorithms is that they are fast enough to get into production and slow enough to explode in production.

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

#415

Post by piskov »

> Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil."

This thing never resonated with me.

I often hear it as an excuse to ignore “optimization” at all.

It’s like “broken windows” theory. This allows slop, rot, and technical debt in. And it spreads fast.

Also if everything is unoptimized, this is not what could be easily fixed.

Death of thousand cuts, if you will.

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

#416

Post by wild_egg »

MaxBarraclough wrote: post #404
quietbritishjim wrote: post #378

Earlier quoted context omitted.

I think when he said "just do an array of flat records" he meant as opposed to record of arrays (i.e. row oriented vs column oriented), as opposed to fancy data structures which I think you're assuming he was implying. Separate arrays for each data member are common in game engines exactly because they're good for iterating over, which as you said is common.

Jonathan Blow's own unreleased Jai programming language has a feature to make it trivial to switch between array-of-structs and struct-of-arrays. From a quick search, it seems HackerNews's own jcelerier has put together a C++ library for doing this. https://github.com/celtera/ahsohtoa

Zig also makes this trivial

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

#417

Post by zahlman »

Someone wrote: post #287
anymouse123456 wrote: post #93

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all evil." First, let's not besmirch the good name of Tony Hoare. The quote is from Donald Knuth, and the missing context is essential. From his 1974 paper, "Structured Programming with go to Statements": "Programmers waste enormous amounts of time thinking about,…

> From his 1974 paper, "Structured Programming with go to Statements": > He was talking about using GOTO statements in C. I don’t think he was talking about C. That paper is from December 1974, and (early) C is from 1972, and “The UNIX Time-Sharing System” ( https://dsf.berkeley.edu/cs262/unix.pdf ) is from July 1974, so time wise, he could have known C, but AFAICT that paper doesn’t mention C, and the examples are P…

Yes, just like in Dijkstra's earlier (1968) "Go To Statement Considered Harmful". The syntax is not C and "go to" is two words, and of course that's definitely too early.

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

#418

Post by jasonwatkinspdx »

nlawalker wrote: post #293

This reminds me of a portion of a talk Jonathan Blow gave[1], where he justifies this from a productivity angle. He explains how his initial implementation for virtually everything in Braid used arrays of records, and only after finding bottlenecks did he make changes, because if he had approached every technical challenge by trying to find the optimal data structure and algorithm he would never have shipped. "There'…

That's very much the norm in the game dev world, especially for someone like Jonathan who's been doing this since the early era of PC gaming.

You've got 16 ms to get that next frame rendered, so stuffing everything into fixed sized tables and linear walks is a simple way to structure against that limit. You've got an entity budget of so many, and there's no unpredictable delays from dynamic allocation or similar.

Even when using scripting languages that offer more flexibility, like LUA or C#, you see a tendency towards this pattern.

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

#419

Post by jjmarr »

awesome_dude wrote: post #410
wat10000 wrote: post #400

Earlier quoted context omitted.

For every game like that, there are a thousand games that shipped, maybe got a few updates, and then they were done.

We can probably add to that the fact that the nominated titles almost certainly started out with spaghetti code that had to be refactored, reworked, and gave maintainers nightmares in their sleep

Roblox didn't have server functions until 2014 and they weren't mandatory until 2018. Anything the client did automatically replicated to every other client.

That meant I could attach Cheat Engine to Roblox, edit memory addresses to give myself in-game cash, and inject whatever code I wanted to everyone else.

Thankfully it was sandboxed so I couldn't give people viruses.

This was probably a good decision because most of Roblox's best games from that period weren't updated to use server functions. It's too difficult.

Post reply on HN