We all know SICP is recommended by experienced developers all over the internet as a mystical book that turns your mind inside out and makes you a better programmer and computer scientist after you work through it.<p>If you are someone from that gang, what did you learn from SICP that really caused this transformation? What did it do differently than other programming languages or CS books?<p>Have you had similar experiences with other books (Lisp based or not)?
If you try to learn programming in any other language, there is always a mountain of syntax to learn. An undergraduate course in programming basically introduces one new syntax (conditional, for loops, while loops, functions...) and the concepts associated with it every week.<p>SICP has an extremely short description of syntax at the start, and how it is parsed. The rest of the book is about the structure and interpretation of computer programs. You just build structure by building abstraction after abstraction using the same basic syntax for everything. You interpret by referring to the parsing order. The language fades into the background - at no point are you referring to your syntax cheatsheet, it is all the same.<p>Instead you think about how to reason. And how to transform that reasoning into structured programs.
I recently looked at SICP again after first reading it many years ago. I had retained the overall impression that SICP demonstrates how to build many of the celebrated creations of computer science - interpreters, compilers, databases, logic programming systems, circuit simulators - using a very simple programming language with just a few constructs.<p>But I had forgotten many of the details. Here is just one: in 3.1.1, Local State Variables, SICP shows how to, in effect, define classes and create objects using only function definition with lambda and set! (that is, assignment) in the definition body. The function you define this way is a like a class, the functions it returns are like instances. So you can do all this without any specifically object-oriented language features. This occupies just a few pages near the beginning of a long book - the whole book is dense with worked-out ideas like this.<p>I would add that the cumulative effect of all these examples in SICP is to demonstrate that you can solve any programming problem from first principles - that is, by combining a few simple but powerful constructs in the several ways they describe. Moreover, a solution constructed this way might be simpler and easier to understand than a solution made the more usual way: by looking for a specialized language construct or library that seems to offer an already-made solution to the problem.<p>(This is copied from a comment I made here several years ago: <a href="https://news.ycombinator.com/item?id=8495934">https://news.ycombinator.com/item?id=8495934</a>)
I didn't read the book, but I watched the recorded [lectures][1]. I got the sense that course was the tip of an iceberg of an entire academic discipline of programming philosophy and practical wisdom. On its face, though, it is an introduction to programming that starts with symbolic substitution, moves on to mutation and other tricks, and then I think gets into interpreter design.<p>If you want your mind blown, read "The Little Schemer" (or the original "The Little Lisper," or another of its variants). I particularly like the section near the end where the Y combinator is (secretly) described. The goal of that book is to "teach you to think recursively." It's not about writing recursive functions at work, but about appreciating the self-referential properties of algorithms.<p>[1]: <a href="https://www.youtube.com/playlist?list=PL8FE88AA54363BC46">https://www.youtube.com/playlist?list=PL8FE88AA54363BC46</a>
What I like about SICP is how it shows how several different moderately-advanced (for an undergraduate) programming concepts are all related by a basic model of computing that's defined in the book.<p>It builds from first principles (among other things):<p>* (the core) the lisp metacircular evaluator<p>* computer algebra<p>* logic programming [1]<p>* a register machine<p>* a compiler targeting that register machine<p>(lazy evaluation, streams vs. lists, concurrency, and more)<p>I can't think of any other book in the undergraduate canon with that kind of breadth.<p>Personally I didn't really see any of this for the first time in SICP: I think I'd already had the whole "programs are data" epiphany from learning Haskell and reading PL-related papers before I read SICP. Still, it's really fun to see so much collected in one place.<p>(I think the fun part of learning new programming languages is the concepts they teach you. e.g. in my opinion there's another fun "reasoning is a syntactic operation" moment you get from learning a language like Coq.)<p>It's been a while since I looked at it but I remember enjoying "Concepts, Techinques, and Models of Computer Programming (van Roy and Haridi)" for reasons similar to why I liked SICP. (It's a little less broad, but has the same subject of ~"here are a bunch of different models of computing and how they are all related by the same fundamentals").<p>(Also, poke around <a href="http://lambda-the-ultimate.org/" rel="nofollow noreferrer">http://lambda-the-ultimate.org/</a> and check out Guy Steele's Lambda the Ultimate papers if you haven't already.) <a href="https://dspace.mit.edu/bitstream/handle/1721.1/5790/AIM-353.pdf" rel="nofollow noreferrer">https://dspace.mit.edu/bitstream/handle/1721.1/5790/AIM-353....</a> <a href="https://dspace.mit.edu/bitstream/handle/1721.1/6091/AIM-379.pdf" rel="nofollow noreferrer">https://dspace.mit.edu/bitstream/handle/1721.1/6091/AIM-379....</a><p>[1] You know, like Prolog? - from that "AI will solve all problems" moment we had in the 80s.
I didn't study SICP directly, but took a course which was inspired by it.<p>Perhaps the question needs the qualifier of whether you've encountered lisp before or not.<p>> ... What did it do differently than other programming languages ...<p>Ah. I don't think anyone would ask this if they knew lisp.<p>At the very least, you can approach languages like JavaScript, C, C++, Python, (etc.) with <i>broadly</i> the same brush where you're writing sequential code that essentially modifies structures in place. -- Especially with C, it's easy to imagine some kind of machine executing the statements. (Obviously, exact idioms vary between languages, etc.).<p>Whereas with lisp, you don't modify structures in place, and you're not writing code as sequential statements.<p>An example I still think is kindof neat from the SICP was writing the same functionality both as a 'low-level' recursive function, as well as making use of higher order functions to achieve the same thing.<p>> Have you had similar experiences with other books<p>I liked the ideas suggested in "Philosophy of Software Design".. it really emphasised the differences between an interface and its implementation; and how complexity arises from if the you need to know more than the interface provides, or if the interface requires more than it needs to.
Recent and related:<p><i>Ask HN: Is SICP/HtDP still worth reading in 2023? Any alternatives?</i> - <a href="https://news.ycombinator.com/item?id=36802579">https://news.ycombinator.com/item?id=36802579</a> - July 2023 (98 comments)
SICP is a multi-layered, intensely philosophical book and philosophical truths are not transmitted like pieces of eight but are made real through praxis.
It kind of gives you everything and is just a well written book that incrementally builds up abstractions in every chapter.<p>I found I got more from it the second time I read it after I had some experience programming. The first time I had almost no experience and was caught up in everything it was trying to teach and missed a lot of things.
It's hard to pin it down to just a couple of things, because I came across SICP early in my programming life and it changed so much of my approach to the art. But here are a couple:<p>1. It taught me to think of programming languages as constructed things, rather than just being "there" and immutable. In particular, to think about the purpose of each language feature, and separating features into core primitives vs. syntactic sugar that could be reduced to those core primitives. It becomes harder to do this for "complicated" languages like C++ and Python, because many of their language features are not for one purpose but bundle together lots of disparate ideas. But it's still worth making the effort to see what choices the designers of those languages made, and how different choices would give you different points in the space of programming languages.<p>2. Once you have a small enough "core language", you can start thinking about algorithms that operate on programs. I had always thought of programs as expressing algorithms that operate on data, but didn't think of programs as data themselves. Of course every program is text, but in complicated languages with many constructs it seems horrendously hard to write programs that operate on other programs and change their meaning. But if your language desugars to a simple core language, the ability to transform programs opens the door to techniques like automatic differentiation of programs, probabilistic programming (like Church), and many others. These would now be called domain-specific languages, but those are often thought of as limited toys for very specific tasks. Instead, I like to think how every task has the "right" language to express it, and when you do API design you're really embedding a DSL in some "host language".<p>Since you asked, the other big development in my approach to programming came from learning Haskell and embracing types as an elegant way of expressing universal truths about programs. Sometimes the type of a function fully determines what the function can be, like how the only function of the type (forall a) a -> a is the identity function; this idea becomes more revelatory with more complicated types.<p>I don't use functional programming very much in my day-to-day life, but I think learning these ideas has shaped my approach to every language. It's not really about the superficial "functional patterns" that people often think of, like using map and filter and such, which is often idiomatically wrong in many other languages.
This is the first I've heard of it after reading and researching on the net for a long time for a myriad of comp sci topics. Perhaps I'm just part of the 10,000 today, but I am surprisingly having trouble finding it being recommended out there. I'm quite interested in whatever blogs/news sites (beyond HN) have been recommending it. Perhaps it will help shatter whatever rock I've been hiding under?
It's been 16 years since I first encountered 'Structure and interpretation of computer programs' through one of my CS courses.<p>It, and by extension Scheme, showed me the power of lambda calculus for the first time.<p>Couldn't really mention much else about that book today to be honest, though I am sure it exposed me to other ideas as well. Just can't remember.
For anyone wanting to take SICP not in Scheme/Racket, there's last years JavaScript edition: <a href="https://www.amazon.co.uk/Structure-Interpretation-Computer-Programs-Engineering/dp/0262543230" rel="nofollow noreferrer">https://www.amazon.co.uk/Structure-Interpretation-Computer-P...</a>
I read most of it during college and it taught me recursion and first class functions pretty well. The former helped me in my college classes and the latter in both college classes and at work. I picked up functional code faster than colleagues of the same age as me.<p>I don't think it "blew my mind" or opened up a new world to me though, but learning how to solve problems with basic tools was fun.
You realise that all of modern software development is designed around the idea of programming as bricklaying rather than as a skilled craft… but it didn’t have to be that way.