3 ms·
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to b
by cjs_ac 2y ago
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) For example, binary trees are always faster than splay trees for workaday problems.
-- Rob Pike, Notes on Programming in C, 1989[0]
Generally speaking, I feel that the bureaucracy involved in a programming project should be proportional to the scale of the project itself. If the 'getting started' tutorial for your programming language demands that I choose a package name for my Hello World program, you fucked up.
[0] https://doc.cat-v.org/bell_labs/pikestyle https://doc.cat-v.org/bell_labs/pikestyle
- wepple 2y agoI mostly agree, because most proof-of-concepts don’t make it very far, and LLM assisted dev is really strong for that kind of low-barriers experimentation. The problem is that if you build quick n dirty, but then end up reaching success; you’re in for a bad time or a rewrite. This is where the above example of a single algorithm departs from a whole stack. Further, one bad “hello world” on a google/apple/amazon domain can make the front page of the NYTimes
- bee_rider 2y agoI dunno, if the package name is just some local thing that could be nice. Is “all software is part of a package” ever a nice simplifying assumption?
- stickfigure 2y agoNobody writes hello world for a living. This is a useless metric.