Thank you for sharing! I've been looking for a well structured course to help me navigate through SICP.
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.
My impression is that computer science education is light-years behind things like physics and math.
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).
I don't know if it's that, or if it's just that it's muddled.
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
That's a good point. I like the fundamentals and really digging in, and for my friends who don't I ask why learn less about the fundamentals of what you're doing!? Those same friends seriously questioned their life choices during the theory/core classes. They later found their calling when they had a chance to explore things like web dev or mobile dev and they're happy now.
I like Richard Gabriel's proposal for a Master of Fine Arts in Software Development degree program. It focuses more on the craft aspects of building software since we still don't know how to do true software engineering in the general case.
You can definitely tell that a number of people are in it without necessarily being dedicated to cs. A bunch of people want our cs program to basically be a vocational school, and in some ways it kind of already is. We learn a trade that we can practice even while students, and people pay us students good money at internships! That's a pretty special opportunity. But the amount of disdain the average student here has for a topic like operating systems is kind of surprising to me.
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!
>> 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.
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.
A bit off-topic here but I think learning peripheral information has become a norm. Last year I was trying to learn Data Science and completed the "specialization" from Coursera. But then there were sometimes when I was unclear on certain topics being discussed by blogs I followed. So I tried googling to see how to really learn in-depth about Data science. I landed on this page:
http://www.quora.com/How-can-I-become-a-data-scientist
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.
Hi all. Glad you find our site useful. Just wanted to add some context that we just spun up this website this summer, and are currently porting all of our lessons to the Racket programming language. Since we're developing course material to work well with Racket, some lessons might be broken/have typos. This means that this summer, the website is mainly for supporting the students taking the live course. Thanks for understanding. :)
-- CS61AS Staff
As much as I love racket/scheme/lisp, I truly believe that the 61A (sans-s) where python is taught, helped me much more for my career/future just because it was taught in python. For programming fundamentals, either works great, but I think working with python is more helpful for future environments.
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/
I don't understand this mindset. You only have 4 years to learn whatever they teach in college, compared with 40+ years if you go into industry. To me, the value of my CS degree was the exposure to a breadth of important ideas across the entire field of computing—thing that I would never have the luxury of exploring while under a deadline. None of the particular tools and workflows I used in college were of any meaningful value after 6 months in industry where the workflows are invariably more sophisticated to cope with the messy nature of long-lived real-world projects.
My CS program was taught in Scheme (the version that's now Racket), and I think I kind of understand it. Shortly after graduation I felt like I had this gap in my resume due to spending all this time learning a language that nobody uses in industry instead of something marketable like Java.
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've done the exact opposite having learned industry standard languages my entire career and only after many years finally gaining a much deeper understanding of computer science (and especially functional programming).
I can say without a doubt that having functional programming knowledge first would have been a phenomenal advantage.
I think the grass is always greener on the other side. I started with SICP in Scheme (Racket) in high school (our teacher had taught at Berkeley over the summer, I think). I don't feel any special reverence for Scheme, and don't particularly feel either way about functional programming. It's just another tool in the toolbox and I don't feel like my smart peers who started with Python are at any disadvantage whatsoever.
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.
> 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.
We're discussing what freshmen in CS should be learning, not what sophomores/juniors/seniors should be learning. Getting people hooked on cool, albeit superficial, things they can build is the right way to get a broader range of people interested in CS (as opposed to just people who started programming before coming to college).
I too took CS61AS in scheme and AI in python, but my experience was different than that of your friend. I didn't find it difficult to pick up python, and learning it after scheme made me appreciate python all the more.
Unless one plans on developing mostly in python during his or her career, I think its beneficial to be forced to learn multiple languages.
> As much as I love racket/scheme/lisp, I truly believe that the 61A (sans-s) where python is taught, helped me much more for my career/future just because it was taught in python.
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. [1]
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.
2 cents from someone who took CS61A in scheme and had a hand in creating the new python version of the course and subsequently was a TA for the class for a few semesters on this debate:
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.
How is it that python is less amenable to functional programing? (Functional in the sense of referential transparency and immutable data-structures, rather than map-filter-fold). Through my limited exposure to python, I agree that immutability isn't idiomatic python, but I don't think there's anything stopping you from implementing those ideas in any language.
(A Berkeley student who went to Aki's sections -- Hi!)
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 :)
The question you should have asked is "how is it that [idiomatic] python is less amenable to functional programming?", which you basically answer yourself. Otherwise, I can't see how amatsukawa implied Python itself was less amenable.
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.
"The first 1/3 of CS61A in scheme had no mutation. That is almost impossible in Python to do..."
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.
I took 61A in python and loved it too. I do a lot of personal projects in django/flask now too, something I probably wouldn't really have thought of before.
These are great notes. Just bookmarked. I'm a self taught programmer (but have EE degree) and have just started to read SICP. I'm actually a Vim guy, but because it was awkward to use Vim, I've decided to use DrRacket. Why not MIT/Scheme? Because every single review would suggest me to use DrRacket, as it's more intuitive to use and it's still developed.
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).
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'm a community college student in California looking to transfer to Berkeley.
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.
It looks like 61AS still uses the old glookup system that's restricted to enrolled students, but you could go through the regular 61A course (which is taught mostly in Python but covers most of the same material as 61AS) which started using the new OK autograder for all assignments last semester (http://inst.eecs.berkeley.edu/~cs61a/sp15/). The tests are all run locally, so just add the --local flag to the command you run to prevent it from sending data to the server (which requires a Berkeley login).
We're looking into releasing a standalone version of the autograders (in response to this comment, actually). No promises yet. I'll reply here if there are interesting developments.
I doubt it, but you can probably just google for sicp answers, there's a lot of github repo's out there :) The scheme programs referred to in some of the notes look like they are available here if you want to try running them yourself:
http://wla.berkeley.edu/~cs61a/sp09/lectures/
The autograder instructions on homeworks 0-5 have been updated to include running tests locally. Note that this is an experimental feature. If you run into bugs, you can hit up Rohin and Andrew (find their emails on the staff webpage)
It's great to see Racket being used for this course, as I'm sure many students will go on to explore the language more deeply and see that it has a lot to offer.
As another commenter mentions, MIT used MIT/GNU Scheme [1] for the introduction to CS class 6.001, so if you're following SICP, this is probably the least-friction distribution of Scheme to be using (hints: use rlwrap, or use scheme-mode in emacs, or figure out how to use its built-in scheme-based emacs clone "edwin").
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.
Racket gives us a superset of Scheme that gives us more expressive power. Modularity (good programming practices), built-in loops (for mucking with vectors), structs (for data abstraction), built-in OOP, and extensive libraries are all things we'd like to take advantage of in the future in our lessons.
The original SICP used MIT/Scheme, a fantastic language. Racket is a continuation of the ideas of MIT/Scheme with more focus on technical computing and a heavy focus on langdev and PLT theory.
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.
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.