Why "Structure and Interpretation of Computer Programs" matters (2011)

The only way it would have "benefited" would be that the web would only be developed by lisp programmers.

To the vast majority of programmers, syntax matters. C-style with brackets, or python whitespace, or Ruby do/end, these fit better the brains of the majority of programmers. Perhaps not the majority of HN readers but the majority of corporate devs.

Another example of this is Erlang and Elixir. Elixir adds a couple of features over Erlang, macros and protocols, but Erlang does everything else. What made Elixir take off where Erlang didn't, after decades, is that Elixir has a syntax that people are comfortable with. Erlang has a syntax that will summon Cthulu.

JavaScript was originally developed in two weeks due to time constraints from Brendan Eich's employer. It would probably have just as many design mistakes if he had stuck with a scheme-like syntax instead. It's just hard to create a well-designed language in such a short amount of time.

As someone who's both versed in Lisps (CL, Racket, Scheme, Clojure) and JavaScript: thank god.

It's like the Lisp crowd can't be honest with itself and not realise the serious shortcomings of lisp projects are: maintainability.

Every single lisp project out there, hell this also applies to Haskell, is so radically different because everybody's too busy reinventing its own abstractions and macros (and language extensions in case of Haskell) that you just throw your hands up in the air in dismay.

It's like the Lisp crowd, that can barely attract like-minded people to collaborate on some simple open source projects out there so you get 20 broken JSON parsers, cannot see the link between that issue and industrial lisps.

I love lisps, they are fun, they have their place in the industry when you leverage them to their core strengths.

Try to ask yourself: why does PHP has more quality killer-software than all of lisps combined?

ECMAScript 2015: proper tail calls are now in the spec

Chromium: we’re not doing proper tail calls

having call/cc would make my life better

I should write a Lisp browser.

R5RS Scheme (standardised in 1998) didn't even have structs. To make anything like the DOM practical, you'd have needed some non-standard extensions that could well have ended up being a mess anyway.

Hey, at least there’s Clojurescript.

I started reading it around a year ago with the personal goal of doing every exercise. I'm not done yet (almost done with chapter 4). It has definitely taken a lot of my time, but it really has changed my thinking about a lot of language constructs I find in other languages.

For instance, the part about tagging objects with their type reshaped my thinking about static type systems in general. Static typing, for example in C, is essentially just moving the location of the type tag from existing at runtime within the struct, to the "analysis" phase of the compiler. It's a pretty simple idea, but it made the "degree of dynamism" tradeoff click in my head. All the information _has_ to exist somewhere, and the only question is where. And Scheme is just at an extreme where the _everything_ is stored dynamically.

Yes. But instead of taking my word for it why don’t you just start reading it and decide for yourself?

I think it is, and if you don't want to take my word for it, John Carmack thinks the same :)

There's an old video [0] where he talks in-depth about his explorations of functional programming. It's perhaps a bit more about Haskell than about SICP, but in it he's also quite enthusiastic about what a veteran programmer can still learn from this book.

[0] https://youtu.be/1PhArSujR_A?si=OD8pGYsoGC7RXPVG&t=125

"Don't cast your pearls before swine".

When I was younger I used to passionately defend those things I've seen as beautiful, but after years experience talking with people passionate about their fields and learning and those who never will be: If you lack the innate curiosity to explore those things others have declared marvelous, then this book will offer you no value.

Every time I crack this book open I get excited and I've read it multiple time and one most of the exercises. I can think of few other books that really expose the beauty and simultaneously strong engineering foundations of software.

You have "tons of experience programming" and sound like you've already decided you know what needs to be known (otherwise why even ask rather than just read it free online), I doubt this will offer you anything you haven't already seen before.

That depends entirely on what kind of a ton of experience you have. If you have written Java/PHP/Python/JS for 20 years, SICP might teach you lots of new tricks. If you have worked a lot with functional languages, probably fewer, but still probably some in later parts of the book.

No

Reading that book made me good at recursive programming :-)

I’d personally say especially so. I’m guessing those taking it as freshman are missing out on 75% of the good stuff.

It’s free online. And YouTube has lectures from the authors- presented in all their early 80’s glory.

Whether it's worth reading isn't a question others can answer for you, but "a ton of experience programming" definitely doesn't imply it isn't worth reading as it's perfectly possible to get through an entire programming career without encountering the ideas and ways of thinking that you'll find in it.

