
SICP in Python - ahmicro
http://www-inst.eecs.berkeley.edu/~cs61a/fa11/61a-python/content/www/index.html
======
angrycoder
This is like reading a modernized version of Shakespeare. You can still kind
of tell the story is good, but it just feels lacking. It doesn't convey the
same kind of weird magic, even though you aren't 100% sure what they are on
about.

It is a perfect example of Rich Hickey's "Simple made easy" talk from a few
days ago.

------
baddox
The very notion seems strange to me, because when I read SICP it was primarily
a "learn LISP's model of computation" book, not a "learn how to program, and
we just happen to be using a LISP" book. Because of that, it doesn't make much
sense to me to port SICP to a non-LISP language.

~~~
joshAg
The way it was explained when I took the class was that the language is
irrelevant for such an intro class and he (harvey, the guy who taught in
scheme) just used scheme because SICP is so good.

We actually went through tons of different programming paradigms that scheme
and lisp probably weren't really designed for, like OO (closures upon
closures, all the way down). Throughout the class harvey and the TA's
emphasized that everything we were learning could be done in any language, and
didn't actually require scheme or lisp (yes, we never got to macros).

I can understand why you it might seem strange to port SICP over to scheme if
you read SICP with the intention of learning lisp, but at berkeley the point
of using SICP was to iterate through many different programming paradigms and
cover basic computer science. unless they've found a better manual for this,
it makes a lot of sense to just translate SICP instead of starting from
scratch.

~~~
tikhonj
I don't know, I found the way they did OO actually made more sense than what I
was taught earlier in a class using Java. It also seems more logical and
elegant than Python's OO implementation, even if Python's isn't quite as
arbitrary and complicated as Java's.

I think the language was only irrelevant because Scheme is so simple. We
covered it in a couple of lectures and then it stayed in the background.

I really don't see the case for switching to Python at all--why "fix"
something that isn't broken? Everybody seems to just assume that Python is a
better choice.

~~~
joshAg
None of the professors want to teach in scheme anymore, and a vocal subset of
the eecs students think scheme is a waste of time because it has no real world
applications.

That said, I think scheme is one of, if not, the best language to begin
programming in, and agree with you that none of the reasons given for
switching were very compelling.

Those scheme handles OO paradigms, the way it does is kind of annoying below
the abstraction. however, scheme wasn't designed to handle OO, it was designed
for functional programming. if i remember correctly, mutability is a hacked on
addition (one of the reasons you use set! instead of def).

~~~
Xurinos
Every time I hear from someone that scheme has no real world applications, I
like to pass them this link: [http://philosecurity.org/2009/01/12/interview-
with-an-adware...](http://philosecurity.org/2009/01/12/interview-with-an-
adware-author)

~~~
joshAg
if i remember correctly, some airfare calculators were/are written in
scheme/common lisp for the macros as well.

------
spacemanaki
This is ok, for a CS 101 class. I'm sure the students will turn out just fine.
Some of them will likely be intrigued by the purple book their class name
references. Looking at the schedule, it looks like it just covers the
"Structure" and not the "Interpretation". My favorite parts of SICP are the
4th and 5th chapters, on metacircular evaluation, interpreters, lazy Scheme,
Prolog, and compilation to byte code. I guess it's probably too much for CS
101 though. It would also be a lot more work to do those chapters in Python,
since you'd need to cover scanning and parsing, instead of just using (read).

~~~
tikhonj
I think that the metacircular evaluator and friends are perfect for a CS 101
class--they really changed my perception of how software works. After all,
this is a CS class rather than just a programming class, and SICP is a good
overview of both while this new class is probably less so.

~~~
spacemanaki
Oh, I definitely agree. SICP was the beginning of the rabbit hole for me. But
I had spent a lot of time programming before I started it, so I'm not sure if
it really is the best text for CS 101, where some students maybe have never
written a line of code. Peter Norvig's review sort of sums up this regarding
SICP: <http://www.amazon.com/review/R403HR4VL71K8>

