51–60 of 82 posts
Without an easily verifiable way to test your solutions as you go I think these kinds of books really do themselves a disservice as you lose the ability to struggle and think hard about the problem if you can't immediately solve it.
Earlier quoted context omitted.
I read the book for the first time later in my career and for me the chapter 4 about metacircular evaluator combined with the video lectures was and still is mind blowing. When I was a freshman I was learning to do for loops with Java when SICP teaches how to create your own programming language...
The insight that "code is data" and should be viewed as such is very well treated by lots of literature/languages. Tons of languages support "eval" and building an AST is really not that difficult. I think SICP might be a popular entrypoint to interpreters but probably not the best.
Earlier quoted context omitted.
It's a lisp dialect form the MIT called scheme. You can find more information here: https://www.gnu.org/software/mit-scheme/
I guess racket is where the development continues for the scheme language. http://racket-lang.org/
This is incredibly beautiful. I wish all technical writing online could be so well presented - I'm tired of trying to read two-column journal-formatted PDFs on my phone.
Earlier quoted context omitted.
It's a lisp dialect form the MIT called scheme. You can find more information here: https://www.gnu.org/software/mit-scheme/
I guess racket is where the development continues for the scheme language. http://racket-lang.org/
Earlier quoted context omitted.
The insight that "code is data" and should be viewed as such is very well treated by lots of literature/languages. Tons of languages support "eval" and building an AST is really not that difficult. I think SICP might be a popular entrypoint to interpreters but probably not the best.
Perl supports eval like lots of languages because data CAN be code. It's only in homoiconic languages like Common Lisp, Scheme, Racket, Clojure, and Rebol/Red that code IS data. Just because you have EVAL doesn't make it a 1:1 relationship and that makes a big difference. If your code/data is just a big AST, then macros are trivial and that prompts you to write DSLs...etc.
Earlier quoted context omitted.
First of all, it's an introductory text that provides a practical whirlwind tour of introductory computer science. Second starts from a straightforward place (when the first edition was written it was quite reasonable to assume that a student arriving at university, even MIT, might never have programmed a computer before) and after one lecture on the scheme language, dives in to practical details. Third, unlike, say,…
Right I always wondered if my opinion of it stemmed from the fact that I read it relatively late in my career. Never having fresh eyes on it, I suppose it's easy to take things like syntax and such for granted. That said, is Scheme really a good language for "not getting hung up on syntax?" It has an admittedly simple grammar but I can't help but feel that with the prevalence of ALGOL style languages, an intro studen…
Earlier quoted context omitted.
First of all, it's an introductory text that provides a practical whirlwind tour of introductory computer science. Second starts from a straightforward place (when the first edition was written it was quite reasonable to assume that a student arriving at university, even MIT, might never have programmed a computer before) and after one lecture on the scheme language, dives in to practical details. Third, unlike, say,…
Right I always wondered if my opinion of it stemmed from the fact that I read it relatively late in my career. Never having fresh eyes on it, I suppose it's easy to take things like syntax and such for granted. That said, is Scheme really a good language for "not getting hung up on syntax?" It has an admittedly simple grammar but I can't help but feel that with the prevalence of ALGOL style languages, an intro studen…
Remember the kids for whom this course was designed were going to be doing circuit design concurrently or the following semester. So the point was to learn composition, abstraction, modularity, algorithms etc, not syntax.
And Sussman was not the only one who used scheme to do a lot of engineering computation as well.
I have never considered Lisp syntax exotic. In any case, remember SICP was the text for a fundamental CS and Engineering class, not a programming class.
Unpopular opinion but having read this book, I think it's a "good" text that is a bit blown out of proportion in terms of how good it is. I'm curious for people that endorse to such a magnanimous degree what other literature they've read and what aspects of SICP in particular they find so superior.
The book was written a long time ago, yet they described MapReduce, and the industry took over 30 years to finally see the light. They described functional programming, and similarly, the industry took forever to catch up, though sadly FP is mostly being done very wrong.
In this day and age of "get a job at CompanyX with 2 months of study," I'd argue that this book is even more valuable. It is an introductory text (where nearly every intro text is water-down; online isn't worth speaking on) that teaches the implementation details of common data structures, along with many clever approaches and tricks, all written and explained without being overly abstruse. Sure current resources may teach you to set up RoR and plug in flavor-of-the-day javascript, but those who built the meta-circular evaluator rightfully roll their eyes at yet another JS... evaluator.