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

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

#31

Post by throwaway894345 » Wed, Aug 12, 2020, 7:57 PM UTC

karl11 wrote: post #6

Everyone building no code tools is learning or will learn that the problem most businesses have is not a lack of coding skill, or the inability to build the algorithm, but rather how to structure and model data in a sensible way in the first place.

Modeling the data and structuring the program are indeed the harder tasks, but orgs have lots of smart people who have those skills but not the familiarity with various existing syntaxes and standard libraries and so on that a programmer learns over the decades of their career. Further, those same orgs probably have many people with experience in the latter but without any special ability to think abstractly. This significantly limits the ability to create tools. Further, the no code tools often abstract at a more appropriate level than general purpose programming languages’ standard libraries because these tools aren’t trying to be general purpose (at least not to the same degree as general purpose programming languages). Lastly, I’ve seen business people use certain no code tools to build internal solutions quickly that would have taken a programmer considerable (but not crazy) time to crank out, especially considering things like CI/CD pipelines, etc. Nocode won’t replace Python, but it serves a valuable niche.

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

#32

Post by yashap » Wed, Aug 12, 2020, 7:58 PM UTC

Ozzie_osman wrote: post #8

It turns out rule 5 (Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident) is both true but also hard. Eric Evans' Domain Driven Design is a good book on the topic.

I’m such a huge fan of DDD. IMO, if you only ever read one book on Software Architecture, that’s the one to pick.

A key point, though, is that you learn the right domain models/abstractions over time. Refactoring is critical as you gain more insight into the domain. If you’re constantly questioning your modelling of the domain, and refactoring towards a better one, you’ll end up with a great model and thus a clean, understandable, easy to extend/modify system. If you stick with whatever abstractions you chose at the start, when you knew way less about the domain/business problems, you’ll likely end up with poor abstractions, and a code based that’s slow, tedious and error prone to modify.

Convincing the business that it’s worth setting aside time to constantly refactor towards better domain models is often the hardest part, but crucial.

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

#33

Post by tmaly » Wed, Aug 12, 2020, 8:01 PM UTC

karl11 wrote: post #6

Everyone building no code tools is learning or will learn that the problem most businesses have is not a lack of coding skill, or the inability to build the algorithm, but rather how to structure and model data in a sensible way in the first place.

If no code tools are anything like ORMs, there will be some interesting surprises when one encounters non-normalized data structures.

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

#34

Post by sukilot » Wed, Aug 12, 2020, 8:02 PM UTC

dnautics wrote: post #27

mywittyname wrote: post #11

> "write stupid code that uses smart objects". Writing stupid code is actually really difficult. For me, it takes a little bit of iterating before I know just the right place to insert stupid.

Do you use TDD? I'm not religious about it in general, but when I'm lost, confused, and easily distracted, I start with TDD to write the dumbest possible code.

TDD is good for features (like web apps) but not so much for algorithms.

The difference is that you only need to support a tiny fraction of possible features / use cases, but your algorithms need to be correct for a wide range of inputs.

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

#35

Post by bluGill » Wed, Aug 12, 2020, 8:02 PM UTC

terandle wrote: post #7

Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.

That depends.

If you are writing the code yourself then the maintenance costs of everyone else after you trying to understand it makes it wrong. However most programming languages have generic programing features such that you can just use an algorithm and so you aren't writing either the algorithm. In that case the code for the fast hash is equal to the O(n^2) code and so of course you select the faster one as a application of don't prematurely pessimise your code rule. If your programing language doesn't already have built in generic algorihtms for your data, then you are using the wrong language (unless your job is to write the generic algorithms for the language in which case this doesn't apply because you can assume your algorithm will be used in a performance critical part at some time)

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

#36

Post by zabzonk » Wed, Aug 12, 2020, 8:02 PM UTC

dragontamer wrote: post #22

terandle wrote: post #7

Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.

> Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity Are you sure that std::unordered_map is faster than std::vector? Did you measure? Every time you access an element in std::vector, you also access nearby ones (thanks to L1 cache, as well as CPU-prefetching of in-line data). In contrast, your std::unordered_map or hash-table has almost n…

Also, creating a hash isn't free. And often ordering is required.

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

#37

Post by cactus2093 » Wed, Aug 12, 2020, 8:02 PM UTC

Interesting that the first 3 are all about performance. Which strikes me as a bit ironic given rule #1, which could be summarized as don't worry about performance until you have to.

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

#38

Post by skybrian » Wed, Aug 12, 2020, 8:04 PM UTC

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.

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

#39

Post by kens » Wed, Aug 12, 2020, 8:06 PM UTC

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…

In case you've wondered what a monoid is, that's a monoid. Something with an associative operation (and an identity), so you can do the operation on chunks in parallel, like addition.

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

#40

Post by lliamander » Wed, Aug 12, 2020, 8:06 PM UTC

sukilot wrote: post #30

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…

And that was 10 years before Haskell went huge in that idea.

I'm not super familiar with either the C++ or Haskell communities, but Stepanov's notion of Generic Programming[1] certainly seems to fit with the Haskell ethos.

[1]http://www.generic-programming.org/