Live data from Hacker News

Paul Graham on SICP (2000)

amazon.com

121–130 of 141 posts

Re: Paul Graham on SICP (2000)

#121
post #103

Earlier quoted context omitted.

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 ea…

You say it was absolutely worth it. What did you gain from the experience?

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.

Re: Paul Graham on SICP (2000)

#122
post #119

Earlier quoted context omitted.

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

Re: Paul Graham on SICP (2000)

#123
post #98

Earlier quoted context omitted.

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…

But wasn't it used for introductory CS courses? Perhaps someone can chime in about how it worked.

Re: Paul Graham on SICP (2000)

#124
post #24

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 tr…

5 cents on you heard on Microsofts Channel 9 podcast.

I don't think so, since I don't think I've heard of that one. It was probably whatever functional programming podcast was popular back then.

Re: Paul Graham on SICP (2000)

#125
post #123

Earlier quoted context omitted.

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…

But wasn't it used for introductory CS courses? Perhaps someone can chime in about how it worked.

It was used for introductory courses at MIT, but no longer.

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?

Re: Paul Graham on SICP (2000)

#126
post #114

Earlier quoted context omitted.

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…

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 f…

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.

Re: Paul Graham on SICP (2000)

#127

> 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 discouragi…

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.

Re: Paul Graham on SICP (2000)

#129
post #123

Earlier quoted context omitted.

But wasn't it used for introductory CS courses? Perhaps someone can chime in about how it worked.

It was used for introductory courses at MIT, but no longer. 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?

My guess -

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.

Post reply on HN