←back to thread

462 points pieterr | 10 comments | | HN request time: 1.249s | source | bottom
Show context
__turbobrew__ ◴[] 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. soegaard ◴[] 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 #
2. pipes ◴[] No.42159520[source]
I hadn't, that looks excellent.
replies(2): >>42160904 #>>42162054 #
3. ralphc ◴[] No.42160904[source]
IMO it's not excellent. It's not like SICP, it's obtuse for no reason, I find it a hard slog. Flexibility is good but it seems to try to make every bit of your program flexibile and pluggable and you just need to do something eventually.

My opinion, I'd welcome others on the book; there was a small splash when it came out but not much discussion since.

replies(2): >>42161097 #>>42161100 #
4. gregmac ◴[] No.42161097{3}[source]
I haven't read the book, but my experience is that the way to make things flexible is to make them simple as possible.

When I've used (or built) something that was built in the style like you're talking about, it's almost always wrong, and the extra complexity and stuff now makes it harder to do right. It's not surprising: unknown future requirements are unknown. Over building is trying to predict the future.

It's like someone building a shed and pouring a foundation that can work for a skyscraper. Except it turns out what we needed was a house that has a different footprint. Or maybe the skyscraper is twice the height and has a stop for the newly-built underneath. Now we have to break apart the foundation before we can even begin work on new stuff; it would have been less work if the original just used a foundation for a shed.

replies(1): >>42168434 #
5. maroonblazer ◴[] No.42161100{3}[source]
Is there another book you'd recommend - more recent than SICP - for how to avoid programming yourself into a corner?
replies(1): >>42161502 #
6. ralphc ◴[] No.42161502{4}[source]
I don't know about books, but I think the best approach is functional programming in a dynamic language. That could be because I'm currently an Elixir fanboy, but I think Lisps, especially Scheme or Clojure, or a functional-restricted approach in JavaScript could do it as well. I agree with parent comment that it's better to keep things as simple as possible and make the changes when necessary vs. building in all the flexibility in the beginning.
7. crystal_revenge ◴[] 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 #
8. WillAdams ◴[] No.42164274{3}[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.

9. zelphirkalt ◴[] No.42168434{4}[source]
I think that is what the book does. Step by step introducing new requirements, by telling you about a situation, where the previous code would not be flexible enough. I am sure it doesn't state, that one should apply all of its ideas all the time, regardless of the project at hand.
10. ngcc_hk ◴[] No.42169046[source]
https://archive.org/details/software-design-for-flexibility_...