Yes, I bet it will give you new perspective on a number of things.

That book was my first programming class and programming ever: CS61A at Berkeley. When I started taking it, one of the TAs said that the ideas in the class were wasted on us - they seemed simple but we wouldn't grasp the fullness of the ideas until we had more experience. He said the class should be required to take twice: your first and last class.

It gives you basics of things like recursion and message passing that are easy to use immediately (well, once you figure them out -- it took me two weeks to be able to write even the simplest recursive function), but there are large conceptual things you won't really see the depth in until you have more experience. The last project is the meta-circular evaluator - writing a scheme program to interpret scheme programs. It is difficult to understand that without having a lot of other background.

Even then along the way learning things like exceptions as implemented through call/cc might be a little too much for a beginner programming. The book is in some ways talks about concepts way outside of a beginner's comfort zone.

well worth reading even for veteran senior engineers. worth re-reading every few years too.

Depends on what you learned during that "ton of experience programming." My only regret was that I had, but stupidly ignored, the MIT course notes that preceded publication of SICP. I didn't realize what I had missed until many years later when I sat down to work my way through SICP. I coulda been a contender.

No. If you want a deeper understanding of programming, write your own static analysis / theorem prover.

It definitely is a "classic" book for a good reason.

I think it really depends on your actual formal education, how valuable this book will be to you. If you have a CS degree basically everything in there should have been covered during your studies, you already know how to operate on trees, recursive algorithms and how to build an interpreter. The main value to you would have been seeing it all come together in one place.

If you don't have that kind of education I believe it is extremely valuable to see programming from a theoretical perspective. The book is very good at laying out a cohesive narrative of how you go from very basic structures to complex programs and how these programs can be executed by a computer. The highlight definitely is the implementation of lisp in lisp.

There were also chapters, mostly towards the end, which I think aged quite poorly and seemed mostly irrelevant. I don't think there is much lost by skipping them.

Depends on the kinds of experience. If you have experience writing compilers and interpreters - probably not a lot. If your experience is in application development you might learn a lot.

I worked through it after years of practical experience as a self-thought programmer, and I learnt a lot (and found it quite challenging, especially the mathy parts).

Only if you’re comfortable being converted to lisp

I used it as a teaching aid to help colleagues from our application teams get the background and skills to work on our core platform. I certainly got a lot out of it because I had to do all the exercises, and I think if i hadn’t had to prepare like that I would have skimmed more and gained less. But I already had a background that covered a lot of the same areas.

So it is going to depend a lot on your background and the effort you put in. It may be better done as part of a reading group where you can discuss the exercises than on your own as some are meant to highlight why certain approaches are hard and are not commonly used.

I would say yes. I read it when I was already an experienced programmer and I still found it worth it. Scheme is one extreme in terms of styles of programming languages, and it allows the authors to present a certain way of thinking about programming that was still new to me that is natural in Scheme.

I'd say it is less about your experience with programming and more about your interest in it. SICP has quite a profound style that's in between academic and poetic. For me, it was both fundamentally informative and inspirational. So, if you feel like structuring your computer science foundation and like an imaginative approach to programming and math that favors aesthetics, give it a try.

Experience in software development isn't linear so depending on which path your experience has taken it could be very insightful and useful, or it could be stuff you already know.

I'd say for the vast majority of developers, experienced or otherwise, it's a good read.

Haven't actually done the book. Can vouch for the lectures[1] though. Very much worth it to get a different perspective on various language structures I had just taken for granted.

Watching 2-3 of these will probably answer your question.

[1] https://groups.csail.mit.edu/mac/classes/6.001/abelson-sussm...

I wouldn't have spoken up except for this comment. As a freshman, I took 6.001, the MIT course that Structure and Interpretation of Computer Programs was based on, and I loved it. As a graduate student, I taught 6.001 three times, twice as head TA under Prof. Sussman and once under Prof. Abelson. In addition to helping make up problem sets, quizzes, and exams, my responsibilities included teaching seven or eight one-hour, five-student tutorial sessions per week as well as teaching a forty-student recitation section once per semester. I graded assignments as well. My point is that I have a lot of experience with what students found challenging in the course.