I've never been involved in teaching CS or programming, and while I really do
think SICP should be required reading for all CS students (and for all
programmers) just because it's so good, I respect that teaching is very
challenging, and fitting it all into a single semester might be tough. There
are some very smart and experienced people who have spent a lot of time
thinking about this (see "The Structure and Interpretation of the Computer
Science Curriculum"), and I hesitate to put SICP on a pedestal where it can't
be touched.

As I said, hopefully some (or many!) of the students taking this class at
Berkley will be curious about the original book and will seek it out on their
own.

~~~
tikhonj
One thing to note is that this class is really more like CS101.5--if you have
never programmed, you're _highly_ encouraged to take a very introductory class
for a semester before this one. Apparently about 90% (or something) of the
people taking it have had at least some programming experience.

I also don't think SICP is _perfect_ ; however, I think it inherently much
better than anything--even itself--done in Python simply because Python
basically forces less breadth. I recently read an interesting paper[1] that I
think could lead to an even better class; if you're interested in this sort of
thing, it's worth checking out.

[1]: <http://www.sics.se/~seif/Publications/fdp.pdf>

It's also not really designed for a completely introductory class, but I hope
that most of the people coming into Berkeley CS aren't _completely_
unprepared.

On a slightly unrelated note, a completely different approach to an intro
class could be cool too: instead of focusing on learning, maybe the first
semester should be dedicated to just building something cool on a computer and
letting the learning happen naturally. The more formal classes can always come
later. For something like that, I could see using Python--although it wouldn't
be my first choice by far--but that's a completely different story.

------
azernik
I took CS61A in the spring of 2008, when it was still done using Scheme.
Looking through the first few lectures and the titles of later lectures, I'm
struck by how much the material is the same. Most notably, in the first
several lectures, they've made a point of stripping down Python to a subset
that makes its evaluation near-identical to Lisp - by using only named
functions (no '1+2', only 'add(1, 2)'), they've kept the emphasis in those
lectures on the environment model of evaluation.

Looking through the later lecture titles, it's quite clear that (despite what
other commenters are saying) the "deeper" parts of the course have been
preserved.

There's a bit that's been lost in translation; in particular, while the
emphasis on metalinguistic abstraction has been kept (students are going to be
implementing an object-class system, in a rather elegant way that uses
Python's capability to redefine attribute getters) the more exotic models of
computation pursued in the old 61A have been abandoned. No more ambiguous
evaluator. This is perhaps inevitable - it's just impractical to create a
metacircular evaluator for a language as complex as Python. Still, the core of
the class has remained, which is a testament to the fundamental similarity of
the the Lisp model of computation with that of many modern scripting
languages.

------
jinfiesto
I'm simultaneously disappointed and thrilled about this. As I've suspected,
teaching SICP in a language other than Scheme would require dropping chapters
4 and 5. They're simply too hard to do in any other language. Which of course
is a bummer, since chapters 4 and 5 are huge amounts of fun.

All the same, I'm thrilled that SICP is being taught.

~~~
tikhonj
SICP has been taught here for a long time, in Scheme. Unfortunately, the
professor--Dr. Brian Harvey, who apparently contributed significantly to the
second edition of the book and has taught this course for decades--has decided
to retire. Now that he is gone, I guess the people running the course have
decided to move away from Scheme to Python, for some odd and unknown reason,
but still use the book (at least for now).

~~~
joshAg
The reason they moved is because no one else wants to teach it in scheme. When
I took the class in 2007 he mentioned then that after he retired the class
would switch to python because he was the only one who thought SICP was worth
the headache of dealing with scheme.

However, they still use SICP behind the scenes because they have a bunch of
lecture notes for it, and because it really is a great book.

btw, i don't think harvey actually retires until 2013 or 14. i think he's just
doing behind the scenes stuff now.

------
disgruntledphd2
Well, at least they're still using Emacs. That being said, they have a weird
way of describing the hotkeys. For example, for C-x C-f, they tell you to hold
down C-x, release all keys, then press C-f. You don't need to release the
control key, and it adds at least half a second if you do.

------
wes-exp
"I felt a great disturbance in the Force, as if millions of voices cried out
in terror and were suddenly silenced. I fear something terrible has happened."

------
Ape_Shell
Won't this end in disaster considering the use of tail recursion in SICP
versus Guido's flat out refusal to allow tail recursion optimization in
Python?

~~~
tikhonj
While I think that this will end in disaster, tail-call recursion is almost
inconsequential---this is a very introductory course, just an overview of CS,
so performance isn't important.

What is important are the big ideas. For example, the course covers several
paradigms: functional, oo and logic programming. The book uses Scheme for the
first two and a language with very Scheme-like syntax for the last; Python is
completely unsuitable for all but oop, and even there is too complex compared
to Scheme.

I took this course in its old iteration last year, and it was a brilliant
course, probably the single best course I've taken on any topic. That was
partly because of the professor, who has retired, and partly because of the
book and language. Now that only the book is the same, I suspect the course is
very far from brilliant.

I should amend this by saying that the professor, who is actually from Google,
is probably good--he created a set of AI projects used in a bunch of AI
classes that are very good. However, the previous professor was particularly
good as a professor--his research involved CS education. So far, he has been
the best professor I've had, and I've had some _very_ good ones.

~~~
Fixnum
> tail-call recursion is almost inconsequential---this is a very introductory
> course, just an overview of CS, so performance isn't important.

> What is important are the big ideas.

Go back and read section 1.2 ("Procedures and the processes they generate")
again. As far as its authors are concerned, this _is_ one of the big ideas.
Basic concepts of time and space complexity and recursive vs. iterative
processes are so important that they appear as soon as the basics of Scheme
have been introduced. It's a core theme of the book (Why is this n-queens
program slow? How can we eliminate two extra stack saves in this register
machine program?), and the main questions in chapter 5 that the evaluators in
chapter 4 don't answer fully (but look closely at the CPS evaluator in section
4.3) are "how do procedures return values to their callers?" and the related
"how can we write an evaluator that doesn't grow the stack when executing
tail-recursive procedures?"

