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.
See also "shift left"
> All the information _has_ to exist somewhere, and the only question is where.
Not entirely sure what you mean about this, but not all type information has to exist somewhere. Sometimes things get encoded into a type that might never be represented otherwise -- like whether an integer is a width or a height, or whether a string is a name or an address.
Then the code is written to make sure you never make the mistake of sending a width to a height, because that would be silly.
The type (width or height) is represented as logic in the code.
theoretically - if you have a type system that allows you to know something is a width or height you can often reduce logic to keep track of these things but my experience is that level of granularity in your typing reduces dynamism too much. I would rather keep track of that in code (as it probably will have to deal with it anyway) than make my type system deal with it.
But note that to make all of that work well you really need your language to provide a lot of syntactic sugar features which are missing in most older languages, so all the operations read seamlessly, instead of being full of ceremony. One could do all of this in, say, old Java 1.4 or something, but the amount of type annotation, along with the massive mounts of boilerplate to get all of the operationg working right, and checked at compile time would make it all Not-Worth-It(tm) But with enough language features, and a smart enough compiler, `val acc = mySpeed / someSeconds` will work, straight up, with the safety included.
I was thinking about this as I was reading your comment, and wondering: is it nonsense? If I have 5 seconds of time as well as 10 milliliters of water... I can consider them as being packaged together... which is addition. And I can subtract 3 milliliters and 6 seconds from them without running out of what I had. Nothing wrong with that, really. Five potatoes and a gallon of water is the same notion, just more familiar. Seems no more nonsensical than dividing length by time, right? Food for thought...
Which means, for example: (3 liters and (i.e. "+") 6 seconds) + (4 liters and 2 oranges) = (7 liters and 6 seconds and 2 oranges). Perfectly sensible addition, which you do all the time. There's no stipulation the output has to be a single number...
The point is, making a vector, that's not addition.
> because it's very much not
I don't expect to change the mind of someone who thinks that addition and defining a vector are the same thing. You've just redefined generally common terms and then started accusing people of being uneducated for not sharing your own eccentric definitions. Poor show.
I didn't intend that to be rude, I was pointing out this is something everyone learns in a standard curriculum i.e. that this is very much the opposite of esoteric. But you seemed determined to reply that way, so I'll stop here.
surely, you have an idea of what you're using that function for, while you're writing it.
The compiler is doing a check to see if the function makes some minimal logical sense (ala, a typecheck), but it cannot read your mind. But this implies the types are actually an actualization of the thoughts in your head, in a formal manner.
Is a pretty bad system because you say "won't even exist in your head" but I dont even know if I should pass it integers, floats a srtring. Or what it will return.
I'm skeptical that sophisticated type systems need to exist.
Perhaps I should dust off my copy and start reading SICP
I'd say for the vast majority of developers, experienced or otherwise, it's a good read.
</Slashdot_nostalgia>
> why don’t you just start reading it and decide for yourself?
A journey of a thousand miles....
You do understand that you don't have to read an entire book before forming an opinion, right?
> sort through everything that exists
"Book that has been considered a classic for forty years and was used as the intro text at MIT for decades" is a long, long way from "everything that exists".
You asked if you should read it, and almost everyone who bothered to reply has said yes. Each time this topic comes up and people ask if they should read it the majority of responses are 'yes'. And I presume if you've been around software for that long, you've seen all of those threads and previous questions and answers like I have - meaning you likely knew what people would say when they responded.
So, in the end, it's up to you to decide if you'll read it or not.
I don't know you personally, but from my life experience it sounds to me like something I've seen in other circumstances. You've more or less decided that you're not going to read it, but feel like you're missing out and you want someone who as read it to say "it's ok to not read it". So you can resolve both the feelings of the decision to not read it, and the uncomfortableness of feeling like you're missing out.
It's possible I'm way off the mark on the above, but I mean it to be helpful - as I can say I've seen what looks to be this same pattern many times in life.
or what you're likely looking for: In the end, there are only so many hours in the day. You gave it a fair shot and it wasn't your vibe. It doesn't say anything about your strength as an engineer, it just has a specific approach and it's not a match for everyone. That doesn't make it a bad thing, it just means you'd rather spend your time learning and exploring in other ways. And it probably would've had more impact earlier in your career than at the level of experience you have now.
But of course before wrapping up I do need to undo my comment: I think you should give it another go. Maybe skim past the early part if it feels a bit to introductory and come back to it later. But it's a book that continues to grows on you the more time it's been since you read it. The concepts it presents are subtle but impactful in changing how you think about software. You don't fully grasp it when you read it. It's just that afterwards you just start seeing things through its lens often. I haven't read any other book like it.
"We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time." - TS Eliot.
You aren't a curious person who studies things for their own sake and finds wonder in exploring ideas. That's fine, this book is clearly not for you so why concern yourself with it? Most of my friends who are obsessed with their field count many intro books as their favorites and frequent re-reads.
> condescending promises of enlightenment.
It sounds like you're more upset that other people enjoy and therefore recommend this book. You're the one asking for proof that it's worth your time. It's clearly not. People who are curious and like to explore ideas in computing recommend this book frequently to other like minded people.
If you don't like sushi, why question somebody's recommendation for their favorite omakase place?
Right?
> Yet people promise me that this one is different, while giving me nothing but condescending promises of enlightenment.
You do understand that it's possible for different people to place different values on the same thing, right?
I mean, clearly there are many, many people who do find the book valuable. You're not one of them. That's fine! But it doesn't mean the book sucks.
By just about everyone who's ever compiled a list of the greatest CS books of all time?
Here you go:
https://duckduckgo.com/?q=classic+computer+science+books&t=b...
Count how many of those have SICP on their list (hint: most of them, excluding the ones that aren't actually lists of CS books -- e.g. the ones that have Jobs and Gates biographies, etc.)
I didn't just make that up, dude. And this isn't Wikipedia, either.
You don't have to read every word of a book to understand if it's interesting to you. I purchased a bunch of technical books the other day that I had never heard of based on opening them up, reading a bit of the intro and flipping through the examples.
Relatively few of my favorite books have come through recommendations compared to those that I have come across through serendipitous discovery.
For anyone who has no time to browse books, then most of the best books in existence would be of little interest to that person.
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.
> 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.
---
https://www.stilldrinking.org/programming-sucks ( https://news.ycombinator.com/item?id=7667825 and others)
> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
I recommend (not ironically) Double Binded Sax by the group named Software.
After you finish that, I recommend queuing up Friedrich Nietzsche by Klaus Schulze.
Not GP, but my time is limited, so asking "is this something an experienced programmer would find worthwhile and insightful" is a fair question.
But I find the book a marvel of pedagogy and rank it as maybe one of the greatest textbooks of all time across disciplines. The lessons are packed so densely yet so concisely that you'll appreciate different things on successive reads.
If you're experienced it will also read very easily and quickly so it then becomes quite an easy and enjoyable skim and then you don't have to rely on other people's accounts of whether it is or isn't worth your time.
Watching 2-3 of these will probably answer your question.
[1] https://groups.csail.mit.edu/mac/classes/6.001/abelson-sussm...
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).
It’s free online. And YouTube has lectures from the authors- presented in all their early 80’s glory.
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.
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.
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.
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’d say it’s actually more valuable to people with programming experience. It gave me a greater appreciation for solving complicated problems in elegant ways. And perhaps ambition to solve other more practical but still complex problems in similarly elegant ways.