"N is usually small" might need to be revisited.
Rob Pike’s Rules of Programming (1989)
451–460 of 483 posts
Re: Rob Pike’s Rules of Programming (1989)
#452[flagged]
> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.
Some abstractions are obvious though. There is value in reusing them across projects and not reinventing the wheel each time. I don’t think this is counter to what you propose necessarily, just adding the nuance that abstractions serve another purpose: communicating intent to the readers of the code. Sometimes a concrete type is unnecessary detail.
Re: Rob Pike’s Rules of Programming (1989)
#453Earlier quoted context omitted.
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
I believe you. Can you provide a simple example? I would be helpful for me to understand.
Re: Rob Pike’s Rules of Programming (1989)
#454This 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'…
It's also notable that video games are programs that run for hours and iterate over large sets of very similar entities at 60 frames or more per second repeatedly and often do very similar operations on each of the entities. That also means that "just do an array of flat records" is a very sane default even if it seems brutish at first.
I would like to add that Braid is not a normal video game.
To me, it is a piece of art. It contains so many mind-bending mechanics that I think it is a real possibility that you could have worked on some of that stuff for years, making it unlikely to ship at all.
So, in addition to the performance requirements of a video game, Jonathan also had to find ways to implement all those fancy mechanics.
Re: Rob Pike’s Rules of Programming (1989)
#455Earlier quoted context omitted.
> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.
Some abstractions are obvious though. There is value in reusing them across projects and not reinventing the wheel each time. I don’t think this is counter to what you propose necessarily, just adding the nuance that abstractions serve another purpose: communicating intent to the readers of the code. Sometimes a concrete type is unnecessary detail.
Absolutely. I don't take that quote to mean we should all start from ground zero every time...if so experience wouldn't have much value.
I more think the point is that the abstractions now obvious to you emerged at some earlier point that you now recognize, and application makes sense. Speculative implies predicting, and if you've been around long enough in the same domain, it's likely you aren't guessing.
It's probably something that applies more to younger devs than older, but not exclusively of course.
Re: Rob Pike’s Rules of Programming (1989)
#456[flagged]
> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.
But they should emerge right when they are needed, not some time later via a painful refactor.
I think every dev lives in fear of the situation where abstraction hasn't been done when it really should have. Maybe some junior dev came in after you and shoehorned in a bunch of features to your "simple" solution. Now you have to live with that but, guess what, there's no time to refactor it, in fact the business just wants even more features.
As usual these rules work best if everyone on the team understands them in the same way. If you work with people who can only see what is right in front of them (ie. the current feature), then it'll never work. You can always fit "one more feature" into the perfect codebase without thinking about the abstractions.
Re: Rob Pike’s Rules of Programming (1989)
#457Earlier 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.
This comment assumes game companies throw away all their code and start from scratch on their next title. Which is completely untrue, games are built on decades old code, like most software. There is absolutely a need for maintainable code.
Re: Rob Pike’s Rules of Programming (1989)
#458Earlier quoted context omitted.
> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.
But they should emerge right when they are needed, not some time later via a painful refactor. I think every dev lives in fear of the situation where abstraction hasn't been done when it really should have. Maybe some junior dev came in after you and shoehorned in a bunch of features to your "simple" solution. Now you have to live with that but, guess what, there's no time to refactor it, in fact the business just wa…
In a perfect world, sure. In my personal experience, refactoring to introduce an abstraction is far less painful than refactoring to remove or fix one.
Usually because intent is far clearer in the former case.
Re: Rob Pike’s Rules of Programming (1989)
#459[flagged]
> In practice what I see fail most often is not premature optimization but premature abstraction This matches my experience as well. Someone here commented once that abstractions should be emergent, not speculative, and I loved that line so much I use it with my team all the time now when I see the craziness starting.
Similar to when someone said that the rule of thumb should not be DRY (don't repeat yourself) but WET (write everything twice) - that is, be happy to repeat similar code once or twice, and wait for the need for abstraction to become evident.
It's advice I like, as I'm prone to falling into design paralysis while trying to think of the One True Abstract Entity.
Re: Rob Pike’s Rules of Programming (1989)
#460Earlier 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.
This comment assumes game companies throw away all their code and start from scratch on their next title. Which is completely untrue, games are built on decades old code, like most software. There is absolutely a need for maintainable code.
I think that there might be a distinction on indie vs big publishers (like EA) - I would expect someone like EA to enforce coding standards, but they do so whilst living off the income of previous hits.