Prof. Harvey's claim rings completely true to me. Students understood the syntax quickly, and spent little time on it. It was not a point of frequent confusion. There were plenty of difficult concepts in the course, but the details of the programming language were not, for most students, among them.

Students who already had programming experience when they started the course often had more trouble than inexperienced students, but mostly because they had to unlearn imperative habits since the imperative features of the language, except for I/O, weren't used until late in the course.

SICP covers a huge breadth of material, from basic computational ideas to algorithms and data structures to interpreters and compilers to query languages to concurrency, and does it in an entertaining and challenging way. Even decades later, I find myself pulling ideas from it in my daily programming work.

I worked at Google for almost twelve years, and I can't count the times I found myself muttering, when reading a design document, "I wish this person had read SICP."

I'm certainly biased, but I would encourage anyone who would like to become a better software engineer to read SICP and study it carefully. Take your time with it, but do read it.

It is quite hard to even tell a noun from a verb

What?

Unless the list is quoted or something, the first item after the opening paren is always the "verb", yes?

Does it beat OO Java classes with students crying ? or months spent on warning kids not to mutate an iterator or else you're gonna cry again ?

Mostly kidding but different paradigms bear different pain points it seems.

Oh and lastly, the let-us-care-not-about-syntax is also an argument at Brown edu (krishnamurti and his team IIRC)

That said, I'd be curious to hear what your students had to say about scheme confusing traits.

Why would the students be confused? By what exactly?

This "everything looks the same" property of Scheme and of all LISP-like languages is a bug, not a feature.

But you are mixing up things here. There are things that look different. Most things in Scheme can be understood as function calls and match that syntax, but there is different syntax for define, let, cond, if, and others. Not everything looks the same. What you might actually mean is, that everything is made of s-expressions. That is actually very helpful, when you work with code. It makes it very easy to move things around, especially in comparison to languages like Python, with significant whitespace indentation.

When the semantics is different, humans need the syntax to be different.

I learned multiple languages before Scheme, and they did leave their scars, but I find, that I do not need syntax to be that much different. Maybe I am not human.

In contrast, LISP/Scheme make everything look the same. It is quite hard to even tell a noun from a verb.

Is that a feature of the English language? I have rarely had this issue in Scheme. Perhaps it is because I think a lot about names when naming things.

This makes learning it and teaching it hard, not easy.

Maybe I only had bad classes and lectures before reading SICP on my own, but I found, that I learned much more from it than most teaching before that was able to teach me.

Brian is selling a fantasy here. If you think Scheme is so great, look at this nightmare of examples showing the various ways to implement the factorial function in Scheme: https://erkin.party/blog/200715/evolution/

And what exactly is your criticism?

That there are many ways of writing the function? That is a property of many general purpose programming languages. For example we could look at something like Ruby, where it has become part of the design to allow you many ways to do the same thing.

Or the richness of programming concepts available in Scheme? Is that a bad thing? I think not. You don't have to use every single one of them. No one forces you to. But am I glad to have them available, when have a good reason to use them.

Surely you are aware, that the page you link to is at least partially in jest?

All of this "abstractions first, reality second" agenda is just a special case of what I call "The Pathology of the Modern": the pathological worship of the abstract over the concrete. Everything modernism touches turns into shit. I am done with living in modernist shit and I hope you are too.

I don't know where you got the idea, that SICP lauds "abstractions first, reality second". This is not the essence of SICP. SICP invents abstractions, once it shows, that some previous approach was not sufficient. A good example is the whole "develop a package" thing, where piece by piece the requirements grow and data directed programming is introduced.

Just an anecdote.

I took CS61A by Brian Harvey in 2009. I loved the course and I actually spent very little time learning the syntax and most of the time learning the concepts.

So I fully agree with Prof. Brian Harvey here.

Bullshit. Again, I was a TA for this course. You do not spend the rest of the semester on ideas, you spend the rest of the semester on the students being very confused.

I was a TA on an SICP course at a UK university, disagree with you. The students weren't confused, the simple syntax really helped and, because all the students had good maths knowledge, a functional style was a lot more intuitive than imperative.

FYI, the course has since been replaced with Python programming.

A funny thing to me is I took CS 50 in '85 or '86 (CS 50 and CS 55 were later split into the CS61X series), and instead of Scheme we used Logo for functional programming.... using Brian Harvey's textbook. He was not teaching the course that semester.

