Paul Graham on SICP (2000)
amazon.com
amazon.com
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 ).
Link: https://www.amazon.com/review/R403HR4VL71K8/ref=cm_cr_rdp_pe...
Also, (2000) should be added to the title.
[1] https://www.amazon.com/gp/review/RRFAH7G81ASUL?ref=pf_vv_at_...
https://mitpress.mit.edu/sites/default/files/sicp/index.html
(I wish I'd kept my Knight of the Lambda Calculus button. Even having had prior programming experience, 6.001 was not pleasant.)
This comment is for the Scheme-based book. I've never seen the Python-based version.
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.
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.
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.
Python is a "Lisp lite" and the parts of Lisp that Python leaves out or cripples are incredibly important.
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.
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:
http://laser.inf.ethz.ch/2012/slides/vanRossum/laser-mop.pdf
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.
[2] https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...
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.
https://en.wikipedia.org/wiki/Common_Lisp_Object_System
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.
This is a persistent myth. CLOS is built in to the language.
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, ...
See for example: https://github.com/binghe/PCL
Really? Indeed, if you search for just "CLOS" Google doesn't find it. Duckduckgo on the other hand, gives it in the 3rd link.
Lua and Ruby I fail to see how they are in any way lisp-y.
Lua: Simple, minimal syntax which is consistent (unlike Python), multiparadigm, designed around one core datastructure, metatables/metamethods, metaprogramming is encouraged, has environments.
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 definedMore like "Ruby lite".
You will likely do more Lisp in Perl than you will do in Python.
In fact the whole point of Python is not to be like Lisp.
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.
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?
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.
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.
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.
How is possible that you read the whole book and didn't learn anything new?
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.
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.
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.
Recursion is heavily emphasized.
And Python doesn't support tail-call optimization.
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 don't think I've seen anyone claim SICP will make you a "good" programmer. I have seem people claim it will make a good programmer better, though.
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.
If we look st those who took it as a course, we have to consider that they are already taking a CS course, and at MIT, no less.
Once again, correlation? Or causation?
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 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.
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.
I've been out of university too long to know what they called homework (plus I never did it, hence my B- average), but problem set sounds about right.
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'd put my bets on "mundane".
Is overwhelming contribution to the Startup culture will only be well understood by future historical analysts.
1. relating or devoted to that which is not sacred or biblical; secular rather than religious.
2. (of a person or their behavior) not respectful of orthodox religious practice; irreverent.
3. treat (something sacred) with irreverence or disrespect.
That all said, I wouldn't go as far as to say profound. Just insightful commentary distilled from experience.
I suppose a few other proper reviews exist on the book's page, so adding another like these might be not so important.
(Also, Amazon in 2000 was quite a different thing than Amazon in 2018. It was much smaller, and much less important.)
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.
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.
pg posted his review on May 20, 2000, when it had 3 stars. From then till today, the book has 4.5 stars. What must have caused this change of opinion?
SICP was a very profound experience. I still have that copy on my book shelf.
Could you elaborate on this point? I am not familiar with this individual or their classes. Is there something special?
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:
https://www.youtube.com/watch?v=MCs5OvhV9S4
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, ..."
It sounds a lot like a typical module from one of the more rigorous introductory undergraduate courses on compilers, that's good stuff!
https://en.wikipedia.org/wiki/SWIG
>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.
Original author(s): David M. Beazley
Roughly how long have people taken to get through 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.
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...
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...
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.
Maybe someone can take up the mantle on that.
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.
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.
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).
Lisp was discovered and evolved by geniuses.
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.