Ultimately, the beauty of SICP isn't in the paradigms covered but the
understanding of how programs execute, and the beauty of Scheme is the
simpleness of its control flow . It's far easier to a understand Scheme
program than one written in Python, Haskell, Prolog, or any other high-level
language. Do most people understand (modulo sophisticated optimizations) how
the Python interpreter actually handles, say, comprehensions, iterators,
generators, or its complex object-oriented features? Can a first-year student
add these features by hand (forgetting completely about macros and first-class
continuations) to an interpreter herself?

It amazes me that Berkeley professors don't want to teach Scheme (and worries
me, as they're much cleverer than me). The whole magic of the language is that
in the end there isn't any magic at all.

------
gonewest
an abomination, pure and simple.

~~~
aria
Any reason for that conclusion? I personally have known the instructor of the
course for the better part of a decade and he's one of the finest CS educators
out there and has numerous awards to show for it.

I've talked with him about this choice and he has a lot of sound reasons for
making this move backed by his years of experience teaching in various
languages.

What's your line of thought? I use Clojure many hours every day and while I
think that LISP languages are awesome, I don't think they're a good choice for
a 1st programming course either.

~~~
kaapi1
Full disclosure: I've known John (the instructor) for 3 years, and I'm a TA
for this course right now. On the other hand, I was also 'born' Scheme at MIT
(which has also switched to Python).

I can confirm that moving to Python was a very well-reasoned decision. Having
TA'd the Scheme version of the same course 2 or 3 times, I can say that for
all talk of Scheme having very simple syntax, it's surprisingly hard for
students to get used to.

\- The code is hard to read, and, a humans, we're not built for nested
expressions.

\- Useful data structures, like key-value stores, and indexable lists, are
limited, or introduced late

\- Having recursion thrown at you in week 1, before you've learned basic
debugging, the concept of abstraction, or how to write readable code, gets in
the way of learning to program.

\- Almost nobody uses scheme.

~~~
Mithaldu
How does the course get around the problem of functional programming being a
complete pain in the arse in Python? For me the value of SICP was to teach me
how easy, beautiful and powerful it can be to program that way, because
everything else before it failed to communicate that. I can't see how an SICP
in python could have the same effect.

