Live data from Hacker News

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

simondobson.org

141–150 of 189 posts

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

#141

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 de…

> big O notation and runtime complexity doesn’t matter the majority of the time and you can solve most problems with arrays

I have the exact opposite experience.

Software comes out best if you always ensure to use an approach with sensible runtime complexity, and only make trade-offs towards cache-friendly-worse-O implementations where you benchmarked thoroughly.

Most cases where I encounter mega slow programs are because somebody put in something quadratic instead of using a simple, standard O(n logn) solution.

Check out https://www.tumblr.com/accidentallyquadratic for many examples.

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

#142
post #56

Earlier quoted context omitted.

Well CS and software dev in trenches moved a bit. There are still jobs where people write frameworks, database engines or version control tools. Those jobs require heavy CS and algorithms, data structures day to day. But there are less of those jobs nowadays as no one is implementing db engine for their app they just use Postgres. Other jobs that is vast majority is dealing with implementing business logic. Using dat…

> while using CS background to fully understand frameworks already existing. Most frameworks today are so complicated that you typically cannot understand them fully, and even understanding them somewhat partially is more than a full-time job.

You don't have to understand them fully to make use of them. One has to understand design patterns and underlying reasoning, understand context of the framework like for example if it is JS framework that it runs in browser to understand which parts are "because we are running in the browser" vs "that is just why framework implemented it" and if it is Typescript then how it blends into that mix.

Then for any details or unexpected behavior knowing where to look in documentation.

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

#143

Earlier quoted context omitted.

> but these days I think the much more important skill is designing systems. It is hard to design systems if you don't have the perspective of implementing them. Yes, you move up the value chain to designing things, no, but no, you don't get to skip gaining experience lower down the value chain. > What computer science doesn’t teach you is how memory caching works in CPUs. That was literally my first quarter in my CS…

I think CS 30 years ago was closer to computer engineering today. At my uni 10 years ago the CS program didn’t touch anything related to hardware, hell the CS program didn’t even need to take multivariable calculus. In my computer engineering program we covered solid state physics, electromagnetism, digital electronics design, digital signals processing, CPU architecture, compiler design, OS design, algorithms, softw…

Computers today are slower than they have ever been. And tomorrow's computers are going to be even slower.

In many applications, the amount of data grows at least as quickly as computer performance. If the time complexity of an algorithm is superlinear, today's computer needs more time to run it with today's data than yesterday's computer did with yesterday's data. Algorithms that used to be practical get more and more expensive to run, until they eventually become impractical.

The more data you have, the more you have to think about algorithms. Brute-forcing can be expensive in terms of compute costs and wall-clock time, while low-level optimizations can take a lot of developer time.

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

#144

Earlier quoted context omitted.

> but these days I think the much more important skill is designing systems. It is hard to design systems if you don't have the perspective of implementing them. Yes, you move up the value chain to designing things, no, but no, you don't get to skip gaining experience lower down the value chain. > What computer science doesn’t teach you is how memory caching works in CPUs. That was literally my first quarter in my CS…

I think CS 30 years ago was closer to computer engineering today. At my uni 10 years ago the CS program didn’t touch anything related to hardware, hell the CS program didn’t even need to take multivariable calculus. In my computer engineering program we covered solid state physics, electromagnetism, digital electronics design, digital signals processing, CPU architecture, compiler design, OS design, algorithms, softw…

We (at a public research university in the US) designed a rudimentary CPU, wrote mips assembly, and understood computer architecture for our CS degree. I graduated 6 years ago

Edit: we also did formal methods and proofs as part of core curriculum

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

#145

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 de…

> I don’t know if distributed systems is consider part of “Computer Science"

It surely was part of my Informatics Engineering degree, with Tanenbaum book being one of the required reads.

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

#146
post #27

Earlier quoted context omitted.

I think in the context of the book 'procedural epistemology' encompasses all programming, not just what you'd call procedural programming.

Hmm, I don’t think so. Functional programming is definitely based on the “declarative point of view taken by classical mathematical subjects”.

My understanding agrees with namaria's. I'm inclined to think that, in the passage you provide, `imperative' means `pertaining to processes' (where processes are those things described by procedures; or, perhaps better put, the meanings of procedures).

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

#147

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 de…

> but these days I think the much more important skill is designing systems. It is hard to design systems if you don't have the perspective of implementing them. Yes, you move up the value chain to designing things, no, but no, you don't get to skip gaining experience lower down the value chain. > What computer science doesn’t teach you is how memory caching works in CPUs. That was literally my first quarter in my CS…

Concur. 15 years ago, as sophomores we built a functional virtual cpu from the transistor level up. As I recall that was about 4 weeks, for the rest of the course, we extended the CPU with cache, extended opcode support, bus expansion, implemented a lexer/parser and ended writing our own assembly subset implementation and using that to write programs.

As for the OP's contention that computer science doesn't teach you to look for higher level things like cache thrashing, I wholeheartedly dissent with that supposition.

I recall at least 3 courses where substantial coursework was devoted to hacking, stack smashing, reverse compiling, profiling/introspection, kernel modification, so much beyond 'dynamic typing is an OO antipattern' stuff that gets IMO erroneously conflated with CS degrees.

Maybe these shit schools exist, but in a top 20 program you will definitely learn cache pitfalls.

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

#148
post #38

Earlier quoted context omitted.

I find books like SICP interesting and not very useful. I love reading them because I like this stuff, but I don’t get to apply their teachings in real world software. It’s a problem because naturally I want to spend my time reading these kind of books, but if I do that I would be jobless. I need to divide my time between reading pearls like SICP and boring Kafka/Postgres/Golang/K8s/AWS documentation.

One of the problems I've seen is that when new learners and self-taught individuals ask for advice, a lot of software engineers give recommendations based on what they wish their job was or how they would like to imagine themselves.

This is a real problem that people with experience put on learners. If you asked them how they learned it, they'd tell you an entirely different story about starting small, practicing often, trying many ideas, having a strong motivation and some occasional guidance. But they tell others to follow a rigorously defined path which creates the opposite mindset that a learner needs.

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

#149
post #43

Earlier quoted context omitted.

I hadn't, that looks excellent.

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 inspirati…

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.

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

#150
post #70

I really wanted to like SICP but Lisp throws me off. I love Haskell and Standard ML however! Did others have a similar experience? Might be interesting to read a book similar in spirit to SICP but using a different language as a vehicle (No, I don't want to do SICP in JavaScript).

SICP isn't a book about Lisp, however it uses some of Lisp's unique properties to demonstrate important concepts that other languages can't easily replicate. A book that's meant to be similar to SICP that doesn't use Scheme or Lisp would not be anything like SICP, or at least not teach the same things. Haskell and ML are in my experience much harder to understand than Scheme, so I'm wondering what your difficulty is?

I don't have a difficulty writing Lisp. It's just not my style. I don't like S-expressions. I understand this is not too big an issue and it's very likely I'll get more comfortable with it given enough time. It hasn't happened yet.
Post reply on HN