←back to thread

SICP: The only computer science book worth reading twice? (2010)

(simondobson.org)
460 points pieterr | 2 comments | 16 Nov 24 17:23 UTC | HN request time: 0.514s | source
Show context
__turbobrew__ ◴[16 Nov 24 20:40 UTC] No.42159121[source]▶
It’s interesting, SICP and other many other “classic” texts talk about designing programs, but these days I think the much more important skill is designing systems.

I don’t know if distributed systems is consider part of “Computer Science” but it is a much more common problem that I see needs to be solved.

I try to write systems in the simplest way possible and then use observability tools to figure out where the design is deficient and then maybe I will pull out a data structure or some other “computer sciency” thing to solve that problem. It turns out that big O notation and runtime complexity doesn’t matter the majority of the time and you can solve most problems with arrays and fast CPUs. And even when you have runtime problems you should profile the program to find the hot spots.

What computer science doesn’t teach you is how memory caching works in CPUs. Your fancy graph algorithm may have good runtime complexity but it completely hoses the CPU cache and you may have been able to go faster with an array with good cache usage.

The much more common problems I have is how to deal with fault tolerance, correctness in distributed locks and queues, and system scalability.

Maybe I am just biased because I have a computer/electrical engineering background.

replies(23): >>42159154 #>>42159177 #>>42159448 #>>42159469 #>>42159581 #>>42159600 #>>42160025 #>>42160394 #>>42160515 #>>42160581 #>>42160656 #>>42161150 #>>42161980 #>>42162797 #>>42163285 #>>42163324 #>>42163910 #>>42164082 #>>42164391 #>>42164509 #>>42164766 #>>42165157 #>>42169617 #
1. KerrAvon ◴[16 Nov 24 20:47 UTC] No.42159177[source]▶
If you knew how to design programs you could run it all on a single box and wouldn’t have to design “systems.”

I’m being slightly facetious, but only slightly. If you really think everything is solvable with arrays, you are not going to scale well and of course you’re going to need to throw a lot more hardware at the problem.

replies(1): >>42162909 #
2. __turbobrew__ ◴[17 Nov 24 08:54 UTC] No.42162909[source]▶
My argument is that 90% of problems can be solved with arrays, 5% of problems can be solved with memoization, 3% of problems can be solved with b-trees, and 2% of problems with other data structures.

It is good to know that solutions to the 2% exists, but what we should be focusing on is writing the simplest code possible which solves the problem and then only optimize afterwards using a profiler. God forbid you have to work on some codebase written by someone who believes they are the second coming of haskell with crazy recursion and backtracing, monads, red black trees, and a DSL on top of the whole thing.

You are right that many problems can be solved with a single box, but my argument is that you do not need fancy algorithms to solve problems on a single box. We should strive to use single boxes whenever possible to reduce complexity.

Computation is designed by humans to serve humans, we should make it as easy as possible for humans to understand. I’m probably going to start a flamewar here, but this is why simple solutions like UNIX and golang have prevailed in the past. Simple code is easy to understand and therefore it is easy to modify and reason about. Some people think simple means that you decompose programs into the smallest possible functional parts, but simple to me is a 500 line main function.