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.
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.