The lectures are good but I think the book is really unparalleled in it's original format. It stresses building the intuitive sense of deep structure, which I think other formats would have difficulty communicating.
I personally thought the biggest barrier was the mundane, so I tried to write up some tips, test cases and helpful utilities for doing SICP ( https://github.com/zv/SICP-guile ).
I first read SICP after 25 years of professional development, and while I didn't learn anything new I did see things in a whole new light. I think it would have been really useful to have read the book 25 years ago: I think you're going to benefit from having a few years of real-world development experience before reading this book. The profundity, impact and applicability to your work will be much greater. Highly recommended.
This comment is for the Scheme-based book. I've never seen the Python-based version.
There is no Python-based version, Abelson and Sussman only produced one SICP based on Lisp.
It is unfortunate that there are other courses by people not associated with Abelson and Sussman that have kept the same name but not the material. It is misleading to refer to these as "SICP" as they lack pretty much everything that made SICP great. SICP works on _multiple_ levels, it is not [just] a book about Lisp or a book about programming. It is this "emergent" quality that it has that makes it a masterpiece.
Someone wrote that "Philosophy is any culture’s pole of maximum abstraction, or intrinsically experimental intelligence, expressing the liberation of cognitive capabilities from immediate practical application, and their testing against ‘ultimate’ problems at the horizon of understanding." In this sense, SICP is a supremely philosophical book.
Lua is a Lisp-lite, Ruby maybe a Lisp-lite, Python? No way, I'd go as far as say that Python is antithetical to the Lisp philosophy and yes, I know Norvig has claimed something similar in the past. It's still inaccurate and wrong. In an interview, Norvig pretty much admitted that popular appeal is more important to him than the inherent superiority [which he of course acknowledges] of the philosophy behind Lisp.
CLOS is metacircular, implemented in itself. Moreover, it decouples state (classes and instances) from protocol (generic functions and methods) and through the MOP allows you to reprogram every aspect of its behavior.
Python's object system suffers from the same ailments that Python itself does. It's an amalgamation of various hacks, some obviously inspired by Common Lisp [1], others made up on the spot in order to make everything "fit" together.
In order to best see this, browse CPython's source and find how metaclasses are implemented. Then imagine what you would have to do if you wanted to radically change Python's object system. Contrast with the Common Lisp MOP.
[1] Here is Guido talking about Python's metaobject protocol. Taking into account everything it lacks and how it's implemented, it's not really a metaobject protocol in the CLOS sense, but it's enlightening to read GvR's description of his "aha!" moments in the slides -- which he came upon when he read "The Art of the Metaobject Protocol" -- and then realize that he simply picked very few of the ideas from it whilst completely missing the essence:
So yes, Python has metaclasses but metaclasses are only ~5% of what makes CLOS (and AMOP) iconoclastic. For the rest, read "The Art of the Metaobject Protocol" [2]. This should convince you that Python is really nothing like Lisp and the philosophy of metaprogramming that Lisp espouses is dumbed down and made pretty much powerless (in a similar way, interactive programming) in Python.
CLOS (as well as a lot of other things in Common Lisp, like the error system) depends on CLOS being present. This is why writing a competent CLOS compiler that can bootstrap itself is very difficult. But it's so worth it.
The canonical implementation (PCL) was written in pre-ANSI CL without CLOS. There's a number of things that are difficult there, but can't put my finger on any related to bootstrapping.
Never meant to say python metaclasses were equal to CLOS MOP. But the spirit of programming at the OO metalevel is very much similar to what CLOS is about.
Besides Google, I find Wikipedia is often helpful when finding acronym definitions as well. In this particular case, probably adding "Lisp" to your Google search would have helped, but if you didn't know it was limited to that domain, it's understandable that you didn't include it.
CLOS is--IMHO--the most advanced object system ever invented. The freedom that comes from CLOS is mind-blowing. Learning what CLOS can do will make you hate every other object-oriented programming system.
Very true. And the most mind blowing thing? CLOS is implemented in Lisp itself using macros. So as a Lisp user, you are able to extend the language to include the best implementation of any particular paradigm that exists.
The original first CLOS implementation called PCL (Portable CommonLoops) was written in 100% Common Lisp with very little implementation specific CL code. PCL was a library which ran on at least 15 different Common Lisp implementations.
What really is a myth that it's (only) macros. That CLOS implementation is a complex library written as data types, functions, macros, ... and which was bootstrapped to be partly written in itself using classes, method, generic functions, ...
I wish there was a way to compare Google searches of today with Google searches of years ago, I feel like they've been declining in quality and relevance even as I'm sure they've improved their algorithms and even with me letting them know more about me via remaining signed in when I search. Using the "date range" tool to set a maximum date on search results (in this case I just randomly picked "2006", which Google interprets as the end of that year) I get two CLOS results as the first two items and a third one a bit further down, so that method helps me sometimes, but it's not the exact comparison I want...
You can write lisp-y python quite easily. It's not good, pythonic or maintainable, but for learning purposes it is acceptable, especially on the 2.x series. Just start with list comprehensions.
Lua and Ruby I fail to see how they are in any way lisp-y.
Ruby: Almost everything is an expression unlike Python, has symbols unlike Python, closures and anonymous functions are not crippled or second-class unlike Python, has full continuations unlike Python.
Lua: Simple, minimal syntax which is consistent (unlike Python), multiparadigm, designed around one core datastructure, metatables/metamethods, metaprogramming is encouraged, has environments.
If by lispy you mean data oriented code with functions instead of classes and composition, I'd argue that it's not only pythonic, but import this compliant.
I got the impression that Hy is stagnating. They removed 'let' in the recent releases (it's hard to imagine Lisp without 'let'). Also there is no support for async, which is pretty important for modern Python IMO.
hy 0.11.1 using CPython(default) 3.5.3 on Linux
=> (cons 1 '(2 3))
(1 2 3)
hy 0.15.0 using CPython(default) 2.7.13 on Linux
=> (cons 1 '(2 3))
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/hy/importer.py", line 199, in hy_eval
return eval(ast_compile(expr, "<eval>", "eval"), namespace)
File "<eval>", line 1, in <module>
NameError: name 'cons' is not defined
No that is not the point of Python. The point of Python was to create a language which was simple, readable and maintainable, easy to learn for beginners, but not limiting. It was the first mainstream language (I believe) where the design was informed by actual usability testing rather then just subjective opinions.
>>The point of Python was to create a language which was simple, readable and maintainable, easy to learn for beginners, but not limiting.
Adding limits to programmer thinking and creativity is the fundamental design principles of Python.
>>It was the first mainstream language (I believe) where the design was informed by actual usability testing rather then just subjective opinions.
That's actually BASIC.
Python and BASIC come from the same Philosophy.
This is what Edsger W.Djikstra has to say about Basic:
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
As someone who doesn't write a ton of CLOS-using CL, but does write CL, Shen, and professional Clojure I don't see the limitations in python very clearly. It's a language that is data oriented but not homoiconic. It has facilities for lazy stream processing built-in, as well as syntax for not only map/filter/reduce but also an object model where methods are only superficially bound to their classes (remember, self is explicitly passed and it's ETAFTP). Add in optional syntax for combined map/filter on various types (an optimization for the most common use cases for map and filter) and good repl support and you have most (but not all) practical aspects of a Lisp with a shitty prelude. There are libraries in python to fix the shitty prelude if you want to write data-oriented functions in a way that maintains DRY. Outside of not being homoiconic, python has everything. You can actually find homoiconic python in Hy.
The key idea behind SICP and the philosophy of Lisp is metalinguistic abstraction which can be described as coming up with and expressing new ideas by first creating a language that allows you to _think_ about said ideas. Think about that for a minute.
It follows then that the 'base' language [or interpreter in the classical sense] that you use to do that, should not get in your way and must be primarily focused in facilitating that process.
Python is not that language since it's very opinionated and constrained by its decisions in the design space and, additionally, has been _deliberately_ created with entirely different considerations in mind. This is very well illustrated by the idiotic Python moto "There's only one way to do it" which, in practice, isn't even the case for Python itself. A perfect example of style over substance, yet people lap it up.
You can pick and choose a few features that seem similar to Lisp features [even though they are not] but that does not make Python a good language for metalinguistic abstraction. This is a classic example of the whole of Lisp being much more than the sum of its parts, and in reality languages like Python don't even do a good job of reimplementing some of these parts. Going back to what I wrote in the beginning, what fundamentally new ideas and notions about computation that have stood the test of time did you see arising from Python?
Are you sure that first class support for programmable syntax is a very essential part of using Lisp? Any program in mainstream languages will effecfively create a domain language consisting of data structures and functions that work on said data, after all.
If you look at Norvig's Lisp-Python article and the grammar example, the code with the ad hoc language is still smaller and easier read than than the Lisp example.
It sounds like you just don't like Python? Any high level language add limits on one level but allows you to be creative on another level. Choose your poison or enjoy the creative freedom of assembler.
Djikstra was objectively wrong. Lots of great programmers of a certain generation started with BASIC. Maybe Djikstra was a smart guy, but that is a really dumb quote. In any case Python is completely different from the BASIC of the early 1970's.
None at all. What's great about SICP is that it starts from pretty much first principles and builds everything gradually on top of them. Things like managing state etc are presented as a very natural progression.
Not at all. It was written as an introductory text for freshman computer science students with no prior exposure to programming (much less a Lisp or Lisp-like language).
Just keep in mind that the students in question were at MIT. :-)
The book gets very deep (note some of the things that Paul Graham says in his review, and note who is saying those things). Be prepared to expend a lot of challenging brainwork to get through it, but nope, it doesn't rely on previous knowledge of Scheme. One of the many nice features of Scheme (and lispy languages in general) is there isn't a lot of syntax and so on to learn in the first place.
(procedure argument1 argument2...argumentn) is pretty much it.
Even at MIT a lot of people struggled with it because they threw so much at you so quickly, and it's since been replaced with a Python-based intro course.
It is definitely challenging and I'm not sure it is appropriate for beginners unless they are geniuses. But the challenging part is not learning Scheme (which is even simpler than Python if not quite as nice to read), the challenge is it works through a lot of computational topics (implementing an interpreter, lazy evaluation, an object system, a logic language, etc.) in a quite compact format.
It's not the right book for 19-year-olds who want to learn programming. It's the book for 19-year-olds who have been programming since primary school. A complete beginner will struggle terribly, and s/he'd still miss most of what the book is really trying to teach.
Lately, MIT has been investing heavily into obtaining a more cosmopolitan image, so ditching a course aims to scratch the itch of hardcore nerds -- while disappointing -- wasn't unexpected, I guess.
You don't need any foundation in lisp to understand it. The exercises may seem a little hard, but as long as you go through those, you will gain a lot.
This is exactly what I did too, but after 12ish years of experience.
I watched the original lectures on Youtube while working through the book. Really enlightening experience.
I was hooked by the cover art of the book and after a few minutes of watching the lecture where he explained a procedure as a pattern of rules and compared them to spells. That's a really profound way of not only thinking, but teaching too because you have to remember those people in the class are new to computer programming. That's such a good analogy on so many levels.
A text like this may not introduce the reader to any new-to-them CS content. Instead, especially if they have a good bit of experience behind them, it reorganizes their thinking. Which can be just as valuable.
>How is possible that you read the whole book and didn't learn anything new?
For one, it's not a book on anything state of the art. It describes very well known concepts and techniques.
It's more of an introduction to programming and functional concepts and such than something where someone with 25 years of experience or a CS degree will learn much new from.
I've read SICP and not only did I not learn anything new, I did not see anything in a new light either.
Yes, the book is entertaining. But there's more profound enlightenment to be had however when working with actual functional programming for a few years in a supporting language and afterwards nothing in SICP is new.
However I wish I would have read this book when I was an undergrad.
This book gives you a coherent view of computation. It's not just a turing machine that keeps munching instructions. I think this book takes a more dataflow-centric approach. Some people would love it, and I agree this is a good introduction for early CS students. It is focused and compact. That said, I think the enthusiasm surrounding this book is a little bit cult-like. Reading this book doesn't necessarily make you a good programmer, because being a good programmer requires much, much more than having a good understanding of computation. And when you disregard the practical aspect of programming, people will probably find you a bit pedantic.
> That said, I think the enthusiasm surrounding this book is a little bit cult-like. Reading this book doesn't necessarily make you a good programmer, because being a good programmer requires much, much more than having a good understanding of computation.
The usual assertion is that it makes you a better programmer, not that it makes you a good one. The reasoning behind this is that the book is pretty unique in giving you practical fundamentals of programming, in a way you wouldn't be exposed to completely elsewhere (especially if all you've learned so far is modern OOP). I'd say it's important today more than ever, given the increasing amount of programmers emerging out of bootcamps.
I you have finished SICP (including exercises) I will posit you must be a pretty decent programmer. (Which is not necessarily the same as a good developer, but that is a different discussion.)
The cliché observation is that "correlation does not equal causation."
It's interesting to think about that: Given that you have to choose to read SICP, and chosen to work your way through it, including choosing to use Scheme instead of whatever is popular today and so forth, and given that SICP is unlikely to get you a job ("Oh, you read SICP? You're hired, you awesome hacker!"), is it possible that you already have certain qualities that correlate with being a pretty decent programmer?
I mean, it's not like reading SICP is free. You're choosing to read it when you could be reading something just as informative and considerably more practical. So are you already a pretty decent programmer?
Going down this rabbit-hole of reasoning, I also wonder, "If you're reading about SICP on Hacker News and decide to read SICP because it sounds interesting, are you a different kind of person than if you decide to read SICP because there seems to be a strong social signal around being a decent programmer if you read SICP?
Those two motivations are obviously not the same.
And now I'm trying to remember why I read SICP way back when. I'd like to flatter myself that I was intellectually curious and read it for its own sake, but to be transparently candid, I'm not so sure I wasn't trying to be like the kind of people I admired at the time.
When the book was written it was not unusual for new students to arrive at MIT without any computer experience. So that book was often their very first exposure to computer programming.
In the short term, those who read it based on signaling value (the "pretenders") will be worse programmers than those who read it purely for fun ("the originals").
But in the long term, action matters more than intent. Those who kept "pretending" and kept learning (no matter the reason) will be just as good or better.
I know correlation is not causation but come on... if a set of students follows as CS introductory course and ends up learning some CS during the span of course, it is overreaching to assume the CS course had something to do with it.
SICP has a well deserved spot in the "basically a bible for engineers" category. I remember hearing about from a podcast in 2012 (I can't remember which one, sadly), and immediately fell in love with the free copy from MIT's website.
I was pretty excited when I found a physical copy at a thrift store for two dollars. Even though I had already read it, I like having it on my shelf to prominently display.
It's not a trivial read, but I feel like it's complicated enough to make you think, but not frustrate.
> Let's see if we can put this in terms that the undergrads will understand -- a problem set
It would be more accurate to say "in terms that MIT/Stanford/Ivy undergrads will understand", considering most universities just call it "homework". Since that's the background Paul and many of his colleagues come from, it's understandable. However, as a CS undergrad at a more run-of-the-mill university, it's a bit discouraging to see this vocabulary so widespread at the top levels of the industry - it makes it seem almost impossible to break in when everyone else is a part of the "elite" that you're not in.
At the end of the day, I realize this is a totally trivial issue. Just curious if any other folks out there have noticed this.
lol what are you talking about. what a thing to interpret as a "micro-aggression" or indicator of "class-divide". Google the term problem set and you'll see plenty of schools that aren't ivies.
Personally, I've never heard what university students do as "homework" -- that's what grade schoolers and high schoolers do and have to turn in. At least in my (public US university in the 1980s) experience, professors generally suggested problems sets to do, but they generally weren't required, although not doing them would make you unprepared for the exams which often had very similar problems as to the ones assigned.
I am going through SICP currently, after having it on my reading list for long. Loving it so far. I agree that exercises in the book shouldn't be skipped, not a single one. You might seem to have grasped the material until you take up the exercises and realise there is more to it.
I still hold that part 1 (building abstractions with procedures) of SICP is not that good from a teaching perspective. The continual reliance on more and more obtuse mathematical formulae for the programming examples is sub-obtimal for engaging or informing a reader who does not have a strong mathematical background.
This is made even clearer in part 2 (building abstractions with data) which is an absolute masterclass in clear effective teaching. Part 2 is everything part 1 is not. It is approachable, immediate, ...tactile in its examples.
I've always wondered if the two section were written by the different authors.
I can't understand why "694 people found this helpful". It's not a very good review or even a review at all. The only review-like part of it is "I still don't feel I have learned everything the book has to teach." which is very cryptic. Why doesn't Paul Graham feel like he has learned everything from the book? Is it because the book has a huge amount to teach and it isn't possible to consume it all in a short period of time or is it because the lessons are poorly taught and therefore require careful re-reading or is it because the book can be read at many different levels?
I have the feeling anything PG says these days is applauded w/o proper reflection. Maybe it’s just me, but I have the feeling most of his thoughts are quite profane
For me Paul Graham is a very rare breed of people that manages the delicated symbiosis between academic Vs entrepreneur - theory Vs real life - gut feeling Vs mathematical analysis.
Is overwhelming contribution to the Startup culture will only be well understood by future historical analysts.
I think you are only half right. I don't know him, but from his online writings, he seems to be a guy who does have a clue, has been around, and has some good insights. But you are correct that he is hero-worshiped more than such things normally deserve. Like everyone else, he is a person whose reputation online might not be in sync with who he is on a personal level. But that is the nature of the internet, and not a reason to lash out at him personally.
I haven't read anything close to 50% of his thoughts to know if most of them are quite profane, but the few other pieces I've read have indeed seemed quite insightful.
The reviewer basically says that anyone who gave the book just one star is an idiot who "doesn't get it". "Smarter people than you like this book, so you are wrong." Which might very well be true...but it is not really helpful or even enlightening.
But such rhetoric seem to be extremely effective in our community, where everyone wants and needs to feel smarter than the rest. If you can make the reader feel smart by declaring some other group dumb, you are ensured upvotes. Just consider the enormous effectiveness of pg's metaphor about the "blub programmers". People love to quote this in defense of whatever random paradigm or technology, since it is so effective to frame the in-group versus the sheeple.
I read all these comments around the internet stating "you" read SICP. Does that mean you worked all the problems? I'm currently reading through SICP (after a CS degree and 12 professional years experience if that really means anything) and it takes a long time, a lot of work, and it is hard.
Reading these comments I feel like an idiot. When you say you read it did you do all and I mean ALL the problems? I find the reading part and thinking I understand well the content to be quite easy and comprehendible though. I love it for that and I feel like I am getting a great deal out of it.
Maybe Paul Graham and Ycombinator getting famous. Or the MIT CS undergrad "intro to CS" switching to Python so the disgruntled undergrads no longer give 1-star reviews.
Well he suggest himself it is due to annoyed students. Since apparently the book is not used as much in introductory classes anymore, less people are forced to read it before they are ready.
I came to SICP from a totally different path. In 1996 I started programming Scheme and developed my own library for matrix calculus and for symbolic calculus. A few months later I had a copy of SICP in my hands. All the things I did previously on my own now were dealt with in a more systematic and profound way. - Many concepts that I learned from that book became important twenty years later in modern programming languages. Closures, immutability, higher order functions, functions returning functions, etc
SICP was a very profound experience. I still have that copy on my book shelf.
Was glad to see this posted here, especially since in late August, I'll be taking the one-week SICP course that David Beazley in the Python community put together:
Given there's so much free material on SICP out there, paying $2500 to learn SICP feels a bit like paying a personal trainer to force yourself to work out (which I've admittedly done before)
Also, David Beazley's work on SWIG is also outstanding! He deeply groks the C++ type system as well a plethora of other languages, and made a great tool that ties them all together.
>The Simplified Wrapper and Interface Generator (SWIG) is an open-source software tool used to connect computer programs or libraries written in C or C++ with scripting languages such as Lua, Perl, PHP, Python, R, Ruby, Tcl, and other languages like C#, Java, JavaScript, Go, Modula-3, OCaml, Octave, Scilab and Scheme. Output can also be in the form of XML or Lisp S-expressions.
You can see some of David Beazley's presentations on YouTube. He presents regularly at PyCon and other conferences. He's also the author of Python Essential Reference and the editor of Python Cookbook, 3rd Edition.
One of my favorite presentations of his that gives a flavor of his instruction style is "Python Concurrency from the Ground Up" at PyCon 2015:
I saw this one live, but I think the recording is good quality. He live codes a Python 3 highly concurrent, generator-based TCP server that does fibonacci calculations, if I recall correctly.
One of the YouTube comments gets it right, it's "The Jimi Hendrix of Python".
The prior course I took with him was called "Writing a Compiler (in Python)". I think I took it the first time it was offered, in 2012. In that course, we implemented a programming language that was a (very small) subset of GoLang, by building the entire parser/compiler in Python. So, in 5 days, you learned all about compiler theory, and wrote your own compiler (in Python) for this GoLang-style language. The last day, we peeled away the layers of the onion for how PyPy is implemented under the hood, using our newfound compiler toolchain knowledge. It was really fun. He has a very engaging presentation style and a fascination with computing that is infectious. You leave the course energized and happy to be a programmer.
"So, in 5 days, you learned all about compiler theory, ..."
You did not. Not to detract from the course - I have no opinion on that and you seem to have got a lot out of it and sounds like fun. But in 5 days no instructor or course is going to give you anything more than a fairly superficial understanding of something like compiler theory.
It sounds a lot like a typical module from one of the more rigorous introductory undergraduate courses on compilers, that's good stuff!
Interesting, thanks for sharing. I would love to hear feedback on how the SICP course is. It looks like his classes are in person only which is unfortunate for those not in the US I guess.
What collection of books or topics would be a suitable replacement for the CS fundamentals most discussed by SICP? When I hear people praise this book, it's often in somewhat vague terms.
I have a copy of SICP sitting on my shelf right now. I've really wanted to get started on it, but I must say that it seems like the kind of book that would take hundreds of hours to get through (with all the exercises, etc). Is that true?
Roughly how long have people taken to get through it?
I worked through the book in my spare time some years ago, and yes it probably took me hundreds of hours. I don't know the exact amount of time, but it was definitely in that range. I did not have any CS or math background, but a lot of practical programming experience. I was absolutely worth it.
I did not watch any of the lectures, just worked through the book, so I can't say if watching the lectures will make it easier or just take more time.
Thanks, good to know how much time I need to apportion.
I'm trying to find a way that I can fit it around work/family schedules and not let my concentration go too stale. I'm thinking of trying for an hour a day, but that feels so prescriptive...
The only advice I can give is, do not set goals like a chapter a week or n exercises a day. Sometimes a section or exercise is just hard and you have to take the time necessary.
This might be considered heresy but the first two chapters can go very quickly, and taken alone can be very impacting, so I'd recommend just them as an initial goal. Once you accomplish it (sooner than you might think!) you ought to use the momentum to continue on, just know it's a steep book for the last few chapters...
A quote I keep in mind: "The reader who has read the book but cannot do the exercises has learned nothing." -- J.J. Sakurai
I'm not quite as strict as Sakurai suggests -- sometimes it's helpful for me to plow ahead anyway and try to come back to the exercises later... Sometimes it's never, but if I do some exercises, integrate some of the non-exercises with other bits of knowledge, I still feel like I've learned something rather than nothing. "Gotten familiar with" might be the best phrase, and there's a nice technique Mike Acton made an infographic of for getting familiar with a stack of books on short notice: https://itsyourturnblog.com/you-cant-cheat-at-learning-quick...
My background is as a self-thought programmer. Never had any formal education related to software, but have worked professionally as a developer for many years. This gives some solid pragmatic experience, but the "fundamentals" tend to lack. I considered a compiler a form of black magic which I had no hope of ever understanding.
SICP gave me a throughout tour of basically all layers of the stack. Understanding the fundamentals of compilers just makes it easier to understand the design decisions behind individual languages, which makes them easier to learn and easier to leverage. SICP is also a journey throughout various paradigms - imperative, functional, stream based, lazy, OO, constraints solving etc. Having a solid grasp of various computing paradigms just give you much more freedom in your approach to solve problems. It also helped dispell any religion I had about particular platforms and languages - I realized religion is just comfort + fear. Experimenting with things like continuations and backtracking was almost mind-altering for me, since I thought the stack was an immutable law of nature and just not a particular design.
Scheme, especially the subset used in SICP, is about the simplest language you can have in programming. It was meant to be understood by freshmen with no prior exposure to programming (while incidentally being a more expressive language than mainstream ones, including Python). Is it so hard to spend the couple of minutes it takes for a person who's already a programmer on understanding the language used in this book? Is it so appalling to read a syntax more consistent than you're used to?
Way to miss the point of the book. But a surprisingly common one.
and just to clarify my why, it really bothers me that people who do python tend to only want to do python, as if it's some advanced, modern language and the only choice for doing code if you don't like c# or java or c++. it's well over two decades old, which isn't a problem in and of itself, but python ignored and has continued to ignore better programming language designs both before and after it was created. how about you learn something new, and just use a lisp or scheme, just as the course and book does, like racket? and if one doesn't want to use a lisp or scheme, then an ml language like sml, f#, or ocaml would be the next best choice.
python is a scripting language. it should have stayed that way, but instead, it's used to build large systems and to teach programming to people. it's a real shame.
and to conclude, the entire point of SICP is that you don't need much of a language. all you need is a small collection of fundamental ideas in your language. and as it turns out, python does not even have those.
There are many ideas in SICP that trigger breakthrough moments (metacircular evaluator, church encoding, code is data / data is code, tower of interpreters, emergence through abstraction) that would easily be seen as gimmicks in Python, because they transcend the hastily-put-together nature of Python. In other words, Python was designed by ordinary people, people who in many cases went out of their way to limit what thoughts the language can help you think (mostly in the interest of popular appeal).
1) Scheme is really really simple to learn. If learning a new language is a major obstacle, you will not be able to finish the course anyway, since it includes implementing multiple small languages.
2) Some of the tasks would be nearly impossible in Python (or any other non-homoiconic language). One exercise is implementing a metacircular evaluator. To do this in Python would require you to implement scanner, parser etc - a major undertaking.
