Note to the unaware, both* this version and the classic (Scheme) version are Creative Commons-licensed and freely available online. (*edit: thanks to keithwinstein for enlightening me -- I wrongly thought it was just the one. The publisher's site doesn't advertise this at all!)
The in-line editor is a bit intrusive (fills up most of my screen, unlike say eloquentjavascript.net) but it's still pretty neat to have run-able examples. Kudos to the creators.
A ton of work seems to have gone into this -- they have a meta-circular evaluator in JavaScript (and it's not that much longer than the original Scheme)!
This isn't an ideal language for doing this stuff. The Scheme version is completely transparent about what you're doing; whereas this kind of language makes you work through a thick veil of abstractions.
(This line doesn't occur in the Scheme version, but the analog would be (quote (let ((size 2)) (* size 5))). Which would you rather debug?)
You can see there's more negativity in this thread compared to the Python one. HN crowd is pretty hostile toward JavaScript.
Yet JavaScript is obviously a better choice than Python in terms of SICP Scheme substitute. For example:
- JavaScript is arguably a Scheme descendant, or at least have closer blood ties with Scheme than Python.
- The Lambda in Python is just awkward, and SICP is a book about lambdas.
- The Chapter 2: JavaScript use more anonymous object which makes it a better choice, although there are dictionaries in Python it's more favored to use Classes.
- Chapter 3, the Object-oriented Programming part: Use lexical closure to simulate object is just day to day JavaScript. So does dispatch and pattern matching messages.
- Chapter 3, the stream part: In JavaScript world the "functional" streams approach is also very popular.
- As for symbolic programming and such, they're both not particularly good. But that's a problem for all mainstream languages. At least JavaScript has programmable string template.
As you can see many SICP stuff are just day-to-day JavaScript, but not so much in idiomatic Python. Let alone JavaScript is more approachable in almost every platform, and much easier to make interactive tutorials.
It's C# that created and popularized async/await, not JS (and it having an already open source implementation at the time, it was available to everyone for free).
Python is based on mainly on statements rather than expressions, and lambdas can’t have multiple statements, so writing lambdas is different from writing normal Python code.
In a very real sense, there is no idiomatic way to write complex lambdas in Python. What you would do instead is define a named function and pass it in as an argument. This is fine but definitely more complicated.
One major benefit here is how approachable this is. One could even simply open Dev Tools on their browser and use the console as a REPL. As someone who installed Scheme/Dr Scheme/Dr Racket long ago, it's nice to say, "you can get started right now". I know there'll be a lot of complaint about JS as a language choice but, it's pretty ubiquitous. And, much like Scheme, no one's saying, "you should use this for your next app that you have planned"
It's definitely a benefit but the trade-off is rough - the book itself is 'approachable' in the sense that it's written well in an accessible style. But it's dense in concepts and ideas and smacks you with them right off the bat. A lot of them are much more convoluted when expressed in JS, especially for the first time. Take a look at the sort of challenge the authors had to deal with:
I agree in contrast to the previous reply I made.
I still play with Shen, and I would love to see SICP in Shen, since Shen has ben implemented for many languages including JavaScript, but it's still a Lisp. I should try my hand at it if I really want to learn Shen.
I am also an APL/J fan and this footnote in SICP rings true:
[15] Richard Waters (1979) developed a program that automatically analyzes traditional Fortran programs, viewing them in terms of maps, filters, and accumulations. He found that fully 90 percent of the code in the Fortran Scientific Subroutine Package fits neatly into this paradigm. One of the reasons for the success of Lisp as a programming language is that lists provide a standard medium for expressing ordered collections so that they can be manipulated using higher-order operations. e programming language APL owes much of its power and appeal to a similar choice. In APL all data are represented as arrays, and there is a universal and convenient set of generic operators for all sorts of array operations.
I wanted to say Shen will never be relevant or useful without a change to it's licensing model, but looking at the website it seems like that exact thing has actually happened? It's hard to find concrete info so I'd love for someone to confirm, but IIRC Shen was encumbered by some sort of distasteful closed source model previously but it looks like that's no longer the case? Very excited to dive in if that's the case.
EDIT:
> In 2021 the SP kernel was returned to open source forming the basis for the S series of kernels on which this manual is based.
This is the wrong kind of approachable, because you have to learn a ton of random web things before you do anything outside the repl and before your program can even process user input and then people struggle with those two concepts that would be trivial to them if they could be introduced earlier.
Having seen what having javascript as a first language does to first year students I can't understand why this is considered a good idea.
I'm an uncle of 6 children, ages 7 and under. My guess is that if any of them have ever seen a VT100 terminal emulator or Windows console window, it was probably only when watching me or my brother-in-law. So traditional line-oriented programs, with plain text input and output, will be alien to kids of this generation.
I know Racket has an integrated GUI toolkit, but will this new generation be able to run it on their tablets?
One benefit of the great variety in front-end JavaScript frameworks, often criticized as churn, is that we're more likely to arrive at an abstraction that will be approachable to beginners. I look forward to watching how this generation learns to program.
Right, but if we're looking for the quickest path, "right click on this page, and select 'Inspect'" and boom. You're there. Certainly one could go to https://replit.com/ and choose from a host of "better" languages. My approach was trying to avoid someone having to install anything at all. As soon as you say, "ok, you'll need to install NodeJS, then use npm to install this package....", things get dicey. Someone who's serious about learning will fight through it, but someone who's just starting out may be put off.
First they replace Scheme with Python for their CS classes, and now SICP in JavaScript! Isn't this another portent from Nostradamus about the coming of the end of the world?
It's not the worst thing to happen, but for the love of god, couldn't they have at least chosen an expression oriented language?! Even Ruby for god's sakes would've been better than JS!
If they were to choose another language, StandardML should have been the choice.
It was designed to be easy for students to implement with relatively easy parsing rules. It is fully functional, but allows mutations. It also has an actually sound type system.
I saw this the other day on Amazon while picking up the SICP instructor's edition. For the life of me, I can't figure out why they chose JavaScript to do this. And the new authors are professors.
Since the original SICP has a permissive license, I've actually thought about doing something similar, but with a more modern functional language.
> Yeah, imagine the craziness of making materials like this accessible to users of the most widely used language.
One of the reasons it was originally written for scheme is that scheme has a small core, simple syntax and can very easily be learned while reading SICP.
More importantly, the type of user that would get put off by using/learning scheme, is probably not going to make it through SICP. Learning just enough scheme is arguably the easiest part of going through SICP.
SCIP uses an amount of high-level functions that are frankly ridiculous outside of a very functional language. Hell, maybe even outside of a Lisp-1. That's not to say that Scheme is the best language (probably not in my top 5), but there are better languages than javascript for SCIP, and better programming methods than SCIP for javascript.
One of the exercises in the first (or was that the second?) chapter is speeding up Fibonacci's iterative algorithm by viewing the state transition equations that derives F_n and F_n+1 from F_n-1 and F_n as a pair of linear transformations, therefore a matrix multiplication that can benfit from fast exponentiation (repeatedly squaring). Then in the chapters after that you code a symbolic differentiator and add pattern matching to the language.
SICP doesn't try to be accessible, it's explicitely an engineering text book made for engineers. That's even the reason some people have criticized it[1] and wrote another book[2] with the same themes and goals but ditching the excessive math focus. Anyone who can understand SICP's exercises can understand Scheme.
I got a chance to talk to Hal Abelson and two things I found surprising where: 1) he thought part of SICPs success was
due to the calibre of students MIT gets and 2) He though Javascript was a fairly good scheme approximation ( although with too much syntax).
>He though Javascript was a fairly good scheme approximation ( although with too much syntax).
that one isn't too surprising because "putting scheme in the browser" was quite literally what Eich set out to do
"As I’ve often said, and as others at Netscape can confirm, I was recruited to Netscape with the promise of “doing Scheme” in the browser. At least client engineering management including Tom Paquin, Michael Toy, and Rick Schell, along with some guy named Marc Andreessen, were convinced that Netscape should embed a programming language, in source form, in HTML. So it was hardly a case of me selling a “pointy-haired boss” — more the reverse.
Whether that language should be Scheme was an open question, but Scheme was the bait I went for in joining Netscape. Previously, at SGI, Nick Thompson had turned me on to SICP.
Readit News
https://sicp.sourceacademy.org/ (JS version)
https://mitpress.mit.edu/sites/default/files/sicp/index.html (1984 classic)
The in-line editor is a bit intrusive (fills up most of my screen, unlike say eloquentjavascript.net) but it's still pretty neat to have run-able examples. Kudos to the creators.
A ton of work seems to have gone into this -- they have a meta-circular evaluator in JavaScript (and it's not that much longer than the original Scheme)!
This isn't an ideal language for doing this stuff. The Scheme version is completely transparent about what you're doing; whereas this kind of language makes you work through a thick veil of abstractions.
(This line doesn't occur in the Scheme version, but the analog would be (quote (let ((size 2)) (* size 5))). Which would you rather debug?)
You can see there's more negativity in this thread compared to the Python one. HN crowd is pretty hostile toward JavaScript.
Yet JavaScript is obviously a better choice than Python in terms of SICP Scheme substitute. For example:
- JavaScript is arguably a Scheme descendant, or at least have closer blood ties with Scheme than Python.
- The Lambda in Python is just awkward, and SICP is a book about lambdas.
- The Chapter 2: JavaScript use more anonymous object which makes it a better choice, although there are dictionaries in Python it's more favored to use Classes.
- Chapter 3, the Object-oriented Programming part: Use lexical closure to simulate object is just day to day JavaScript. So does dispatch and pattern matching messages.
- Chapter 3, the stream part: In JavaScript world the "functional" streams approach is also very popular.
- As for symbolic programming and such, they're both not particularly good. But that's a problem for all mainstream languages. At least JavaScript has programmable string template.
As you can see many SICP stuff are just day-to-day JavaScript, but not so much in idiomatic Python. Let alone JavaScript is more approachable in almost every platform, and much easier to make interactive tutorials.
Try publishing a dependency for Java. Now try doing it for JS.
Everyone was able to do highly concurrent workloads. Something that was extremely difficult before Javascript.
It just smells of elitism to me. It's a wonderful language that brought the async await system to everyone.
Npm is light years ahead in execution and usage. Python distribution is.... interesting with eggs & poetry
In a very real sense, there is no idiomatic way to write complex lambdas in Python. What you would do instead is define a named function and pass it in as an argument. This is fine but definitely more complicated.
- Gets very messy when nested
And SICP is a book about learning computer science by abusing lambdas.
https://sicp.sourceacademy.org/chapters/1.1.7.html#ex_1.6
We're just a few pages in and the original instructive exercise of 'why can't I make my own if out of cond' involves learning the JS ternary operator.
I am also an APL/J fan and this footnote in SICP rings true:
[15] Richard Waters (1979) developed a program that automatically analyzes traditional Fortran programs, viewing them in terms of maps, filters, and accumulations. He found that fully 90 percent of the code in the Fortran Scientific Subroutine Package fits neatly into this paradigm. One of the reasons for the success of Lisp as a programming language is that lists provide a standard medium for expressing ordered collections so that they can be manipulated using higher-order operations. e programming language APL owes much of its power and appeal to a similar choice. In APL all data are represented as arrays, and there is a universal and convenient set of generic operators for all sorts of array operations.
EDIT: > In 2021 the SP kernel was returned to open source forming the basis for the S series of kernels on which this manual is based.
(https://shenlanguage.org/OSM/History.html)
Anyone have a PDF link to a paper about this Fortran analyzer?
Having seen what having javascript as a first language does to first year students I can't understand why this is considered a good idea.
I know Racket has an integrated GUI toolkit, but will this new generation be able to run it on their tablets?
One benefit of the great variety in front-end JavaScript frameworks, often criticized as churn, is that we're more likely to arrive at an abstraction that will be approachable to beginners. I look forward to watching how this generation learns to program.
Nothing prohibits them from learning, "better" languages after you reach them, but first you have to reach them.
It was designed to be easy for students to implement with relatively easy parsing rules. It is fully functional, but allows mutations. It also has an actually sound type system.
Since the original SICP has a permissive license, I've actually thought about doing something similar, but with a more modern functional language.
One of the reasons it was originally written for scheme is that scheme has a small core, simple syntax and can very easily be learned while reading SICP.
More importantly, the type of user that would get put off by using/learning scheme, is probably not going to make it through SICP. Learning just enough scheme is arguably the easiest part of going through SICP.
I think the decision on what language to use in teaching material should be made based on quality and ease use, not popularity of the language.
JavaScript lacks several features that make it apt to translate this book.
What is "accessible" in this context is purely a state and attitude of the intellect.
SICP doesn't try to be accessible, it's explicitely an engineering text book made for engineers. That's even the reason some people have criticized it[1] and wrote another book[2] with the same themes and goals but ditching the excessive math focus. Anyone who can understand SICP's exercises can understand Scheme.
[1] https://en.wikipedia.org/wiki/The_Structure_and_Interpretati...
[2] https://en.wikipedia.org/wiki/How_to_Design_Programs
that one isn't too surprising because "putting scheme in the browser" was quite literally what Eich set out to do
"As I’ve often said, and as others at Netscape can confirm, I was recruited to Netscape with the promise of “doing Scheme” in the browser. At least client engineering management including Tom Paquin, Michael Toy, and Rick Schell, along with some guy named Marc Andreessen, were convinced that Netscape should embed a programming language, in source form, in HTML. So it was hardly a case of me selling a “pointy-haired boss” — more the reverse.
Whether that language should be Scheme was an open question, but Scheme was the bait I went for in joining Netscape. Previously, at SGI, Nick Thompson had turned me on to SICP.
"https://brendaneich.com/2008/04/popularity/
That would be very nice.
Everybody's dealt with that one asshole* who overdosed on category theory and proceeds to write Haskell in Python for the next two years.
* It's me, I'm that asshole.
Guilty here too, just not in python.
In langs with proper TCO (like scheme and lua), recursion is a beautiful and practical way to solve problems.