Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

91–100 of 332 posts

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

#91

Post by allover »

rubyn00bie wrote: post #77

> 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. That one hits me in the feels because I think a lot of folks focus on algorithms (including myself), and code patterns, before their data and as a result a lot of things end up being harder than they need to be.…

The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.

I.e. too much focus has been put on data structures and not enough on the rest of the tool.

A less efficient data structure, but more focus on UX could have saved millions of man hours by this point.

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

#92

Post by chrisweekly »

jonfw wrote: post #2

"Write stupid code that uses smart objects" That's a good one. It's amazing how much complexity can be created by using the wrong abstractions.

Yes! We should replace DRY (don't repeat yourself) with AHA (avoid hasty abstractions), as the dominant rule of thumb.

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

#93

Post by mgkimsal »

monocasa wrote: post #71
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

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.

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

#94

Post by Koshkin »

chubot wrote: post #46
NewEntryHN wrote: post #42

Earlier quoted context omitted.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

Except that there are infinite such non-bottlenecks, and all the effort you spend on there is effort not spent on the real bottlenecks. In other words, all engineering is time- and cost-constrained. Anybody can build a good chair for $10,000 or a good PC for $100,000. Doesn't mean it's good engineering.

Yes they can indeed: https://blogs.systweak.com/someone-has-built-a-gigantic-1000...

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

#95

Post by Koshkin »

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 that’s because it’s Bad Programmers who need help!

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

#96

Post by chubot »

mamcx wrote: post #58
chubot wrote: post #13

Earlier quoted context omitted.

FWIW I find this is especially important for compilers and interpreters. It's not an exaggeration to say that such programs are basically big data structures, full of compromises to accomodate the algorithms you need to run on them. For example LLVM IR is just a big data structure. Lattner has been saying for awhile that a major design mistake in Clang is not to have its own IR (in the talks on the new MLIR project).…

> FWIW I find this is especially important for compilers and interpreters. Totally. I'm building a relational language and start to get very obvious why RDBMS not fit certain purity ideals of the relational model (like all relations are sets, not bags). I'm stuck in deciding which structures provide by default. Dancing between flat vectors or ndarrays or split between flat vectors (columns), and HashMaps/BTree with n…

FWIW I found this post thought provoking in thinking about data models of languages.

https://news.ycombinator.com/item?id=13293290

---

About first class variants:

https://lobste.rs/s/77nu3d/oil_s_parser_is_160x_200x_faster_...

https://github.com/rust-lang/rfcs/pull/2593

Another way I think of this is "types vs. tags": https://oilshell.zulipchat.com/#narrow/stream/208950-zephyr-... (Zulip, requires login)

Basically variant can types stand alone, and have a unique tag. Tags are discriminated at RUNTIME with "pattern matching".

But a variant can belong to multiple sum types, and that's checked statically. This is modeled with multiple inheritance in OOP, but there's no implementation inheritance. Related: https://pling.jondgoodwin.com/post/when-sum-types-inherit/

So basically in the ASDL and C++ and Python type system I can model:

- a Token type is a leaf in an arithmetic expression

- a Token type is a leaf in an word expression

But it's not a leaf in say what goes in a[i], or dozens of other sum types. Shell is a big composition of sublanguages, so this is very useful and natural. Another construct that appears in multiple places is ${x}.

So having these invariants modeled by the type system is very useful, and actually C++ and MyPy are surprisingly more expressive than Rust! (due to multiple inheritance)

Search for %Token here, the syntax I made up for including a first class variant into a sum type:

https://www.oilshell.org/release/0.8.pre9/source-code.wwz/fr...

There is a name for the type, and a name for the tag (and multiple names for the same integer tag). Tags (dynamic) and types (static) are decoupled.

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

#97

Post by gen220 »

rubyn00bie wrote: post #77

> 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. That one hits me in the feels because I think a lot of folks focus on algorithms (including myself), and code patterns, before their data and as a result a lot of things end up being harder than they need to be.…

It makes sense, when we bring in another aphorism "code is data". It's easier to write good code with good libraries. And it's easier to write good data models that extend good data models. The main distinction is that code is very dynamic, flexible, and malleable, whereas data models need not be.

Data models are the "bones" of an application, as part of the application as code is. Data models fundamentally limit the application's growth, but if they're well-placed, they can allow you to do things that are really powerful.

You always want to have good bones. But the Anna Karenina Principle is a thing [0].

So, applying this, I think baby ideas should not have many constraints on the bones, to allow them to move around in the future. Instead, there should be a ton of crap code implementing the idea's constraints, because they change every week, month, quarter, and the implementer is still learning the domain.

Once the implementer reaches a certain point of maturity in the domain, all of the lessons learned writing that crap code can be compressed into a very clever data model that minimizes the amount of "code" necessary, and simultaneously makes the project more maintainable, interface-stable, and extensible: in other words, making it an excellent platform to build on. The crap code can be thrown out, because it was designed to halfway-ensure invariants that the database can now take care of.

I think most software we consider "good" these days followed this development cycle. multics -> unix, -> git, ed -> vi -> vim.

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

#98

Post by erik_seaberg »

atombender wrote: post #79
sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

Not all optimization candidates are about bottlenecks. Reducing allocation is also optimization, for example.

Peak memory or garbage collection throughput can become a bottleneck. But if you know you have more memory than you need, further reducing allocation is arguably a waste of your time.

This can become a tragedy of the commons in desktop and mobile apps, where you don't know how much memory the end user has or needs, but you do know you aren't paying for it.

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

#99

Post by Koshkin »

skybrian wrote: post #38
lliamander wrote: post #9

Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…

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.

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

#100

Post by gen220 »

allover wrote: post #91
rubyn00bie wrote: post #77

> 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. That one hits me in the feels because I think a lot of folks focus on algorithms (including myself), and code patterns, before their data and as a result a lot of things end up being harder than they need to be.…

The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user. I.e. too much focus has been put on data structures and not enough on the rest of the tool. A less efficient data structure, but more focus on UX could have saved millions of man hours by this point.

It's difficult, because git's exposition of it's data structures enables you to use it in ways that would not otherwise be possible.

I think git is more of a power-tool than people sometimes want it to be. It's more like vi than it is like MS Word, but it's ubiquity makes people wish it had an MS-word mode.

So, I think that it's hard to fault git's developers for where it is today. It's a faithful implementation of it's mission.

FWIW, I have never used a tool with better documentation than git in 2020 (it hasn't always had good --help documentation, but it absolutely does today).

Post reply on HN