At least part of the goal of CS 50 at that time was to explicitly weed students. They didn't want undeclared students to waste a whole lot of time on CS only to find out they were not going to be accepted into CS. Instead, they went through one hard course to find out. Perhaps that explains why some of it was overwhelming to some students?

You could also portray this as yet another case of theory trumping practice, which is also symptomatic of modernism.

The idea that a language based on a small, elegant set of composable primitives is inherently better for programming in the large as well has not been borne out in practice.

Upvoted for an interesting take, even though I disagree with some of it.

I took 61A from bh. Personally, I agree with bh's statement that you quoted. Where I encountered difficulty was applying the ideas in a different context (e.g. C or Java). Brian spent time addressing this precise difficulty (in the last lecture or so), but it still wasn't enough for me.

I do heartily agree with you calling out "the pathological worship of the abstract over the concrete". Knuth's Concrete Mathematics was also bucking this trend (e.g. https://youtu.be/GmpxxC5tBck?si=tRHQmuA4a-Hapogq&t=78). I'm curious, once you came to this opinion/realization, how did your teaching/learning change?

I won't dispute your experience, but for me the point did hold true. SICP was my first introduction to anything Lisp-like, and by that point I'd done C/C++, a bit of Java, quite a bit of Perl/Python, and of course BASIC.

And I was really surprised how quickly and effortlessly I picked up the part of Scheme taught in the book. Faster than any language I had encountered thus far - Python included.

I tried Racked with the recommended IDE setup (VScode), does that have structural editing?

Here are my notes from 2023-07:

https://docs.racket-lang.org/more/index.html

    * okay, seriously. functional programming is nice, but these fucking parenthesis are ridiculous. the VSCode extension is okay, but doesn't help at all with formatting, etc.
    * "car" and "cons", yeey, but "first" would have been so hard?
    * the whole "define x 'x" is also meh.
    * no return, so sometimes something just takes the last one and returns.
    * there's string->url ... why not string->parse-url .. no, would have been too verbose. MAYBE YOU COULD HAVE SAVED SPACE BY OMITTING THE FUCKING PARENTHESES
    *

ehehe ... well ... I think I will keep trying it again every few years. is there a pythonish version, where indentation matters and no need for wrapping parens?

I complain about parentheses, and yet I'm building a structure editor[1]. Two complaints about parentheses:

- Parentheses obscure the structure of the language. When different syntax is used for different parts of the language, it's easier to visually scan the code. This is simply because punctuation/arrows/etc. visually stand out more than plain identifiers.

- Parenthetical languages have just as much syntax as non-parenthetical languages, it's just a shittier syntax. Try writing (let (x 1) (y 2) (+ x y)) and see what happens: it's a syntax error. Look at the indentation rules in DrRacket: there's let-like, cond-like, etc., because all of those constructs have different syntax. But it all kind of blends together in a sea of parens.

This weakness of paren-heavy languages is also their greatest strength, though. Since the syntax is so generic, it's easy to extend, and these language extensions can be indistinguishable from the base language. That's a big deal!

BTW, what structure editor would you recommend? Which have you tried?

[1] https://github.com/justinpombrio/synless

I love SICP, but I will say this: there's a certain class of "great" textbooks that sometimes get recommended by experts, that aren't actually that great for someone learning something for the first time. They get the reputation as being "great" because they are great for people that already have a good basic grasp of the material: They are precise and pithy, and they contain insights that are deep and useful, but hard to appreciate if this is your first encounter with the material. (Kleppner & Kolenkow would be a good example of a freshman physics textbook in this category.) With all due respect, I would put SICP in this category. Which, of course, is a noble and important category, but maybe not the most important category if you're just starting out on a topic.

Very good point. That was literally the magic of early Basic. One could do something quickly. And the imperative nature of the language gave a simple point of attention mental model. I feel that point is lost in many criticisms.

