Does anyone know of a better way to navigate the document structure here?
I see this on the GNU website and in the HTML versions of their manuals, so am assuming it's from a design choice made there ...
Making the empty side margins Clickable to indicate "next page" / "continue" or binding the arrow keys, or spacebar-if-scrolled-to-bottom would make this much more tolerable to navigate, I surmise that the emacs / info readers must have more usable controls. Are there nav controls I'm missing?
this must have been so much work. SICP is an intricate masterpiece. So many projects like this fail mid-way. Even if all you do is change the CSS style, that's an accomplishment in itself.
I've just skimmed through the first couple of pages, but didnt find anything about which lisp to use/howto. Any ideas?
There is a package that you can use with Racket: http://docs.racket-lang.org/sicp-manual/index.html In order to use this, you will need to install Racket first: http://racket-lang.org/
I worked through a couple chapters of SICP using Racket and the SICP package in DrRacket before moving on to Emacs and Geiser.
DrRacket is a great starting point if you don't want to bother with setting up Emacs and the SICP package even supports the image elements that are covered in the course.
Any advice from the community on what environment is best for SICP/Scheme? I'm currently using Dr.Racket as I've heard to avoid Emacs at this point, any other suggestions/thoughts?
Unpopular opinion but having read this book, I think it's a "good" text that is a bit blown out of proportion in terms of how good it is. I'm curious for people that endorse to such a magnanimous degree what other literature they've read and what aspects of SICP in particular they find so superior.
Reading the book isn't really good enough. The lessons are tucked into the well thought-out exercises, which is a feature that isn't found an many other texts. The book was written a long time ago, yet they described MapReduce, and the industry took over 30 years to finally see the light. They described functional programming, and similarly, the industry took forever to catch up, though sadly FP is mostly being done…
Oh I should say, I did the exercises too. My background is in math and I'm very accustomed to the meat of the book being in the exercises (I'm looking at you Springer).
The insight that "code is data" and should be viewed as such is very well treated by lots of literature/languages. Tons of languages support "eval" and building an AST is really not that difficult. I think SICP might be a popular entrypoint to interpreters but probably not the best.
Perl supports eval like lots of languages because data CAN be code. It's only in homoiconic languages like Common Lisp, Scheme, Racket, Clojure, and Rebol/Red that code IS data. Just because you have EVAL doesn't make it a 1:1 relationship and that makes a big difference. If your code/data is just a big AST, then macros are trivial and that prompts you to write DSLs...etc.
Right, I'm not even just talking about code as data in a homoiconic sense but literally just, code is a bag of instructions (jumps, load, store, add, etc) regardless of if your language is homoiconic or not. Maybe the point that can be made is that exposure to a homoiconic language earlier helps bridge this gap faster?
Perl supports eval like lots of languages because data CAN be code. It's only in homoiconic languages like Common Lisp, Scheme, Racket, Clojure, and Rebol/Red that code IS data. Just because you have EVAL doesn't make it a 1:1 relationship and that makes a big difference. If your code/data is just a big AST, then macros are trivial and that prompts you to write DSLs...etc.
Right, I'm not even just talking about code as data in a homoiconic sense but literally just, code is a bag of instructions (jumps, load, store, add, etc) regardless of if your language is homoiconic or not. Maybe the point that can be made is that exposure to a homoiconic language earlier helps bridge this gap faster?
Aight we're on the same page now. Yea it's all the same instructions under the hood anyway at some point.
Does anyone know of a better way to navigate the document structure here? I see this on the GNU website and in the HTML versions of their manuals, so am assuming it's from a design choice made there ... Making the empty side margins Clickable to indicate "next page" / "continue" or binding the arrow keys, or spacebar-if-scrolled-to-bottom would make this much more tolerable to navigate, I surmise that the emacs / inf…
There are access keys set that are supposed to work as follows:
t: top of page
b: bottom of page
n: next page
p: previous page
u: up one level
c: table of contents
Unfortunately, they seem to be a bit iffy (partly because some of them are set on multiple elements).
Sarabander's edition is definitely a huge credit to it's author: It isn't just a reprint of SICP; The text and it's font has been updated, many of the diagrams have been redone for clarity and the document and footnotes are hyperlinked. If it's your ambition to follow in the footsteps of others or otherwise just prefer the classic Lisp-haqr experience, you can use a TexInfo version of SICP and have both the text and…
Someone put it on Melpa. `M-x package-install sicp`, then open the info directory node (with `C-h i`) and search for "SICP".