5 ms·
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
by banachtarski 10y ago
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.
- gumby 10y agoFirst 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, your average introductory programming class it doesn't get hung up on syntax; unlike an average introductory algorithm class the algorithm examples are typically on stuff a student would already know (numerical methods, etc) rather than super-abstract "consider a graph..." Finally it's an engineering text: if you do the problems you end up writing an interpreter for the thing that seemed so amazing on the first day and you discover you know how all the bits fit together.
- banachtarski 10y agoRight 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 student is better off just just biting the bullet and learning something more traditional. If I was going to teach things like type systems and such and was ok with exotic syntax, I might teach Haskell or something.
- yoz-y 10y agoAt my university the introductory programming was taught using scheme and I found it weird at first as I knew the more traditional approaches (personally I have taught myself programming first in Basic and Pascal). Later I have been assisting a professor during python classes and I have come to appreciate the benefits of a purely functional language for introductions (our teachers have strategically chosen not to talk about the `begin` keyword in Scheme). Many students have had really hard time grasping the idea of variables and scopes.
- Latty 10y agoBecause so many of us learn imperative programming first, then find functional a big shift, I think we forget that everyone learns maths, which has no mutable state in the traditional maths classroom written style, and so functional actually resonates pretty well with people who have never touched programming at all, provided they've been exposed to enough maths.
- banachtarski 10y agoThe weakness to this approach is that learning the functional approach is all well and good but you can't learn this at the expense of learning what the machine does. Learning a traditional ALGOL like C exposes you to memory access, the stack pointer, and other such concepts. You're also a small hop away from assembly where you learn about RISC/CISC architectures, CPU caches, etc. I wish there was a book as popular as SICP that people would read so that the understanding of what the hardware is doing is better across the industry.
- throwaway7645 10y agoI think the book shown with nand2tetris (maybe called the elements of computing) is pretty good going from logic gates to building Tetris. Also "CODE" and "Computer Architecture with the Raspberry Pi" are great.
- yoz-y 10y agoAll of that comes in but I think it is better to introduce an overview of what a computer can do and later explain how it is done. Motivation has a great influence of how well you can learn something. Swamping people with technicalities is a great way to lose them.
- brlewis 10y agoI used Scheme a lot in the past and currently help people get up to speed on JavaScript. I definitely think the IIFE syntax makes more sense in Scheme, and higher order functions are a lot easier when you end a block with ))) instead of )}; }) )};
- gumby 10y agoIt's funny you contrast it with ALGOL since ALGOL was explicitly cited as one of the predecessor languages used when designing Scheme (the other being Lisp) as Scheme is a block-structured language with lexical scope. And the programming style of SICP is procedural, not a functional or logic approach. 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.
- wsy 10y agoIt is particularly good for an introductory programming course to use something 'exotic', because that levels the field. Students who did some Basic/Pascal/PHP/Ruby/... in high school, who often think they already know what programming is, are forced to take a fresh look. So the steeper start pays off.
- pimeys 10y agoI 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...
- banachtarski 10y agoThe 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.
- throwaway7645 10y agoPerl 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.
- cutler 10y agoIt's also the concept of the reader which differentiates lisps from languages which attempt the same thing with eval.
- banachtarski 10y agoRight, I'm not even just talking about code as data in a homoiconic sense but literally just, code is a bag of instructions (jumps, load, store, add, etc) regardless of if your language is homoiconic or not. Maybe the point that can be made is that exposure to a homoiconic language earlier helps bridge this gap faster?
- throwaway7645 10y ago
- dizzystar 10y agoReading the book isn't really good enough. The lessons are tucked into the well thought-out exercises, which is a feature that isn't found an many other texts. 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.
- banachtarski 10y agoOh I should say, I did the exercises too. My background is in math and I'm very accustomed to the meat of the book being in the exercises (I'm looking at you Springer).