When I was first introduced to computers, I was shown BASIC and Logo (Apple II plus). Logo felt a lot like a LISP (at least, that's how it was presented to me... ) with a very easy way to make graphics (turtle model).

I couldn't really get into Logo- it felt too indirect, too computer-sciencey, so I went into BASIC and later Machine Language to learn how to build games (I was influenced by Choplifter, Lode Runner, Wizardry, and Ultima). It wasn't until some time later that I learned LISP and began to appreciate functional programming and the turtle model (I still am amused at how much I learned on that original Apple II that still applies today to tech like SVG).

I reflect a lot on how Norvig was a LISP guy and then when he saw what was happening in scientific computing, pivoted to treating Python like LISP (https://www.norvig.com/python-lisp.html and https://www.norvig.com/lispy.html) although I don't know that anybody really anticipated we'd have systems like Jax which really turn functional programming in an imperative language on its head.

The danger in demanding to just be taught how to be a good code monkey is that that increases your risk of getting stuck just being used as a code monkey.

My intro CS class was taught in Scheme. I haven't found what I learned in that class to be quixotic at all. Instead, I view it as setting me up with a strong foundation that colleagues of mine who learned in a more "popular" language lack. It's put me at a permanent advantage for designing and building software - even decades later, I find that there are ways of decomposing problems that I can understand easily, and colleagues of mine who learned on Java still have trouble with, because they simply lack the "design vocabulary" that would enable them to think about the problem in the right way.

We never again used the language past that first introductory course, but I still don't think it was a waste of time, because it allowed us to cover so much ground so quickly. In 3 months we went from basic fundamentals to building our own object-oriented programming system from scratch. That's amazingly powerful. A deep knowledge of what object-oriented programming actually is, and how it works under the hood, is usually considered an advanced and esoteric concept that few people really understand. Fast forward about 15 years, and having that kind of knowledge in my head allowed me to take a job at a Java shop, having never touched the language previously, and then within just a few short months have a deeper understanding of how Java works than colleagues of mine who had been using it on a daily basis for 20 years. So that they were coming to me for help with Java problems, despite having an order of magnitude more experience with the language.

Rewind back to school, and it's the same story. The second class in the freshman curriculum used C++. It was not a course in C++, mind - it was a class on algorithms and data structures. Learning C++ was just the first couple of weeks. And learning it mostly consisted of being taught the syntax and the build and debugging tools. The semantics for everything - pointers, classes, templates, etc. - took a negligible amount of time because it could be explained to us in terms of concepts we had already learned by building ourselves - in a 3 month intro class.

Quixotic features like functions and variables.

Edit: Sorry, was cranky from being hungry. I take issue with “useless in the real world.” The first chapters introduce variables, functions, recursion, and lambdas, and not much more than that. That’s the beauty of the book. Flexible ideas that are immensely useful and form a great foundation for learning computing. It’s not the best total beginner book, I’ll admit, but it’s a great beginner-intermediate book for those who seek mastery.

From personal experience, I can say a person can build a fruitful bread-and-butter earning programming career on the first two chapters of the book, provided you solve literally all the exercises. Such is the density of know-how and design context packed in there. This also makes the book a challenging read. I feel like the math-y content is also not for everyone. After all, it was aimed at MIT engineering undergrad students who are expected to have a baseline mathematical felicity well above the average high school level.

Hm... I read half of the book (with exercises) and stopped. I don't remember why, but it was probably OO for me too.

Is the 'How to get Scheme' still appropriate even though it was last updated in 2003?

Apart from another HTML rendition, there's also an e-reader-ready epub rendition (from the HTMLs obv.) at https://github.com/sarabander/sicp?tab=readme-ov-file#sicp

Similar themes. SICP is a little more academic. You build a compiler, do more math, etc.

PAIP also focuses more on Common Lisp specifics.

SICP isn't an algorithms book or a reference. It's very unlike The Art of Computer Programming.

I think your searchable resource is called a "software engineer".

I want a searchable resource where I give my inputs and desired output and brief description of the algorithm and it gives me the algorithm and code.

It sounds like you'd like to outsource your problem solving and thinking. Some things require work, and from that you learn and grow, which is the greatest reward.

With a 50% fail rate, I think the standard course load does a very good job of that anyway.

And here i thought the goal of SICP was to scare off folks who were getting into CS

Well, the acronym is pretty close to SCP...

And the best introductory lesson ever where they explain you what is programming.

My favorite class in college was my fundamentals of computer systems class.

It finally clicked how assembly instructions could draw images on a screen and all the magic inside my computer vanished instantly.

Big fan of dumb switch boxes