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

341–350 of 483 posts

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

#341

Post by artyom »

SoftTalker wrote: post #322
vishnugupta wrote: post #292

I can’t emphasize the importance of rule-5 enough. I learnt about rule-5 through experience before I had heard it was a rule. I used to do tech due diligence for acquisition of companies. I had a very short time, about a day. I hit upon a great time saver idea of asking them to show their DB schema and explain it. It turned out to be surprisingly effective. Once I understood the scheme most of the architecture explai…

Yes, fully agree. Rule 5 has been the center of my approach to designing and writing software for over 30 years now. Fad methodologies and platforms come and go but Rule 5 works as well for me today as it did in 1995.

I can't agree more. I live and breath by rule #5.

Getting competent at it, however, is no joke and takes time.

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

#342

Post by mkehrt »

ryguz wrote: post #297

[flagged]

This comment is fascinating to me, as it indicates an entirely different mindset than mine. I'm much more interested in code readability and maintainabilty (and simplicty and elegance) than performance, unless it's necessary. So I would start by saying everything flows from rule 4 or maybe 5. Rule 1 is a consequence of rule 4 for me.

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

#343

Post by astrobe_ »

munk-a wrote: post #336
ryguz wrote: post #297

[flagged]

As someone who believes strongly in type based programming and the importance of good data structure choice I'm not seeing how Rule 5 follows Rule 1. I think it's important to reinforce how impactful good data structure choice is compared to trying to solve everything through procedural logic since a well structured coordination of data interactions can end up greatly simplifying the amount of standalone logic.

Data cache issues is one case of something being surprising slow because of how data is organized. That said, Structure of Arrays vs Array of structures is an example where rule 4 and 5 somewhat contradict each other, if one confuses "simple" and "easy" - Structure of Array style is "harder" because we don't see it often; but then if it's harder, it is is likely more bug-prone.

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

#344

Post by cleaver »

munro wrote: post #340

> Rule 5. 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. It's so true, when specing things I always try to focused on DDL because even the UI will fall into place as well, and a place I see claude opus fail as well when building things.

I recall a similar statement from Ed Yourdon in one of his books (90's?)

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

#346

Post by JanisErdmanis »

CyberDildonics wrote: post #337
JanisErdmanis wrote: post #299

Earlier quoted context omitted.

One can always look as global variables equivalent to a context object that’s is passed in every function. It’s just a syntactic difference whether one constructs such data structure or uses it implicitly via globals. What I am getting at is that when one has such gigantic data structure there is no separation of concerns.

Does one need one's separation of concerns if one's concerns shouldn't be separated in the in the first place? Anytime one has access to a database one has access to one large global data structure that one can access from anywhere is a program. This same concept goes for one's global state in one's game if one is making a game.

Separation of concerns is still a valid paradigm with a single global datastructure like GUI, Microservice, Database and etc. In such situation one can still seperate concerns via composing the global datastructure from a smaller units and define methods with respect to thoose smaller units. In that way one does not need to wonder whether there are some unattended side effects when calling a function that mutates the state.

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

#347

Post by akkad33 »

munk-a wrote: post #336
ryguz wrote: post #297

[flagged]

As someone who believes strongly in type based programming and the importance of good data structure choice I'm not seeing how Rule 5 follows Rule 1. I think it's important to reinforce how impactful good data structure choice is compared to trying to solve everything through procedural logic since a well structured coordination of data interactions can end up greatly simplifying the amount of standalone logic.

But good data structure is not always evident from the get go. And if your types are too specific it would make future development hard if the specs change. This is what I struggle with

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

#348

Post by EvanAnderson »

cleaver wrote: post #344
munro wrote: post #340

> Rule 5. 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. It's so true, when specing things I always try to focused on DDL because even the UI will fall into place as well, and a place I see claude opus fail as well when building things.

I recall a similar statement from Ed Yourdon in one of his books (90's?)

The article makes reference to Fred Brooks and "The Mythical Man Month", but doesn't make a direct quote. The quote I'd have referenced is:

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

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

#349

Post by Jensson »

kevincox wrote: post #328
01100011 wrote: post #252

Rule 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…

I actually disagree with Rule 3! While numbers are usually small being fast on small cases generally isn't as important as performing acceptably on large cases. So I prefer to take the better big-O so that it doesn't slow down unacceptably on real-world edge-case stresses. (The type of workloads that the devs often don't experience but your big customers will.) Of course there is a balance to this, the engineering ti…

Rule 3 was true 1989, back then computers were so slow and had barely any ram so most things you did only was reasonable for small number of inputs. Today we almost always have large amounts of inputs so its different.

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

#350

Post by oxag3n »

> Rule 5. 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.

I'm a big fan of Data Oriented Design. Once you conceptualize how data is stored and transformed in your program, it just has to be reflected in data structures that make it possible.

Modern design approaches tend to focus on choosing a right abstraction like columnar/row layout, caching etc. They mostly fail to optimally work with the data. Optimal in this case meaning getting most of all underlying hardware capabilities, for example reading large and preferably continuous blocks of data from magnetic storage, parallel data processing, keeping intermediate results in CPU caches, utilizing all physical SSD queues.

Post reply on HN