It's kind of funny how at my university (one of the better public unis in the world, or so they say), there is no rigorous introduction to computer science. Sure, we have our architecture, and our data structures, OS, and algorithms, and even a "here's how to Java" introductory course. Yet there is no "This is the way to think like a computer scientist and how to understand as a computer scientist would" class.
The result? You can clearly tell there are a lot of people in the cs program who just sort of go by and learn all these periphery (but still important!) topics without ever touching the core principles. I've even seen seniors who are just clueless! I guess the idea is they're meant to figure it out for themselves through a eureka moment? That doesn't seem like a sound structure to me. I'm realizing that I, myself, fall into the lacking-understanding camp and I'm doing my damn best to rectify that. When I get my degree I want to be able to say I'm a computer scientist, and I want those words mean something. I'm hoping that SICP will truly help me understand the core principles.
I feel a lot of it has to do with the amount of money you can make straight out of college even as a mediocre coder, compared to the low-paying, unrewarding mess that education currently is.
Good on you for trying to do things right :) I was lucky to take the non-self paced version of CS61A, and I do think the class is top-notch. But even then there's tons of room for improvement, but no one has the time. We're all too occupied with our start-ups here (professor was amazing, but it says a lot that he was a full-time employee of Google while he taught our class).
Physics is really two different fields: There's Physics for people who want to a rigorous understanding of the underlying theory, and possibly also want to become research scientists or academics within the field. And there's engineering and all its subfields for people who are primarily interested in applying that knowledge to make stuff.
There's the potential for CS to be broken up along similar lines, but it hasn't happened. I'd argue that this does students a great disservice, since it's hard for someone getting in at the ground level to tell what a program's real focus is just by reading the course catalog.
I took the SICP route and I'm very glad I did. But plenty of my classmates hated it, and I don't see a problem with that. It's terribly dry stuff, and there are plenty of people who've got only a high level grasp of the theory and still make amazing software and make it well
Different strokes for different folks.
I could be wrong, but as a casual observer who isn't yet in the workforce it seems to me that the people who put up with the rigor of the more difficult and less sexy topics (e.g. a solid understanding in algorithms à la CLRS) are not only just as well compensated as those who prefer to focus on what they think are marketable skills that industry is looking for, but they grow faster and further. These sorts of people (again, in my casual observer's eye) don't get pigeon-holed into a technology stack, but can easily jump into new topics if they think they're sufficiently interesting.
It's at least true for my friends in compsci who I have the most respect for as programmers. They seem like they can do anything!
As an EE working with computers (albeit at a lower level), I'd think the topics concerned with implementation of computers (computer architecture, operating systems, algorithms etc) hold more 'fundamental' status in my book. I guess it depends on where you belong in the stack.
Having said that, I definitely feel that I could benefit from the knowledge of more abstract issues that SICP addresses.
The detailing given in some of the answers meant I had to go back and strengthen some of the basics and learn things in depth rather than peripheral information.
One example of this is when a classmate of mine was taking an artificial intelligence class at Berkeley (Cog Sci 131) and was at a loss because she was taking 61as which was taught in strictly scheme, and the artificial intelligence class was taught in strictly python.
Both classes are wonderful and I can proudly say that it has made me a better computer scientist. http://cs61a.org/
Nowadays, though, I feel like my time spent getting used to functional programming in school has given me a secret weapon. It's something much more subtle than the ability to bandy about obscure words that probably start with M. I really do think I'm just fundamentally better at dealing with abstraction, both using it and creating it, than my peers who haven't had such an experience. And that's not small beans considering that, to an approximation, working with abstractions is what I do all day every day.
I can say without a doubt that having functional programming knowledge first would have been a phenomenal advantage.
I do think that another major advantage for Python is the fact that you can do cooler things with it, faster. CS has a serious funnel problem and the quicker we can get students to do cool things with CS (GUI stuff, web stuff), the better CS education will be.
The issue is these skills don't solve serious or interesting problems. GUI and web programming have become easier than ever and requires less programmers on staff to perform. My company can't find enough qualified engineers with a good depth of knowledge in CS.
I've found functional concepts have been incredibly important in shipping maintainable code on the JVM using both Java 8 and Scala.
Unless one plans on developing mostly in python during his or her career, I think its beneficial to be forced to learn multiple languages.
It's not what you learned that's the problem, it's what you didn't. You almost certainly missed out on things that you could very well never see again, or even know the existence of (at least for a very long time) unless you were motivated enough to go discovering stuff by yourself.
Did you ever learn about macros in Python? I doubt it, because they don't exist. Did you get introduced to metaprogramming -- the idea that you can write programs that generate more powerful programs? I doubt it, because it's hard to do that in Python. But The old 61A, which used Scheme, did just that. They added an OOP system --- yes, that's classes, inheritance, methods, constructors, etc. --- to a language that never had one, and they even taught you the basics of how it was done. 
This is something you can't even dream of doing in most (all?) languages that aren't dialects of LISP. You won't even realize it's a possibility, unless someone teaches it to you or unless you're lucky enough to stumble across it and realize its importance.
i.e., you won't know what you're missing out on.
Whereas with Python, there's not much you're missing out on: there are a ton of languages like it that you're bound to see them later in industry, if not Python itself, and learn what you would have learned anyway.
In any class of reasonable difficulty/usefulness, there will be students who do great, ones that do okay, and ones that struggle. What we should aim to do as the very first intro course is to help as many of those people from all of those groups to do as well as possible in their future classes/careers.
For the great students, I actually believe we did them a disservice. CS61A in scheme was truly beautiful. It was amazing, given how simple the language was, how much you could achieve. All pieces of the puzzle fit together perfectly. Trying to do the course in python, on the other hand, we had to compromise a little bit. We didn't want to just teach the exact same content in a different language. We wanted to teach the "Pythononic" way of doing things. To give a few examples:
- The first 1/3 of CS61A in scheme had no mutation. That is almost impossible in Python to do, and is not the way the language is used in industry. I personally believe functional programming and immutability is The-Way to program, so I see this as a huge loss.
- We teach recursive lists (linked lists) in order to teach recursion, but I feel like having both the default Python mutable lists (which are array lists) and linked lists is confusing to students, since we do not teach their performance tradeoffs (that is in 61B).
- Mutual recursion was almost useless to teach. Where it was most commonly used in Scheme, you achieve the similar thing using list comprehensions in Python (the language feature essentially took away your need to construct the list in a recursive fashion).
- The very interesting bits of the old class about metacircular evaluators, we simply could not do in Python.
- Python also has tons of quirks (magic methods, for instance) and lost some of the elegance we saw in scheme.
But for the okay and struggling students - 70-80 percentile and below, the students who understand most of the material, but perhaps fail to grasp some of the more complex concepts - I think Python was the correct way to go for a few reasons:
- It is a much more commonly used language. It sets you up to go for internships, research, hackathons, whatever you please, straight from what you learned in class.
- The language is way more similar to Java, which allows students to translate what they learned easier to the next course in the series, CS61B.
- 80% of the material hasn't changed but you've gained the above benefits. Remember, we are talking about students who probably would have struggled to grasp those last 20% anyway (maybe they are completely new to programming and they already have their hands full with the 80% to begin with).
I think therein lies the difference in opinion. If you took CS61A in scheme and understood it very well, then you don't understand the change. If you understood the intricacies of what was taught in CS61A, you will find it very easy to generalize those concepts to new languages - and new concepts. In fact, you will find that much of what you learn in the rest of your undergrad career will be "CS61A review". However, for students who may not have had the CS maturity or time to grasp all the concepts, they find that the Python course is much more useful.
One thing I've seen is that when you're first learning a langauge and pick up bad habits, they can be really hard to break. I've heard lots of students talk about the problem this causes when interviewing, especially early on. Additionally, for languages like Python, where there is loads of (often excellent) support online it can be confusing/frustrating to have a class teach one method and find answers which are mostly unrelated.
That said, I agree with what was said. Scheme is pretty amazing :)
What is stopping you from implementing those ideas in Python during a first-semester course in CS is that you will not serve your students, as amatsukawa described.
Pretty unambiguous to me. GP had a very thoughtful reply to be clear.
If the desire was to teach idiomatic python, that's totally legitimate. But the decision to whether or not teach FP concepts is in no way constrained by the choice of language.
So what I'm doing is using DrRacket with this module: http://www.neilvandyke.org/racket-sicp/ This adds and makes the environment SICP friendly, and so far I didn't have any single problem (I'm at Chapter 1, page 67).
From Berkeley, the SICP lectures from Brian Harvey are highly recommended. You can watch them from: https://www.youtube.com/view_play_list?p=EC3E89002AA9B9879E And of course the lectures from MIT itself are good too: http://ocw.mit.edu/courses/electrical-engineering-and-comput... I'm going to watch those once I've finished Chapter 1 myself, to re-read and go over the chapter again.
Because it would be good to observe what I've done and track my progress I've setup a Git repo with my thoughts, notes and solutions about SICP and Scheme: https://github.com/fatih/sicp
This is the first time I'm exposed to Scheme/LISP and it's just wonderful. I really like the examples (though they to much based on mathematical proofs and functions).
I am currently two weeks into the CS 61A Summer Course here in Berkeley and I can confidently say that it is the best class I have taken in my academic career. A few reasons:
1. It follows the mentality of guided discovery. Topics are covered in class, and just enough is taught such that the basis of a solution can be formed, but the implementation requires each person to discover something new.
2. The breadth of topics. The course is 50% students who have never programmed before, I have been programming for 4 years, but still I am learning new things about optimizations, tail recursion, and Big-O notation. If you look at the calendar at http://cs61.org, it goes from "these are variables" to "AI" in 8 weeks.
3. Resources. CS 61A Staff during the summer course if legendary already. They're extremely knowledgeable and very welcoming to everyone. The main lecturers, Albert and Robert, both cover the material well and make themselves available to students of any programming knowledge. There are also dozens and dozens of TAs and Lab assistants which are actually useful, unlike some other courses.
4. Intrigue. I have never wanted to bunker down and learn everything there is to know about recursion, interpreters, and algorithms more than I have in the last two weeks. The way the course is structured, as mentioned above, actually inspires learning in a way that some other topics don't achieve because they follow archaic teaching methods.
Here's to an awesome 61A course.
MIT ran(/runs?) a one-month short course covering material from 6.001, and they used PLT Scheme when I took it (now Racket). I seem to remember needing to go into one of the rnrs language modes to get things like mutable cons cells. (How impure.) From what I understand, MIT Scheme is much more in the Maclisp tradition, vs. Racket being more from programming language theory (though both are firmly rooted in the Scheme standard), which reflects in their extensions to the core language.
Nowadays, there is no equivalent to 6.001 at MIT, except maybe 6.945 can substitute. They have a survey course sequence 6.01/6.02 which covers EECS in general, using Python when programming is needed. As a challenge exercise you can make an interpreter for a language, though that's not very metacircular.
Not to make the language seem daunting, it's really quite easy to pick up, maybe if you find yourself with a few spare weekends you should give it a try!
It comes with a builtin IDE and profiler and everything else, so you just gotta dig in and learn.