I am one of Brian Harvey's student progeny. I still consider the SICP as my favorite computer science book, and in retrospect CS61A one of my favorite and most important courses. There is something amazing about a course that takes one from "square can be defined as (define (square x) (* x x))" to writing an interpreter, and be something a mere mortal can work through in a few months. And that's just chapter one to four out of six in SICP, if memory serves.
I like Python, and use it in industry. Ruby, Go, and C also. In the past, I wrote Common Lisp professionally as well. I do not pine for Scheme or CL, although both had some of their own unique charm. Nevertheless, I think Brian's sentiments about Scheme's clarity in stripping away what can seem to be the 'magic' in programming while maintaining an absolutely rigorous representation that can actually be executed are spot-on. There will be plenty of time in practical work to reintroduce some magic to make practical tasks easier, but there is but a precious few years -- or indeed, just a semester -- to examine the structure of abstraction at its very core.
I love the story where the creators defined a Lisp interpreter in Lisp, and then one said, "you know, we don't have a Lisp compiler, but I could compile this source by hand." It's quite an elegant concept when you accidentally create a fully-functional interpreter overnight.
> Steve Russell said, look, why don't I program this eval..., and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bug, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today...
a shorter version from "History of Lisp" page 9:
> S.R. Russell noticed that eval could serve as an interpreter for LISP, promptly hand coded it, and we now had a programming language with an interpreter.
> What MIT decided was to move from a curriculum organized around topics (programming paradigms, then circuits, then signal processing, then architecture) to a curriculum organized around applications (let's build and program a robot; let's build and program a cell phone).
While this is offered as an excuse for switching away from SICP, I don't like this either.
Programming paradigms are the perfect introduction to programming. First, it naturally teaches you one of the most fundamental concepts in computer science (abstraction) by example; with the SICP approach, you learn about abstractions by constructing your own idioms for abstractions within a programming paradigm!
Second, applications become easier and easier to develop the more one learns to break out of a single paradigm and borrow ideas and tools from each as needed - otherwise, it's easy to get stuck in a rut and miss a simple but elegant solution to the problem at hand. Being able to cross-pollinate features or ideas idiomatic in one language to another gives you a Leatherman instead of an x-acto knife.
Having a fundamental grasp of programming paradigms makes programming languages feel like a second skin, rather than an obstacle sitting between the brain and the binary output.
"Perhaps in time the applications-first approach will spark a revolution as profound as the one that followed SICP, but it hasn't happened yet."
Put the way he's written described it, "a curriculum organized around applications", I don't think it will. You have it right: too many trees, not enough forest.
Does anyone who has taken the new MIT curriculum have any comments?
Sorry, but what "profound revolution" followed SICP?
It was a mighty fine course and text-book. But where's the revolution?
Where are the guys that were taught SICP that went on to do "revolutionary" things?
And if they do exist, how do they compare to a control group that just learned with UNIX/C/C++ and the like?
(Downvotes? I thought we're taking compute SCIENCE here. Where's the science and the proof? If one didn't know any better he would have thought I was stoned for insulting some holy scripture...)
> Downvotes? I thought we're taking compute SCIENCE here.
From SICP:
'Underlying our approach to this subject is our conviction that "computer science" is not a science and that its significance has little to do with computers.'
(Don't know about the downvotes or anything. Just thought that was like vaguely funny.)
"In my experience, relatively few students appreciate how much they're learning in my course while they're in it."
How true! I hated CS61A when I was in it, and I thought nothing was practical and everything was a trivial example. Sorry Brian! I failed to grasp the depth of all the 'trivial' examples. I never appreciated the complexities of the class until I started being a TA for it, and I never truly loved the class until I lectured it.
Awesome point about just how language agnostic the course was: the key idea that every programming language has 3 components (primitives, one or more means of combination and one or more means of abstraction) and once you figure those out you can do the same things in just about any other language is really not highlighted enough. Still haven't seen any other programming courses that point that out: getting bogged down in syntax trivia seems to be the pattern of the day.
"Courses that teach those languages spend at least half their time just on learning the notation."
Spot on. This describes exactly my experience of my Pascal-based course back in 1986 - and it was way more than half. I didn't come across SICP until 10 years later, and it was a revelation, I didn't realise how much more productive an introductory course could be.
I was turned onto the SICP lectures[1] though people talking about them on HN, and I was just floored by them. They still give me goosebumps when I watch them. It's like watching a video of someone completely in their element and at the top of their game, like the lecture equivalent of the 2007 Wimbledon Finals or something.
And of course, the book is awesome too. And it rewards repeat readings.
I don't personally feel strongly about this, but why bother taking a plain text article written by someone else and re-publishing it in plain text somewhere else? It doesn't add any value, and just adds noise to the discussion here. Also, the original author may not appreciate your republishing their work.
SICP has wonderful materials to touch on so many important and elegant concepts in CS that it should be taught to any serious CS students. It's not about the language Scheme itself but all the underlying CS ideas. You might be able to learn those concepts here and there from time to time. SICP ties them in one comprehensive course.
My experience with SICP is a case of after the fact. I've learned and wrote LISP codes long before touching SICP. The learning process was reading existing source codes and going through reference materials. It's not until I went through SICP that suddenly all these concepts and ideas became so clear.
Brian Harvey was a wonderful, wonderful teacher. Most of what I have learned in CS since has been more-or-less an addendum to his version of CS61A. The world just doesn't make hackers (and teachers) like that enough.
I can't help feeling that this attempt to render a previously excellent course more commercially viable by making it more superficially appealing for students is directly linked to this story: http://news.ycombinator.com/item?id=4785246
If everything is always forced to justify itself commercially, then everything will implode into a hideous, hollow caricature of itself. Everything becomes a flashy excercise in deceit and con artistry if it wants to survive. Quality and substance can never hope to win against marketing.
My high-school CS teacher structured his course around SICP--he worked with Brian Harvey to build the curriculum--and looking back I can definitely see the power of this approach.
I agree whole-heartedly with what he's said in this piece and hope that others can continue to reap the value of SICP. It's made me a clearer thinker and better programmer.
One might say that SICP is unique in as much as it transcends coding as an act of "slinging code at a screen", pushing readers to think carefully about the nature and design of their programs. That's only a sliver of what it does, but it's ever so easy to miss that as a beginning programmer.
Yeah, it definitely takes discipline to get through, but it's quite rewarding.
"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."
While on the coursera online scala irc chan we discussed other material, SICP came with sentences like 'rumors made me read it'. This book lives by itself.
As someone who hasn't been able to get enough motivation to read past the first few pages of SICP, I _really_ wish someone made a TryRuby.org like thing using SICP.
Because I'm skeptical of the use of transforming SICP into a "tutorial" style. It's the kind of book that you need to read and think about.
Having said that, finding a REPL that's compatible with it can take a little bit of time. Personally I quite like GambitC which I seem to recall is fairly compatible.
The best cs book by a mile. One can't help but fall in love with programming after reading SICP. I'm now reading Peter Norvig's Paradigms of AI Programming. It's another classic.
I've also listened to video lectures of Brian Harvey. I think his own twists to SICP such as starting the course with functions on words instead of numbers are invaluable too.
I just finished watching MIT 6.00SC for the hell of it. It was really sad experience.
Of course, prof. Guttag is really a big-shot and seems like no one could say anything, but I cannot even properly describe how much worse it was than CS61A by Brian Harvey.
It is not just Python, it is ugly Python, boring Python, without any hint of elegance it could be. No list-set-dict comprehensions, which is what makes Python interesting, very few slicing examples and one or two use of yield.
I must say that usage of classes was reasonable - only when there were even a small advantage to structure the code this way, but it is just boring stuff.
Each lecture of CS61 keeps you alert and awake, and curious, time passes unnoticed, and you almost feel how a new connections growing in your brain,) while in 6.00CS you're forcing yourself to to stay alert, almost yawning.
So, if one is engaged in self-education just do CS61A and old 6.001 classic videos. After you can skim trough all those mainstream Python-based courses very quickly with great ease. I can do 4-5 lectures per day.)
6.01 (6.001) is where SICP was previously taught, not 6.00. 6.00 is an introductory course to be taken for those with no/limited programming exposure before 6.01.
On a tangent, it's not only list-set-dict comps what makes Python interesting. The very simple and powerful approach to metaprogramming is very interesting as well (all the magic __whatever__ methods, for example)
Scheme is also known for its simple and powerful meta-programming system: macros.
Macros might be hard to fully understand at first, but the core idea is really simple. They're also extremely powerful: they let you change the actual syntax of a program and give you extremely fine-grained control over virtually everything.
We need to start discussing about OO in general. We have a generation (or two,three in internet time) that think that OO is the epitomy of software engineering. We have Haskell, Ocaml, and others that can do better
Why haven't they? Success in practice is hard to argue with. Theory can always sit in the corner, winning every debate by staying above the fray of the dirty real world, and never get much of anything done.
Please don't attempt to rebut with Real World Haskell, unless you have read the book and gone on to build a widely deployed application.
am i wrong in thinking in the Common Lisp thinking that data and methods don't belong together? In production environments we at least have extensions methods in c#, but man i still love generic functions in CL style. Why am i wrong?
I like Python, and use it in industry. Ruby, Go, and C also. In the past, I wrote Common Lisp professionally as well. I do not pine for Scheme or CL, although both had some of their own unique charm. Nevertheless, I think Brian's sentiments about Scheme's clarity in stripping away what can seem to be the 'magic' in programming while maintaining an absolutely rigorous representation that can actually be executed are spot-on. There will be plenty of time in practical work to reintroduce some magic to make practical tasks easier, but there is but a precious few years -- or indeed, just a semester -- to examine the structure of abstraction at its very core.