Live data from Hacker News

Paul Graham on SICP (2000)

amazon.com

111–120 of 141 posts

Re: Paul Graham on SICP (2000)

#111

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…

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.

Re: Paul Graham on SICP (2000)

#112
post #47

Earlier quoted context omitted.

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…

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.

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.

Re: Paul Graham on SICP (2000)

#113
post #105
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…

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.

Re: Paul Graham on SICP (2000)

#114
post #109
post #102

Earlier quoted context omitted.

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…

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.

Re: Paul Graham on SICP (2000)

#115
post #109
post #102

Earlier quoted context omitted.

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…

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.

Re: Paul Graham on SICP (2000)

#116
post #98

Earlier quoted context omitted.

> Reading this book doesn't necessarily make you a good programmer 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.

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.

Re: Paul Graham on SICP (2000)

#117
post #103
post #100

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

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

Re: Paul Graham on SICP (2000)

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

Re: Paul Graham on SICP (2000)

#119

Earlier quoted context omitted.

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.

> CLOS is implemented in Lisp itself using macros.

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

Re: Paul Graham on SICP (2000)

#120
post #114
post #109

Earlier quoted context omitted.

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

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

Post reply on HN