I am revisiting SICP at the moment, because a friend uses it to learn programming. But I have to say, I am not nearly as impressed with the book as I used to be. Wadler's critique "Why calculating is better than scheming" (http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p...) fully applies, and the book can be rather confused and ad-hoc in some places, e.g. section 1.3. A stronger focus on data structures would have been useful, instead of ad hoc recursion schemes, like version of `accumulate', `sum' and `product' they make you write in the exercises in that section, which are essentially unfoldr and foldr rolled into one---and would be better written as a composition of those functions.
`How to design programmes' (http://www.htdp.org/) leaves a better impression as a beginners' book for me.
Thinking on "Why calculating is better than scheming" vs SICP I realize that there is an axis where most programmer's ways of thinking can be placed, with 2 extremes:
- the mathematician-programmers: the thinking in terms of "what is" extreme, or mathematical thinking inspired programming: people closer to this like to think in terms of types and usually dislike dynamic languages, they also like to be able to properly reason about all aspects of a program, to have defined "states" they can think about. These people tend to like MLs, Haskell, OCaml, F#. The "mathematical beauty of perfect code" is their ideal and favorite metaphor. And I think they are right that teaching a Lisp to a beginner pushes ones mind away from "what is" oriented programming.
- the Schemers: the thinking in terms of "what transformations to apply to something (it doesn't matter what "something" actually "is") to get something else or somewhere else" programmer: these people like to be able to transform everything, including code itself, they like homoiconicity or macros in general, they prefer thinking in terms of "how to compose/cahin transofrmations" instead of types, they tend either no know or not value category theory too much and they are ok with seeing code as an "organic entity" that can't always be reasoned about. These people tend to like Lisps, Smalltalk and dynamic languages. The "programming as magick", in the sense of "controlling the spirits (processes) inside computers" is their favorite metaphor. They also like to maintain a playful mood and their "it's ok that paying customers get shafted every now and then" may have had a reason for businesses' dislike for "schemer" types and "schemer" realted technologies. As an offside paradox, some "schemers" tend to also like OOP, though they understand it should not be overused (I consider Alan Kay, usually mentiones as the father of OOP to be a "schemer"). I think that exposing a young learner to Lisp pushes one mind towards this direction, and this is why I love SICP. If you are a competent engineer you surely have a serious amount of math knowledge, so you can easily switch your mind to what-is/math mode and see the mathematical beauty when there is one to be seen, but most "mathematician-programmers" never seem to be able to love this "ruleless organic beauty" of the "schemer way".
I consider myself a "schemer" and I am biased to this side, but I understand and appreciate the value and arguments of the other - I'd rather fly in a plane with the control systems coded by a "mathematician-programmer" than by a "schemer" like me :)
"In my experience, relatively few students appreciate how much they're learning in my course while they're in it."
That quote describes me to a T.
The University of Minnesota taught a sophomore class on OO using SICP. At the time, C++ was hot (this was about 1991 or 1992) and I distinctly remember someone raising their hand and asking "Why are we learning this language that we will never use again? Why isn't an OO class taught in C++?" And I remember thinking to myself "Who cares what language it's in? I'm kind of excited about learning another language." And I truly was.
It wasn't until much later, after being in industry for a decade (currently starting my third decade now ;) )that I recall thinking to myself "You know, that book had a tremendous impact on how I write software and program in general, I need to pick that up again, what was it?" And I re-found it and am on my third reading of it as I write this, mostly just to refresh the ideas in my mind (since I mostly work in Java and JavaScript these days), but I have never truly finished the whole book. The class took us through chapter 3 and then sort of a mixed bag of topics from later in the book, so I've never truly read the whole book, but certainly enough of it to help me.
I didn't realize it was a famous book at the time, it was just our text book. I still didn't realize it was a famous book when I re-bought it a decade later. And now I know why it is a famous book, it is that good. And though the third re-read is very familiar, I still enjoy it and find it profound.
I'm intrigued that anyone would teach OOP using a language other than Smalltalk. As well as giving you the bits you need to build objects, it puts them together in a dispatch system and class library, fully thought out and tastefully designed, then gives you the tools to take it apart, study how it works, think about why parts of it are clumsy, and consider the consequences of fixing them. Perhaps graphical workstations were too expensive for universities in 1992?
SICP videos are also great. The first part of the Lecture 1A, talks about "computer science". From the first moment, we learn that computer science is also not really much about computers.
"...when some field is just getting started and you don't really understand it very well, it's very easy to confuse the essence of what you're doing with the tools that you use..."
"...Well, similarly, I think in the future people will look back and say, yes, those primitives in the 20th century were fiddling around with these gadgets called computers, but really what they were doing is starting to learn how to formalize intuitions about process, how to do things, starting to develop a way to talk precisely about how-to knowledge..."
SICP is a masterpiece. I took the old MIT 6.001 in Spring 1986 where we burned through the entire book in about 14 sleepless weeks. Sussman was the lecturer and Rod Brooks was my recitation instructor. I was like 19 years old at the time and it was the most intellectually beautiful thing I had ever experienced. I ended up acing the course and went on to get a PhD in CS. I've never read a better book on programming.
I wish that had been my experience with it. I did well in the class, but I didn't learn nearly as much as I should have. To be clear, that was entirely my fault, not the class's; I was lazy and got away with a lot of shortcuts. And even when I learned real stuff, I shrugged it off as "not actually how you build programs in the real world; can't I have for loop?" (so, sooo dumb). After years in the industry and a slow, organic rediscovery of all the great concepts I should have taken to heart as a college freshman, I cracked open SICP and said, "holy shit, this is what I was being taught?" 6.001 really was incredible, had I only been smart enough to see it. Eat your veggies, kids.
I have to confess I just discovered you can order a relatively cheap copy (well, compared to Amazon) of SICP direct from MIT.
I have only skimmed so far, but combined with the lectures I have to say that I really wish that had been my introduction to programming. Maybe it is just because of where I'm at, but it really feels like in the first 3 lectures some of the more elusive topics of programming are at least touched. Sure, you will need to seek out more, but it is not as hidden behind "but for this language, you have to do this" kind of crap.
Years ago, I was very interested in having the physical book to read, but too cheap to buy a new copy. Every once in a while I would check half.com and book shopping comparison sites looking for a cheap used copy. One day in December 2006, there was a rift in The Matrix and Barnes and Noble was selling the hard copy 2nd edition for ... $7.00 (new). I ordered two copies and as soon as they were physically in my hands, I tried to order more. Alas, the glitch had been fixed by then. Sometimes I wonder if there shouldn't be a general price scanning app that will alert on wild changes in the price of a popular book.
When I was student, my school has decided to stop using Ada as teaching language. They were hesitating between CAML Light and Scheme. They asked me my feeling because I was one of the rare student to know well both of them. I like both of them, but I choose CAML Light. Scheme has a lot of parenthesis that makes it look very old fashion. Scheme type system was also outdated. Programming in CAML Light was more fun for me, the syntax was simple and pleasant. The currification was cleaner in CAML Light. 20 years latter, CAML Light does not exist anymore, but I still think that my choice was right. My school has choosen CAML Light.
I went from SML, Caml Light, and OCaml to Common Lisp, and then to Scheme.
I prefer Scheme by far to any other language I've ever used (which includes a whole bunch of languages not listed above).
For me, Scheme is much more fun to program in than OCaml, etc. With OCaml I found myself constantly wrestling with the compiler to get my program to compile, and had problems decyphring its obscure error messages, which seemed to require taking university-level courses on type theory in order to be understandable.
With Scheme, my programs mostly "just work", and I can program the way I think.
Some people have problems with Scheme's parenthesis, but I personally quickly learned to love them because they make scope explicit and obvious. Through long and bitter experience, I've learned to value explicitness and clarity in programs above almost everything else. Scheme is great for that.
True, Scheme might not be as safe as OCaml and friends, but for ease of programming, speed of development, and sheer pleasure, I find it very hard to beat.
The most useful didactic feature I've found in ML-like languages--Haskell for me, but they're all somewhat similar--was pattern matching. Honestly, pattern matching is what really got me to understand recursion. It also makes the language feel much more declarative than using `if` and `cond` statements.
French classes prépa[1] have been using it in the CS course until this year (I have heard it would be dropped in favour of Python next September). So even though there hasn't been any development for the past 10 years[2] it still exists! And then there is OCaml which is still lively.
Even though a CS graduate may say that S-expressions are the simplest syntax possible - not that he's wrong - I'm happy I discovered functional programming through OCaml, whose syntax feels way more natural (to me at least).
"Scheme has a lot of parenthesis that makes it look very old fashion."
Might I argue that this is a huge advantage? No one knows scheme, and it's very obscure, and looks nothing like other programming languages. This means that you can teach concepts using it and pre-judgements about the language don't get in the way.
Then, I suppose the same could be said of CAML and its obscurity.
Can you elaborate? Is your school still using CAML Light, or have they moved on to some other language (O'Caml?)? How effective was it as a teaching language?
I took Brian Harvey's SICP course, what I didn't realize until I read this article is that I was in the first class he taught in 1987.
I remember helping a friend in the course. We stared at five lines of code while I tried to explain it, he had a really hard time with it (some type of recursion I assume). I still hold the lesson from that tutor session. Write code to be easily read by the average joe. Python, Ruby, etc are great because they are easier to read by more people. Languages are about people not machines.
p.s. I am still writing code today, and loving it.
Excellent article. I'm immensely glad and lucky to have had Brian Harvey as a professor, and this echoes exactly what he taught us and the general teaching at Berkeley: that the concepts of programming and computer science were of paramount importance, and that you should understand them in the abstract.
To this day, this is why I value a good theoretical CS education, why I value university education, and why I continue to look back on and use my supposedly theoretical and impractical CS education with great respect.
This is so true: "learning another programming language isn't a big deal; it's a chore for a weekend. I tell my students, 'the language in which you'll spend most of your working life hasn't been invented yet, so we can't teach it to you. Instead we have to give you the skills you need to learn new languages as they appear.'" Can you imagine how valuable it was to be told that from the start?
He's right about scheme too: part of the value of using Scheme or Lisp is its inherent crazy unfamiliarity to the great majority of students. The first thing when you see all those parentheses and weird paradigms is "woah, this is unlike anything I've seen before." And that's perfect. You don't get lost in things you think you already know—you learn concepts fresh and the language, because it's so weird and wild and totally abstract and you can't imagine using it for any real project—is as malleable and temporary as modeling clay. You get to make things with it that teach you about art, and how to look at things, how to see infinity—not about the properties of the materials in your hands.
For this reason among others, it's profoundly disappointing to me that Berkeley has switched their introductory language to Python. As great as it is, it's no Scheme, if only for the fact that its popularity and usefulness as a language detracts from the underlying concepts. I have to think Brian Harvey fought this change, had he not retired and lost some influence.
"Every five years or so, someone on the faculty suggests that our first course should use language X instead; each time, I say "when someone writes the best computer science book in the world using language X, that'll be fine.'"
SICP was, in retrospect, a masterpiece of education. Someone sat down and thought about exactly these concepts and how best to elucidate them without getting in the way of the connections being made. The new trend toward applications-focused education feels to me like the wrong direction, and I don't think I would get as good an education today as I did learning abstract concepts theoretical computer science taught as the most important part.
Sure, it's fun and attractive to think about applying what you learn to the revolution at hand quickly, making mobile apps and designing robots and putting everything together into useful applications, but you can learn all that stuff after a couple semesters of awesome CS core theory anyway. And while you might get frustrated for those 2 years as an 18-year-old hotshot upstart startup-minded student, in 10 years you'll look back on it and think, "wow, that really was the most important part."
Sounds like Berkeley are making a huge mistake and losing sight of what a University is there for. They seem to have moved to a more practical approach than theoretical approach.
This is the type of approach that is more appropriate to a Technical College than a major University. This new approach almost seems like teaching civil engineers how to weld and rivet in order to build bridges, rather than deeply understanding the mathematical theory behind stress and vectors.
"woah, this is unlike anything I've seen before." - it so totally isn't, if you know Ruby and to a lesser extent JS, both popular languages. It's a funky syntax coating on a fairly normal dynamic language, with about three quirks (tail calling, homoiconicity, and call/cc) all of which are more of interest academically than practically.
I didn't discover SICP until after I had graduated from a good CS school. Its clear and away the best programming book I've ever read, even for an experienced developer.
I studied ME and my only computer course was Fortran but over the years 70% of my work has become programming. For me SICP was a great introduction to CS. Up to then I had the typical practitioner's view that computing is all engineering and no science but SICP changed my view.
I was working through the coursera functional programming course on scala which is modeled on SICP. While the content is really good, it suffers from the same problems pointed out by Dr Harvey. Getting used to scala syntax takes time while Scheme was a breeze.
Universities are communities of people from very different sub-disciplines, with every person considering their own sub-discipline or course the most important one, and as a result the curriculum is diluted and hurried to please the greatest amount of people. It might have its benefits, but if training great computer scientists is really the goal, I think it is a bit of a pity you cannot go to a place where you could just do a mix of SICP, algorithms and mathematics for full three years, spending much more time with a single instructor on a single broad topic.
Actually, you can do something really close. The trick is to study mathematics and specialize from there, e.g. in algorithms or mathematical optimization.
But an average student might need the exposure to other "common" paradigms from C, Python, or Java, before getting introduced to SICP, to "fully appreciate" the power of functional language.
Pedagogically speaking, I think this is backwards. SICP isn't a course in functional programming; it's a course in programming. And the use of Scheme is critical, because it doesn't waste time on nonsense like classes and structs and other ephemera -- you just jump right into the conversation with the computer.
Hi everyone, is there a kind of video/guided tutorial through Scheme and SICP? I have tried picking the book up on my own but have had a hard time retaining the information.
I wish my school had used this book. The first year of CS at my school was futzing around with operators and basic data structures. No tie-in to the big picture.
I started an SICP study group at work, where a few of us get together and watch the MIT video lectures given by Abelson and Sussman. People were a little skeptical at first, given that they consider themselves top-of-the-line l33t hackers and this is an introductory course, but after the 3rd lecture, nobody questioned the value of it.
For those turned off by its mathiness, one of the coauthors explained, "There’s a tremendous amount [of math] in this 6.001 book. That’s partly because we were writing it for MIT. You want to talk about higher-order procedures, so the obvious thing you can do is you can express the idea of an integral. So that’s an obstacle for lots of places. Remember, at MIT the context we were writing in is every person who took the course had just had a semester of calculus."
Thanks. The mathiness has been an obstacle for me. It's not that I'm incapable of groking the ideas, just that when I sit down to play with a language I haven't yet mastered I don't also want to be learning tangential concepts. Still, I love it, and keep coming back to it. It's so readable, and scheme changed my brain.
[+] [-] eru|13 years ago|reply
`How to design programmes' (http://www.htdp.org/) leaves a better impression as a beginners' book for me.
If you can already programme then "Programming Languages: Application and Interpretation" (http://cs.brown.edu/courses/cs173/2012/book/) is a great follow-up.
[+] [-] nnq|13 years ago|reply
- the mathematician-programmers: the thinking in terms of "what is" extreme, or mathematical thinking inspired programming: people closer to this like to think in terms of types and usually dislike dynamic languages, they also like to be able to properly reason about all aspects of a program, to have defined "states" they can think about. These people tend to like MLs, Haskell, OCaml, F#. The "mathematical beauty of perfect code" is their ideal and favorite metaphor. And I think they are right that teaching a Lisp to a beginner pushes ones mind away from "what is" oriented programming.
- the Schemers: the thinking in terms of "what transformations to apply to something (it doesn't matter what "something" actually "is") to get something else or somewhere else" programmer: these people like to be able to transform everything, including code itself, they like homoiconicity or macros in general, they prefer thinking in terms of "how to compose/cahin transofrmations" instead of types, they tend either no know or not value category theory too much and they are ok with seeing code as an "organic entity" that can't always be reasoned about. These people tend to like Lisps, Smalltalk and dynamic languages. The "programming as magick", in the sense of "controlling the spirits (processes) inside computers" is their favorite metaphor. They also like to maintain a playful mood and their "it's ok that paying customers get shafted every now and then" may have had a reason for businesses' dislike for "schemer" types and "schemer" realted technologies. As an offside paradox, some "schemers" tend to also like OOP, though they understand it should not be overused (I consider Alan Kay, usually mentiones as the father of OOP to be a "schemer"). I think that exposing a young learner to Lisp pushes one mind towards this direction, and this is why I love SICP. If you are a competent engineer you surely have a serious amount of math knowledge, so you can easily switch your mind to what-is/math mode and see the mathematical beauty when there is one to be seen, but most "mathematician-programmers" never seem to be able to love this "ruleless organic beauty" of the "schemer way".
I consider myself a "schemer" and I am biased to this side, but I understand and appreciate the value and arguments of the other - I'd rather fly in a plane with the control systems coded by a "mathematician-programmer" than by a "schemer" like me :)
[+] [-] spitfire|13 years ago|reply
[+] [-] craigching|13 years ago|reply
That quote describes me to a T.
The University of Minnesota taught a sophomore class on OO using SICP. At the time, C++ was hot (this was about 1991 or 1992) and I distinctly remember someone raising their hand and asking "Why are we learning this language that we will never use again? Why isn't an OO class taught in C++?" And I remember thinking to myself "Who cares what language it's in? I'm kind of excited about learning another language." And I truly was.
It wasn't until much later, after being in industry for a decade (currently starting my third decade now ;) )that I recall thinking to myself "You know, that book had a tremendous impact on how I write software and program in general, I need to pick that up again, what was it?" And I re-found it and am on my third reading of it as I write this, mostly just to refresh the ideas in my mind (since I mostly work in Java and JavaScript these days), but I have never truly finished the whole book. The class took us through chapter 3 and then sort of a mixed bag of topics from later in the book, so I've never truly read the whole book, but certainly enough of it to help me.
I didn't realize it was a famous book at the time, it was just our text book. I still didn't realize it was a famous book when I re-bought it a decade later. And now I know why it is a famous book, it is that good. And though the third re-read is very familiar, I still enjoy it and find it profound.
[+] [-] thisrod|13 years ago|reply
[+] [-] sepeth|13 years ago|reply
"...when some field is just getting started and you don't really understand it very well, it's very easy to confuse the essence of what you're doing with the tools that you use..."
"...Well, similarly, I think in the future people will look back and say, yes, those primitives in the 20th century were fiddling around with these gadgets called computers, but really what they were doing is starting to learn how to formalize intuitions about process, how to do things, starting to develop a way to talk precisely about how-to knowledge..."
[+] [-] chrismaeda|13 years ago|reply
[+] [-] icambron|13 years ago|reply
[+] [-] taeric|13 years ago|reply
I have only skimmed so far, but combined with the lectures I have to say that I really wish that had been my introduction to programming. Maybe it is just because of where I'm at, but it really feels like in the first 3 lectures some of the more elusive topics of programming are at least touched. Sure, you will need to seek out more, but it is not as hidden behind "but for this language, you have to do this" kind of crap.
[+] [-] lesterbuck|13 years ago|reply
[+] [-] edem|13 years ago|reply
[+] [-] tobinfricke|13 years ago|reply
For the mind-blowing effect to occur, you must actually do the exercises. (-:
[+] [-] brudgers|13 years ago|reply
http://mitpress.mit.edu/books/structure-and-interpretation-c...
[+] [-] jluxenberg|13 years ago|reply
http://www.amazon.com/Structure-Interpretation-Computer-Prog...
[+] [-] webreac|13 years ago|reply
[+] [-] gnosis|13 years ago|reply
I prefer Scheme by far to any other language I've ever used (which includes a whole bunch of languages not listed above).
For me, Scheme is much more fun to program in than OCaml, etc. With OCaml I found myself constantly wrestling with the compiler to get my program to compile, and had problems decyphring its obscure error messages, which seemed to require taking university-level courses on type theory in order to be understandable.
With Scheme, my programs mostly "just work", and I can program the way I think.
Some people have problems with Scheme's parenthesis, but I personally quickly learned to love them because they make scope explicit and obvious. Through long and bitter experience, I've learned to value explicitness and clarity in programs above almost everything else. Scheme is great for that.
True, Scheme might not be as safe as OCaml and friends, but for ease of programming, speed of development, and sheer pleasure, I find it very hard to beat.
[+] [-] tikhonj|13 years ago|reply
[+] [-] bru|13 years ago|reply
>CAML Light does not exist anymore
French classes prépa[1] have been using it in the CS course until this year (I have heard it would be dropped in favour of Python next September). So even though there hasn't been any development for the past 10 years[2] it still exists! And then there is OCaml which is still lively.
Even though a CS graduate may say that S-expressions are the simplest syntax possible - not that he's wrong - I'm happy I discovered functional programming through OCaml, whose syntax feels way more natural (to me at least).
1: http://en.wikipedia.org/wiki/Classe_pr%C3%A9paratoire_aux_gr...
2: at least according to http://caml.inria.fr/caml-light/release.fr.html
[+] [-] calinet6|13 years ago|reply
Might I argue that this is a huge advantage? No one knows scheme, and it's very obscure, and looks nothing like other programming languages. This means that you can teach concepts using it and pre-judgements about the language don't get in the way.
Then, I suppose the same could be said of CAML and its obscurity.
[+] [-] seanmcdirmid|13 years ago|reply
These don't seem like very good reasons to choose one over the other; the choice probably came down to culture.
[+] [-] endgame|13 years ago|reply
[+] [-] gcv|13 years ago|reply
[+] [-] zoz|13 years ago|reply
[+] [-] calinet6|13 years ago|reply
To this day, this is why I value a good theoretical CS education, why I value university education, and why I continue to look back on and use my supposedly theoretical and impractical CS education with great respect.
This is so true: "learning another programming language isn't a big deal; it's a chore for a weekend. I tell my students, 'the language in which you'll spend most of your working life hasn't been invented yet, so we can't teach it to you. Instead we have to give you the skills you need to learn new languages as they appear.'" Can you imagine how valuable it was to be told that from the start?
He's right about scheme too: part of the value of using Scheme or Lisp is its inherent crazy unfamiliarity to the great majority of students. The first thing when you see all those parentheses and weird paradigms is "woah, this is unlike anything I've seen before." And that's perfect. You don't get lost in things you think you already know—you learn concepts fresh and the language, because it's so weird and wild and totally abstract and you can't imagine using it for any real project—is as malleable and temporary as modeling clay. You get to make things with it that teach you about art, and how to look at things, how to see infinity—not about the properties of the materials in your hands.
For this reason among others, it's profoundly disappointing to me that Berkeley has switched their introductory language to Python. As great as it is, it's no Scheme, if only for the fact that its popularity and usefulness as a language detracts from the underlying concepts. I have to think Brian Harvey fought this change, had he not retired and lost some influence.
"Every five years or so, someone on the faculty suggests that our first course should use language X instead; each time, I say "when someone writes the best computer science book in the world using language X, that'll be fine.'"
SICP was, in retrospect, a masterpiece of education. Someone sat down and thought about exactly these concepts and how best to elucidate them without getting in the way of the connections being made. The new trend toward applications-focused education feels to me like the wrong direction, and I don't think I would get as good an education today as I did learning abstract concepts theoretical computer science taught as the most important part.
Sure, it's fun and attractive to think about applying what you learn to the revolution at hand quickly, making mobile apps and designing robots and putting everything together into useful applications, but you can learn all that stuff after a couple semesters of awesome CS core theory anyway. And while you might get frustrated for those 2 years as an 18-year-old hotshot upstart startup-minded student, in 10 years you'll look back on it and think, "wow, that really was the most important part."
[+] [-] SeanDav|13 years ago|reply
This is the type of approach that is more appropriate to a Technical College than a major University. This new approach almost seems like teaching civil engineers how to weld and rivet in order to build bridges, rather than deeply understanding the mathematical theory behind stress and vectors.
[+] [-] JulianMorrison|13 years ago|reply
[+] [-] mzs|13 years ago|reply
http://www.cs.uchicago.edu/courses/description/CMSC/10500/99...
[+] [-] yanatan16|13 years ago|reply
[+] [-] mrspeaker|13 years ago|reply
[+] [-] minikomi|13 years ago|reply
[+] [-] zwieback|13 years ago|reply
[+] [-] denzil_correa|13 years ago|reply
[+] [-] ramkalari|13 years ago|reply
[+] [-] zenbowman|13 years ago|reply
I like the language, but I'm simultaneously disgusted by it.
[+] [-] stiff|13 years ago|reply
[+] [-] eru|13 years ago|reply
[+] [-] protez|13 years ago|reply
[+] [-] jfb|13 years ago|reply
[+] [-] tsurantino|13 years ago|reply
[+] [-] drivers99|13 years ago|reply
[+] [-] arcs|13 years ago|reply
The ones prior to 2010~2011 used scheme, and it tracks SICP fairly closely.
http://webcast.berkeley.edu/playlist#c,s,Fall_2010,EC6D76F0C...
[+] [-] qu4z-2|13 years ago|reply
Take it slowly, don't be discouraged if it takes you hours to get something concept, and DO THE EXERCISES.
[+] [-] Spooky23|13 years ago|reply
[+] [-] zenbowman|13 years ago|reply
It's a timeless course.
[+] [-] kristianp|13 years ago|reply
https://news.ycombinator.com/item?id=4784827
[+] [-] calibraxis|13 years ago|reply
http://www.codequarterly.com/2011/hal-abelson/
[+] [-] cturner|13 years ago|reply
[+] [-] jallmann|13 years ago|reply