CS61A: The Structure and Interpretation of Computer Programs
inst.eecs.berkeley.edu
inst.eecs.berkeley.edu
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!
Looks awesome but I still wish there was a completed clojure version.
(The title of the submission seems to have changed, earlier it mentioned both Scheme and Python.)
I think most people would look at that corpus and say "that's a Python text."
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...
That's the JS version's page. Click "Open Access" to get to the online version.
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.
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.
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.
Anyway, there is a version in Javascript and the linked page has a textbook in Python.
}
}
}
}
}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).
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 :)
SICP was my first introduction to Scheme/Lisp - and not at a young age. Once I started doing the problems, reading it became trivial.
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.
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
I only use elisp though, and not common lisp or clojure
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.
(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.
if (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;There are some alternative syntaxes like Sweet expression[1] (t-expression), but they've not found any widespread use.