Rob Pike’s Rules of Programming (1989) • Hacker News Board

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

#111

Post by rumanator » Wed, Aug 12, 2020, 9:41 PM UTC

mgkimsal wrote: post #93

monocasa wrote: post #71

Earlier quoted context omitted.

Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships

> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones.

This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have added.

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

#112

Post by burke » Wed, Aug 12, 2020, 9:42 PM UTC

mgkimsal wrote: post #93

monocasa wrote: post #71

Earlier quoted context omitted.

Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships

> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

Bad programmers inflicting their worry upon the others.

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

#113

Post by wvenable » Wed, Aug 12, 2020, 9:43 PM UTC

mgkimsal wrote: post #109

Koshkin wrote: post #95

Earlier quoted context omitted.

And that’s because it’s Bad Programmers who need help!

but... they need help on data structures/relations and up front thinking about those issues, not where curly braces should go, or tabs-v-spaces.

That stuff is hard! Better to just shove your data somewhere unstructured and then you don't have to worry about data structures and relations.

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

#114

Post by karmakaze » Wed, Aug 12, 2020, 9:44 PM UTC

commandlinefan wrote: post #49

> Tony Hoare's famous maxim "Premature optimization is the root of all evil." Actually that was Donald Knuth - it's an urban legend that it's an urban legend that it was originally Knuth. Hoare was quoting Knuth, but Knuth forgot he said it, and re-mis-attributed the quote to Hoare.

Ha. So the truth is that Knuth did quote Hoare, not aware that he was quoting Knuth--indirectly Knuth was quoting himself.

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

#115

Post by rumanator » Wed, Aug 12, 2020, 9:44 PM UTC

mathattack wrote: post #90

andrewl wrote: post #5

In The Mythical Man Month Fred Brooks said "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." I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

An early mentor put it as “learn the data, which won’t change, before learning the fancy stuff on top, which will” That carried me very well.

Plenty of professional developers would benefit greatly if they read Domain-Driven Design.

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

#116

Post by Benjammer » Wed, Aug 12, 2020, 9:45 PM UTC

mgkimsal wrote: post #109

Koshkin wrote: post #95

Earlier quoted context omitted.

And that’s because it’s Bad Programmers who need help!

but... they need help on data structures/relations and up front thinking about those issues, not where curly braces should go, or tabs-v-spaces.

Right, because the hyper-focus on linting of the industry is the symptom here, it's not a misguided treatment for the underlying problem of bad programmers.

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

#117

Post by ttamslam » Wed, Aug 12, 2020, 9:46 PM UTC

gentleman11 wrote: post #83

> Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident What does this have to say about the careers and roles of data scientists vs programmers? A data scientists entire job is to categorize and model data in a useful way. In the future, will they fundamentally more important than coders, or will the two roles just merge?

I think you're conflating two things: in my mind, working on the shape of data is different than pulling inferences out of that data.

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

#118

Post by wvenable » Wed, Aug 12, 2020, 9:47 PM UTC

aserafini wrote: post #105

OliverJones wrote: post #81

In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…

Sometimes storing in UTC is simply not correct. For example a shop opening time. The shop opens 10am local time, whether DST or not. Their opening time is 10am local time all year but their UTC opening time actually changes depending on the time of year!

I made that mistake early my career following this exact advice and I ended up with a lot things were randomly 1 hour off depending on when the record was created and the date entered.

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

#119

Post by rumanator » Wed, Aug 12, 2020, 9:48 PM UTC

Koshkin wrote: post #99

skybrian wrote: post #38

Earlier quoted context omitted.

But adding floating point numbers isn't associative, in general. Sometimes you need to do it the right way to avoid catastrophic cancellation. I guess the key is to know how to deal with things that are only mostly true.

That’s why in C++ we have traits and overloading.

Could you explain where do you see traits and overloading helping you with floating point operations?

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

#120

Post by Benjammer » Wed, Aug 12, 2020, 9:50 PM UTC

aserafini wrote: post #105

OliverJones wrote: post #81

In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…

Sometimes storing in UTC is simply not correct. For example a shop opening time. The shop opens 10am local time, whether DST or not. Their opening time is 10am local time all year but their UTC opening time actually changes depending on the time of year!

Totally. "Store everything in UTC" is just another flavor of "pick a timezone to store everything." In a lot of cases, you probably need to go ahead and just store the fully qualified date including timezone/offset for each record.