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

431–440 of 483 posts

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

#431

Post by zephen »

pydry wrote: post #56
PaulKeeble wrote: post #23

Earlier quoted context omitted.

I feel like every time I have expected an area to be the major bottleneck it has been. Sometimes some areas perform worse than I expected, usually something that hasn't been coded well, but generally its pretty easy to spot the computationally heavy or many remote call areas well before you program them. I have several times done performance tests before starting a project to confirm it can be made fast enough to be…

The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future. It's the same thing with programmers who believe in BDUF or disbelieve YAGNI - they design architectures for anticipated futures which do not materialize instead of evolving the architecture retrospectively in line with the future which did materialize. I think it's a natural human foible…

> poor programmers is a belief that theyre special snowflakes who can anticipate the future.

Some of us are actually reasonably good at anticipating the future, and don't mesh well in environments where people claim to care about quality but are always deferring stuff for the next release.

> This is why no matter how many brilliant programmers scream YAGNI, dont do BDUF and dont prematurely optimize there will always be some comment saying the equivalent of "akshually sometimes you should...",

You write as if there are no brilliant people doing BDUF. This is unequivocally false.

> remembering that one time when they metaphorically rolled a double six and anticipated the necessary architecture correctly when it wasnt even necessary to do so.

You've doubled down on the gambling trope. Any development is gambling. Thinking otherwise is foolish.

Sure, people who live and breathe YAGNI gamble in different ways, but they still gamble. I can't count the number of times I've made the statement "but if this happens and then that happens, it will be bad" which was countered with "but what are the chances of that?"

Look, if you have to ask, the probability of it being a problem at the customer approaches one.

My personal solution?

I went to work for chip companies. Chip companies have to put a stake in the ground and work to build something that they will be able to sell as designed and implemented.

This doesn't mean that there isn't a triage for features, or the potential for feature creep, or that there isn't a triage for the most important bugs right before tapeout, but the process that works and gets you a chip that customers will use is much closer to what people call BDUF than it is YAGNI.

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

#432

Post by zephen »

pydry wrote: post #332
tbrownaw wrote: post #193

Earlier quoted context omitted.

Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails. Don't insist on file-based data ingestion being a wrapper around a json-rpc api just because most similar things are moving that direction; what matters is whether someone has specifically asked for that for this particular system yet. . Not all decisions can be usefully…

Going "what if?" and then validating a customer requirement that exists NOW is NOT the same thing as trying to pre-empt a customer's requirement which might exist in the future. Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

> Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

But how do you ask "the right questions" without imagining many future possibilities and then trying to discern which ones are important?

It seems like a distinction without a difference to me.

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

#433

Post by zephen »

koliber wrote: post #178
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,…

Picking the starting point is very important. "optimization" is the process of going from that starting point to a more performant point. If you don't know enough to pick good starting points you probably won't know enough to optimize well. So don't optimize prematurely. If you are experienced enough to pick good starting points, still don't optimize prematurely. If you see a bad starting point picked by someone else…

> If you see a bad starting point picked by someone else, by all means, point it out if it will be problematic now or in the foreseeable future, because that's a bug.

Can't disagree at all, but many people push back in the name of XP.

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

#434

Post by CyberDildonics »

JanisErdmanis wrote: post #429
CyberDildonics wrote: post #399

Earlier quoted context omitted.

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.

It’s about coupling and being able to maintain that in the long term. A narrow focus helps to test each individual unit in isolation from each other. It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective and that is fine, because someone else engineered and tested it for you. However if you were to look into how a database is implemented you would get to s…

It’s about coupling and being able to maintain that in the long term.

What does that mean? This is all the kind of abstract programming advice that sounds nice until someone needs an example.

A narrow focus helps to test each individual unit in isolation from each other.

A function operating on a data structure is already a narrow focus.

It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective

And also from a reality perspective because it's literally what a database is about.

However if you were to look into how a database is implemented you would get to see the composition of data structures, like btrees that are tested in isolation.

I don't know what point you're trying to make. Data structures should be tested? I don't think anyone is saying they shouldn't.

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

#435

Post by zephen »

aleph_minus_one wrote: post #288
rsav wrote: post #9

Earlier quoted context omitted.

There's also: >I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds

> >I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. > -- Linus Torvalds What about programmers - for whom the code is a data structure? - who formulate their data structures in a way (e.g. in a very powerfu…

Linus has the same problem as corporate America, but at a slightly different level.

He needs some group of really smart, self-selected programmers, where corporate America is looking for a larger group of somewhat less intelligent programmers.

You might be describing an even more intelligent programmer, but unless he can dumb down his programming to fit in, he's probably better off being a lone developer.

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

#436

Post by harry8 »

fl0ki wrote: post #281

> Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. I get where he's coming from, but I've seen people get this very wrong in practice. They use an algorithm that's indeed faster for small n, which doesn't matter because anything was going to be fast enough for small n, meanwhile their algorithm is so slow for large n that it ends up becoming a production crisis j…

The error here is not understanding the data being transformed.

You won't get it right either way if you don't /know/ how big n is going to be.

If you can't know, why not? Should you even be coding this at all?

Maybe there should be a rule zero.

0) Understand the data on which your data transformation is going to operate.

The extent you don't is the extent to which the endeavour is doomed.

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

#438

Post by YesBox »

SatvikBeri wrote: post #364
Fraterkes wrote: post #361

Earlier 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.

Wow! I'm shocked Limbo took 3 years and had a larger team. I've played a bit of the game (but didn't complete it). Looking at the Steam reviews and a quick search shows me it takes 3-10 hours to beat the game. :O

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

#439

Post by oops »

CharlieDigital wrote: post #18

I feel like 1 and 2 are only applicable in cases of novelty. The thing is, if you build enough of the same kinds of systems in the same kinds of domains, you can kinda tell where you should optimize ahead of time. Most of us tend to build the same kinds of systems and usually spend a career or a good chunk of our careers in a given domain. I feel like you can't really be considered a staff/principal if you can't alre…

> I feel like you can't really be considered a staff/principal if you can't already tell ahead of time where the perf bottleneck will be just on experience and intuition.

I feel like you can’t really be considered a Dunning-Kruger if you can’t already tell ahead of time where the perf bottleneck will be just on experience and intuition.

Post reply on HN