Heh, in the early days of C++ (1990ish) I had a notable application of 3+4 involving a doubly linked list with cache pointers (time-sequence data browser so references were likely "nearby" as the user zoomed in; spec was to handle streaming data eventually.) Had problems with it crashing in pointer-related ways (in 1990, nobody had a lot of C++ experience) so I cooked up a really dumb "just realloc an array" version so I could figure out if the problem was above or below data structure... and not only didn't the "dumb" version crash, it was also much faster (and of faster order!) due to amortized realloc - doing a more expensive operation much less often turns out to be a really good trick :-)
Rob Pike’s Rules of Programming (1989)
391–400 of 483 posts
Re: Rob Pike’s Rules of Programming (1989)
#392[dead]
Re: Rob Pike’s Rules of Programming (1989)
#393Earlier quoted context omitted.
This is slightly surprising to me, since Braid is kinda infamous for being in development for a pretty long time for a puzzle platformer
Was 3 years a long time for an indie platformer in the early 2000s? Looking at some similar examples: * Braid was 3 years * Cave Story was 5 years * World of Goo was 2 years * Limbo was about 3 years (but with 8-16 people) So Braid seems pretty average.
Yeah, you’re right. I must’ve misremembered.
Re: Rob Pike’s Rules of Programming (1989)
#394Earlier quoted context omitted.
I'd be careful extending learnings from games (solo or team efforts) to general programming as the needs and intent seem to be so different. We rarely see much code re-use in games outside of core, special-purpose buy largely isolated components and assets. Outside of games there's a much bigger emphasis on the data IME, and performance is often a nice-to-have.
Yeah - A game is (generally) a one and done enterprise. Like a start up it's all about getting it out the door, there's little to no expectation of having to maintain it for any real length of time.
HN has some hot takes but that one is particularly impressive.
Fortnite, Roblox, League of Legends, Counter Strike . . . all very short term projects.
Re: Rob Pike’s Rules of Programming (1989)
#395Worth noting these were not written as rules of programming generally but rules specifically targeted at complexity. They are lifted from the "Complexity" section of Rob's "Notes on Programming in C".
https://www.lysator.liu.se/c/pikestyle.html http://www.literateprogramming.com/pikestyle.pdf
Re: Rob Pike’s Rules of Programming (1989)
#396Rule 3 gets me into trouble with CS majors a lot. I'm an EE by education and entered into SW via the bottom floor(embedded C/ASM) so it was late in my career before I knew the formal definition of big-O and complexity. For most of my career, sticking to rule 3 made the most sense. When the CS major would be annoying and talk about big-O they usually forgot n was tiny. But then my job changed. I started working on dif…
Well it is hedged with the word "fancy". I think a charitable reading is to understand the problem domain. If N is always small then trying to minimize the big-O is just showing off and likely counterproductive in many ways. If N is large, it might be a requirement. Most people don't need FFT algorithm for multiplying large numbers, Karatsuba's algorithm is fine. But in some domains the difference does matter. Person…
> Personally I usually see the opposite effect - people first reach for a too-naive approach and implement some O(n^2) algorithm where it wouldn't have even been more complex to implement something O(n) or O(n log n). And n is almost always small so it works fine, until it blows up spectacularly.
Same. People solve in ways that are very obviously going to cause serious problems in only a few short weeks or months and it’s endlessly frustrating. If you’re building a prototype, fine, but if you’re building for production, very far from fine.
Most frustrating because often there’s next to no cost in selecting and implementing the correct architecture, domain model, data structure, or algorithm up front.
Re: Rob Pike’s Rules of Programming (1989)
#397[flagged]
> In practice what I see fail most often is not premature optimization but premature abstraction. Compare and contrast https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf
Philip Wadler gave us a sound type system. Rob Pike gave us a programming language for stupid people. Each contributed in their own way, towards different goals.
Re: Rob Pike’s Rules of Programming (1989)
#398[dead]
Re: Rob Pike’s Rules of Programming (1989)
#399Earlier quoted context omitted.
Seems like one is backpedaling because one was just talking about one's separation of one's concerns and now one is defending one's separation of concerns with respect to one's global data structure.
I still firmly believe that one ctx object and hundred functions/methods is as bad as programming with plain variables defined in the global scope. If the ctx is composed from smaller data structures with whom the functions are defined, then all is good. This is the opposite of the rule.
But why?
You keep saying you believe it, but that is literally what a database is, game state manipulation, string manipulation, iterator algorithms, list comprehensions, range algorithms, image manipulations, etc. These are all instances where you use the same data structures over and over with as many algorithms and functions and you need.
Re: Rob Pike’s Rules of Programming (1989)
#400Earlier quoted context omitted.
Yeah - A game is (generally) a one and done enterprise. Like a start up it's all about getting it out the door, there's little to no expectation of having to maintain it for any real length of time.
HN has some hot takes but that one is particularly impressive. Fortnite, Roblox, League of Legends, Counter Strike . . . all very short term projects.
For every game like that, there are a thousand games that shipped, maybe got a few updates, and then they were done.