CS61A: The Structure and Interpretation of Computer Programs
inst.eecs.berkeley.eduFor those interested in the original Scheme, here's that playlist of SICP lectures by the authors. I read and worked through the second edition book, but found these videos later. They added lots of value and emphasis beyond the written material. https://www.youtube.com/playlist?list=PLE18841CABEA24090
From 1986 - wow!
Funny story: I took Scheme around 1995 for my first college programming class at UIUC, and nobody told me that we could split our code up into separate lines of execution. So I turned in all of my assignments for the semester as a multi-page function composed of higher-order methods executed in one shot. My teacher must have stared at some of them dumfounded, because they all worked. Although remembering back, I don't think I was the only student doing that!
In the end, it helped me see that all programming is basically a spreadsheet and analogous to the STDIN/STDOUT stream processing of Unix executables. All of the stuff we think of as programming, like objects and classes, is basically hand waving to make problems/solutions supposedly fit in the human mind.
>In the end, it helped me see that all programming is basically a spreadsheet and analogous to the STDIN/STDOUT stream processing of Unix executables. All of the stuff we think of as programming, like objects and classes, is basically hand waving to make problems/solutions supposedly fit in the human mind.
Holy shit Zack, I thought you didn't pay attention at Bayside???
Mind-blowing thought for my mind at this place and this time. Something that I intuited at some point but never made concrete by putting it into words. Thanks for sharing!
I couldn't make head or tails of that link but the textbook his here: https://inst.eecs.berkeley.edu/~cs61a/sp12/book/index.html
Looks awesome but I still wish there was a completed clojure version.
http://composingprograms.com/ <- This is the current textbook they use for the course (per the Summer 2023 course site).
yes. but that's the python book.
There are three books involved, two of them are Python. The original SICP, the CS61A Python version of SICP (top poster in this thread linked to it, no longer in use), and the current version of the text (also Python) that I linked.
(The title of the submission seems to have changed, earlier it mentioned both Scheme and Python.)
The link you provided links to a series of pages about (mostly) Python, some SQL and a touch of scheme. Interestingly, it doesn't talk about using scheme as a programming language as much as using python to create interpreters which interpret a small subset of scheme.
I think most people would look at that corpus and say "that's a Python text."
It’s the current version of the textbook for the current version of the submitted course (CS61A). I don’t understand the point you are trying to make. It was an appropriate addition to the discussion.
SICP is one of my favorite books on programming. Along with GEB and Levy's Hackers.
When I want to give a young person a headstart "sneak preview" taster into "our" culture -- or what I think our culture should be, on the intellectual plane, as an ideal, then I'm confident that these in particular can be stimulating little gems.
OK, fine fine: also HHGG as the 4th of my top 3. The first book (in its series) especially but the entire 5+ books of its increasingly misnamed trilogy.
And... Neuromancer. And Snow Crash. And Cryptonomicon. And...
Cool! I was in the process of reading the JavaScript version. Converting the book to various languages will help spread the concepts in this book to a larger audience.
Oh wow! I didn't know js version existed! I'll go check it out.
https://mitpress.mit.edu/9780262543231/structure-and-interpr...
That's the JS version's page. Click "Open Access" to get to the online version.
Anyone have experience reading both LISP and Python version of SICP? Does the Python version as good as LISP version?
Kris Jenkins wrote this page about functional programming, which is the best quick explanation of why functional programming languages matter: http://blog.jenkster.com/2015/12/what-is-functional-programm...
And then you mix that with Larry Wall's famous quote: "Computer languages differ not so much in what they make possible, but in what they make easy."
So you mix these two references together and you get the idea that maybe Lisp and Scheme and ML make functional programming easy. Python, on the other hand, makes it easy to avoid the key feature of Lisp: separating concerns and managing complexity.
This doesn't mean Python is a bad language, and it doesn't mean you can't use python to craft programs in a functional style. But it's A LOT easier in Python for an inexperienced programmer to do things that Lisp and Scheme are trying to force you to avoid (by exposing unnecessary state to a function, conflating concerns and avoiding abstractions for manipulating complexity.)
I think this is why Scheme was originally chosen for SICP over contemporary languages like C or Modula-{2|3} or Bliss. It's simultaneously good for CS pedagogy and a small team can build decent, extendible, testable and debuggable programs with it.
Python isn’t as powerful as lisp so you end up standing on your head to do some of the things that are so straightforward in lisp.
I suppose using python might make it easier for some people to translate what they learned in class into their work, at least if that is in python.
Python has gobs of libraries so it’s easier to write complex programs that can benefit from that than it is to try the same in lisp.
Just in case: use an editor with support for Scheme.
If you want something easy to install, try DrRacket.
- tab indents the current line
- cmd-I (or ctrl-I) will indent the entire buffer
- Press ] to insert a matching closer (an parenthesis, bracket or brace)
When you need it, install the `sicp` package to get the Henderson picture language (and more) used in the book.
Are there "conversions" for other languages as well? I know it's almost required reading for any software developer worth their salt, but I have several failed starts with the original version and have sworn to never have to read Lisp code. I get the gist. I get that Lisp elegantly represents the close tie between data and programs in a way that procedural programs never will, which is probably why it is chosen for the book. But no matter how perfectly suited for the task it is, I won't squint at lines ending in ))))) to try to see that meaning.
> I get that Lisp elegantly represents the close tie between data and programs in a way that procedural programs never will
Procedural is probably the best paradigm box to fit most Lisp in.
> I won't squint at lines ending in ))))) to try to see that meaning.
Nor do people who read and write Lisp. The indentation is really all that matters when reading Lisp. When writing Lisp, having your editor highlight matching parentheses is really the only feature you need to edit an expression that is deeply nested at the end like that. I bet your editor can already do that :)
In general, I would suggest that conversions to non-LISP languages (and that includes things like Ruby because people say "Ruby is my favorite LISP") makes pedagogical goals of teaching the theory difficult.
When I took my intro class in college, it was taught in Pascal. I had already been programming pascal (as taught by a chemist) in high school for a year or so. The first assignment which was Hello World I didn't even need to wake up in lectures for.
The second assignment... I didn't do quite so well. I had been using global variables and playing fast and loose with scope and passing variable parameters into procedures rather than using a function.
The thing was I already "knew" pascal and I had to unlearn what I knew before I could learn how to write pascal properly.
LISP (and Scheme and Clojure) work well in part because it always forces you to learn new concepts rather than having to unlearn what you did as a hobbiest before taking the class. The LISP family is unlikely to have been the choice language of a high schooler.
---
> But no matter how perfectly suited for the task it is, I won't squint at lines ending in ))))) to try to see that meaning.
When I took an AI class taught in LISP a few years later, the TA sent a joke email about how they had broken into some top secret code only to find it was all written in LISP. Due to the constraints of the mail system there they could only send the last {some number} characters.
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Yeah that's exactly why (I imagine) the first course in programming I was taught at University was Haskell. All of us who had been programming since age 8 had to reset our brains. A fantastic strategy for a curriculum if you ask me.
Lisp/Scheme/Clojure I'm sure are elegant and great for the same reasons as Haskell. They have unique traits that work well for teaching CS concepts.
I have one single issue: the syntax. I'm not getting past it. I'm 45 years old and have coded since age 8. I have tried and failed to manage learning or reading Lisp many times. I have tried picking up clojure, reading SICP I have had to tinker with AutoCad (AutoLisp) stuff for work. I'm just accepting that I'm not going to enjoy doing anything Lisp-related to the point where I'll ever manage to usefully read SICP, or learn one Lisp-y language to the point where I'd choose it for anything. And frankly it doesn't matter. I just accept it and move on. And I also understand that I can gaze at some Typescript monstrosity with sixteen levels of curly brackets, and while it's terrible syntax, my brain accepts it. But I can only imagine that it's 30 years (or just 1, who knows!) of curly bracket coding that makes my brain able to swallow that. But I'm not ready to invest even a week or two of time in teaching my brain to accept Lisp syntax.
While I had a class in '94 using LISP, it wasn't until dabbling with using "compute pi using pi/4 = 1/1 - 1/3 + 1/5 - 1/7 ..." as a replacement for FizzBuzz. In 2013 (and I can point to the date) I was also playing with Clojure and wrote:
While I won't claim that that is beautiful Clojure, the `((if pn + -) accum t)` part was a lightbulb moment for me about how LISP and functional programming really worked.(defn pi ([] (float (* 4 (pi 1 0.01 0 true)))) ([term tol accum pn] (let [t (/ 1 term) a ((if pn + -) accum t)] (if (< (* 4 t) tol) a (pi (+ term 2) tol a (not pn)) ) ) ) )With Java 8 (and beyond) I've become comfortable with passing around functions themselves or creating a Map<String, Function> or having an enum with a function field.
As to LISP-ish concepts with {} syntax... https://en.wikipedia.org/wiki/Schwartzian_transformif (type == enum.FOO) { UnaryOperator<String> trim = s -> s.replaceFirst("^0+", ""); idFun = trim.compose(DTO::getFooNum); } else { idFun = DTO::getBarNum; } // ... Set<String> ids = results.stream().map(idFun).collect(Collectors.toSet());@sorted = map { $_->[0] } sort { $a->[1] <=> $b->[1]} map { [$_, -s $_] } # get the size of the file on disk @files;
Oh, newbies can learn Common Lisp badly and have to unlearn. Like, oh, use this let thing rather than introducing variables with setq inside your function, and speaking of which, for proper globals use defvar.
Are you saying let is bad? Why? Or am I reading you wrong?
I only use elisp though, and not common lisp or clojure
Reading Lisp isn't that onerous. For a start, the brackets (and particularly the closing brackets) are basically irrelevant. They help the computer parse the code but you can read it mostly based on indentation.
Anyway, there is a version in Javascript and the linked page has a textbook in Python.
If you have reasons to believe that the ))))) is correct (or in any case you are not looking to convince yourself whether it is correct or not) then it just means "multiple expressions are being closed here, consistently with the indentation". There is no reason to stare at it.
But you are OK looking at this?:
} } } } }Some times it's unavoidable but I'd try to avoid it if at all possible. There is no perfect syntax. It's common, especially with some newer constructs in TS/JS/C# that you end up with lines saying })), because of a closure passed. And I consider that kind of token salad to be quite a smell too.
"...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
"If somebody starts talking about stuff like lines count, function sizes, nested ifs depth and tries to define optimal values, then be very careful about their advices" - me, ¤tYear
Regardless of what you think of this particular maxim, one could do worse than cargo-culting Linus.
Code org itself is IMO fairly trivial. I just do whatever I think happens to look good. But trends will emerge even when you're just coding to taste. Thumbing through my code I find very few instances of either `} } } } }` or `)))))` (disclaimer - I don't use lisp).
I think he's probably right for C. Unfortunately for TS/JS it's not just idiomatic it's downright unavoidable to have at least twice that number of { } levels.
Before async/await I would have agreed with you, but now I think 3 indents is a reasonable maximum (4 if you're writing classes).
Were you merely reading, or were you doing the exercises as well?
SICP was my first introduction to Scheme/Lisp - and not at a young age. Once I started doing the problems, reading it became trivial.
I was trying to read it, without being at all comfortable with the language. But I have also tried and failed multiple times to accept it by e.g. doing Clojure before that. So I wasn't entirely new to the syntax when I tried to read the book.
or you could just use m-expressions. just an idea. you know. use the tools provided by the language.
Nobody actually uses M-expressions. Mathematica and Wolfram use something quite close, but Lisps are almost universally written in S-expressions.
There are some alternative syntaxes like Sweet expression[1] (t-expression), but they've not found any widespread use.