Hacker News Reader

Comment by taylodl | Hacker News Reader

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.

View on HN

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.

Do you need to have a solid foundation in lisp to understand it or is it approachable for experienced software developers in other domains?

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.

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.

MIT EECS freshmen aren't exactly beginners.

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.

Studying SICP in Python is kind of like reading the Odyssey via Google Translate. You'll get the gist of it, but you won't feel the earth move.

Python is a "Lisp lite" and the parts of Lisp that Python leaves out or cripples are incredibly important.

Mostly agree but:

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.

i you squint you'll see CLOS

In Python’s object system? How so?

Access to metaclasses. Whenever I watch a python metaclass talk I can't help but thinking 'welcome to CLOS guys'

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:

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

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.

How so?

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.

PCL is a perfect example of what I'm talking about. Search for the string "braid" in the sources.

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.

What is CLOS? Is this an acronym? Google is failing me here.

Common Lisp Object System

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.

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.

I think BETA comes close, but it never made it into mainstream.

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.

> CLOS is implemented in Lisp itself using macros.

This is a persistent myth. CLOS is built in to the language.

Somehow.

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

> Google is failing me here.

Really? Indeed, if you search for just "CLOS" Google doesn't find it. Duckduckgo on the other hand, gives it in the 3rd link.

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.

there's also "hy", which gives you lisp syntax and access to the python libraries.

https://github.com/hylang/hy

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.

Oh my, they removed 'cons' :(

    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

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.

>>Python is a "Lisp lite"

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

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.

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.

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

How is possible that you read the whole book and didn't learn anything new?

I am not OP, but my take.

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.

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.

It refactors your thought process.

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

>>This comment is for the Scheme-based book. I've never seen the Python-based version.

Recursion is heavily emphasized.

And Python doesn't support tail-call optimization.

Reply on news.ycombinator.com