←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.435s | 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 #
soegaard ◴[16 Nov 24 21:22 UTC] No.42159469[source]▶
Have you seen

"Software Design for Flexibility: How to Avoid Programming Yourself into a Corner" by Chris Hanson and Gerald Jay Sussman

It's from 2021.

replies(2): >>42159520 #>>42169046 #
pipes ◴[16 Nov 24 21:27 UTC] No.42159520[source]▶
I hadn't, that looks excellent.
replies(2): >>42160904 #>>42162054 #
1. crystal_revenge ◴[17 Nov 24 04:54 UTC] No.42162054[source]▶
Unfortunately, while I really want to love Software Design for Flexibility, it's clear that Hanson and Sussman haven't really solved (or even come close to solving) the problem they have identified in the book.

The introduction to that book is brilliant at identifying just how much room software has to grow (you can find similar talks from various Strange Loop sessions Sussman has done), and is really quite inspirational for anyone seriously thinking about the future of computing.

But the rest of the book fails to provide a coherent answer to the questions that are brought up in the intro. It shows off some neat functional programming tricks, but repeatedly fails to deliver on solving the (admittedly ambitious) challenges it provides for itself.

I'm still glad I have a copy, and have re-read the first half multiple times now, but sadly it's not the book it wants to be. To be fair though, that is because we haven't come close to understanding computation enough to solve those problems.

It's a very ambitious book that falls short of it's own ambitious.

replies(1): >>42164274 #
2. WillAdams ◴[17 Nov 24 14:15 UTC] No.42164274[source]▶
A more humble book, with a more grounded approach might be:

_A Philosophy of Software Design_ by John Ousterhout (the guy behind Tcl)

https://www.goodreads.com/book/show/39996759-a-philosophy-of...

Written as the textbook for a software engineering course, it developed out of that course being taught multiple times _and_ all the code reviews which that entailed.

Previous discussions/mentions here which had a notable number of comments:

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

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

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

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

I re-wrote my current project in the course of reading it (I would read a chapter, then read through the code and where appropriate apply the relevant principle) and once I finish the current re-write (from OpenSCAD to Python) will be repeating that process to see if what I was supposed to have learned stuck/survived the re-write.