~~~
lloeki
Python has some powerful elements too. It sure it lacks elements and features
of historical and current pure functional[1] programming languages, but I find
it elegant to use python as a set-theory powered language. Often I can solve
complex problems in a few lines by thinking about the sets of elements I am
manipulating, constructing and transforming them. Instead of imperative,
python code becomes very descriptive. Indexing a dictionary with frozensets
and making use of a proper definition of __hash__ to put various objects as
dictionary keys or inside sets allows for tremendous power and terseness and
explicitness.

In [2] the solution given by yairchu can be written succinctly via generators,
which look extremely like a mathematical set definition.

    
    
        def grandKids(generation, kidsFunc, val):
            return reduce(lambda a, v: (x for v in a for x in kidsFunc(v)), xrange(generation), [val])
    

I often happen to think about a problem and explicit it with pen and paper
using pure mathematical set notation then implement it in Python.

[1] [http://stackoverflow.com/questions/1017621/why-isnt-
python-v...](http://stackoverflow.com/questions/1017621/why-isnt-python-very-
good-for-functional-programming) [2]
[http://stackoverflow.com/questions/1016997/generate-from-
gen...](http://stackoverflow.com/questions/1016997/generate-from-
generators/1017105#1017105)

~~~
Mithaldu
Mind: I said "a pain in the arse", not "impossible". And i think not only
about the writing (writing such things regularly is not what any programmer
would want to do), but also the debugging perspective.

What you have done there is cute and commendable as a mental exercise, but if
i'd ever encounter that in production code someone would make a close
encounter with my chainsaw. This is basically undebuggable (i don't know the
line/statement debuggers python has available, so i'm guessing here at what
happens) because either the debugger will step over that in one step because
it's one statement, or it'll just keep stepping on the same line again and
again which is also entirely useless.

Lastly, what you did there is basically golf the living hell out of that code
to bring it down from multiple statement lines to a single one. If i have to
reach to such means i might as well use Perl. Only Perl actually does allow me
to put multiple statement subs into a lambda, so i don't have to golf there.

Weird days when i have to golf in Python but don't need to in Perl.

------
kaapi1
But they can do such cool projects! Mining twitter data? Seriously?

[http://wla.berkeley.edu/~cs61a/fa11/projects/trends/trends.h...](http://wla.berkeley.edu/~cs61a/fa11/projects/trends/trends.html)

~~~
spacemanaki
That's definitely cool, but as I mentioned in another comment, check out what
they're missing:

    
    
      metacircular Scheme interpreter
      lazily-evaluated Scheme interpreter
      non-deterministic Scheme interpreter
      pseudo-Prolog in Scheme
      register machine simulator
      compiler to bytecode for the same machine
    

edited for formatting

~~~
kaapi1
They do interpreters for Logo instead, and wow... not even 6.001 at MIT did
the register and bytecode stuff.

~~~
tikhonj
The interpreter for Logo is actually _extremely_ similar to an interpreter for
Scheme; additionally, we went over several variations on the Scheme
interpreter in lecture.

We didn't do the registers and bytecode, which was too bad although fair to
students taking the class with less programming experience. One happy side-
effect of the switch to Python is that there is now a self-paced version that
allows the students to do all that if they want.

------
Apocryphon
What about a compromise? Why doesn't someone translate SICP to a more widely-
used modern day functional language, such as Haskell or Erlang?

~~~
tikhonj
Most of the reasons cited for moving to Python are much more applicable to
Haskell and Erlang. Additionally, both languages--and I say this as somebody
addicted to Haskell--are too narrow: the perfect introductory language should
be able to accommodate both functional programming better than Python and
imperative better than Haskell.

Having a statically typed language would add unnecessary complexity to the
course; those languages come later anyhow.

Finally, some of the particularly brilliant insights that Scheme gives (code
as data and an _extremely_ elegant interpreter in Scheme) are absent in both
Haskell and Erlang.

That said, we really should have more functional programming in other classes.
I think CMU does this with ML throughout the CS program, and I envy them in
that regard. However, this is a different issue; I don't think a language like
that would fit any better to SICP than Python.

