At the risk of forfeiting my nerd card: I first read SICP in my 40s and the big barrier to entry for me wasn’t Scheme, but rather the fact that a lot of the examples and exercises are, for lack of a better word, very math-y. I hadn’t had a reason to use things like calculus for over two decades, so I spent easily ten times as long refreshing my memory on the problem domains as I spent thinking about the programming concepts the book was trying to convey. Or rather, I did that toward the beginning of the book; later on it got easier once it was able to focus on ASTs and such.
However, those examples are probably completely fine for the book’s target audience of MIT students, who will have all those topics fresh in their heads.
My school is holding the first session of our fundamentals of programming course in years, and none of the previous instructors left notes for the course so I decided to reboot it using this text instead of the Python one that was used before. I have enjoyed using Python to teach in the past, and I use JavaScript in other courses for practical reasons, but since the course is completely dedicated to programming, without some sort of career-based outcome at the end, I decided to give this book a shot. It’s a one-semester high-school course, so I will be curious to see how far into the book we are able to make it.
You’re definitely not the only one. I’m not sure if I even have a nerd card, but the math in SICP was too much for me. I never took calculus—I never even took trig!—so I had nothing to fall back on. The Little Schemer worked much better for me, though obviously it’s not SICP.
I had a similar experience but it was the Scheme plus the “math-y” stuff. The new edition interests me because JavaScript was the first language (for good or ill) I reacted with in any “real” way and I wonder, with SICP’s examples and such now being in the more approachable (for me) JavaScript, how approaching the book now will turn out even with its “math-y” parts (I assume) intact.
I believe a lot of people, especially intermediate/experienced programmers, don’t like tutorial books on “how to learn X language”. I myself don’t like them because I find them to be too slowly paced. I prefer to explore a specific concept or idea by writing in that language. So Structure and Interpretation of Computer Programs (SICP) was a vehicle for me to learn Scheme. I enjoyed working through the problems and exploring the ideas presented by the book. Especially the writing about data representation, which stuck with me long afterward. And as a side effect, I learned quite a lot about how to solve problems in Scheme. Which is what I wanted to get when I picked up the book in the first place.
I hope this edition does the same thing, for learners who want to explore JavaScript. There are a million reasons to learn JavaScript, as there are probably more than a billion JavaScript interpreters in the world, in people’s pockets and desktop computers. I expect that one can pick up SICP Javascript Edition to learn that language, and come away struck by the other key concepts the book has to offer.
+1. I’ve been bouncing off of LISP’s [REDACTED] syntax since 1980 and have no desire to spend a bunch of time trying to read or write it, but SICP is an important book that I’d like to read.
JS is by no means my favorite language either, but I’ve used it before, and it’s fairly readable. Its approachability and popularity should increase the audience for the book, which can’t be a bad thing.
It’s funny because I was reading through the version cndreisbach posted above, and it looks so strange to me without the S-expressions. Like, in my head the underlying assumption is that everything is S-expressions and I work in various syntactic sugars over them.
If it were sugary enough I wouldn’t mind, but I haven’t seen any LISPs that allow a more, uh, human-oriented syntax. (For example, something on the level of Smalltalk syntax would be nice.)
There is OpenDylan which is lispy but with a more algol-adjacent syntax.
You could do a more natural language version of Lisp with Racket. It has all the tools at your disposal there from the start. You might enjoy Beautiful Racket.
I mean when I’m writing Haskell or Prolog or C#, they feel like sugar. In many cases I prefer sugar. It’s nice to read and helps my visual system find errors.
We’re talking about a language designed in ten days to enable a monkey to
dance in a webpage when you hovered over it with a mouse. A language
that warranted a book with a title like JavaScript: the Good Parts.
A language where “3” * “3” is 9 and “3” + “3” is “33”.
Though arguably JS is closer to Lisp than Python is. Python, with its
statement-orientation, pitiful lambda, lack of TCO, and bizarre
idea of scope was chosen to succeed Scheme as the teaching language in
the MIT course.
The language is type checked, try it out using cndreisbach’s link. For example, your multiplication of strings results in:
Line 1: Expected number on left hand side of operation, got string.
Hints:
Line 1: A type mismatch was detected in the binary expression:
"3" * "3"
The binary operator (*) expected two operands with types:
number * number
but instead it received two operands of types:
string * string
But the + is still working for concatenation of strings.
JS from Netscape days is not the JS of today and people could use some break. The language grown. And yes, lots of the old gotchas are still there, but that is for a good reason. Either they’re needed to not break the web because you don’t want all old content suddenly breaking, or they’re misunderstood and part of some standard that people complaining are not aware of.
In your example, the plus sign is the concatenation operator between strings. That is the correct behaviour. The multiplication example works because of automatic type coercion. You don’t want the string concatenation operator to attempt to do integer coercion and sum the strings. Today, we might not want that kind of automatic coercion, but there are sites using this and changing it would break the web.
It is better to have a working and retrocompatible web than break things for language purity and elegance.
I’d argue a language with so much cruft that is strongly bound to backwards-compatibility is not the most suitable language for teaching fundamental concepts. Purity and elegance is exactly what you need when teaching fundamentals, so that the awkwardness does not get in the way of the exposition.
Speaking as a teacher, I think that teachers like the purity and elegance (and I do) because it makes it easy to teach, not because it makes learning easy or durable. So when students come up with weird ways to use JavaScript, it slows me down, but it also allows me to present a realistic picture of the way actual work in the field is probably going to be.
There has been an ongoing debate in my faith over the tension between God’s sovereignty and human will, with competing systems proposed to defend one or the other. Both of them break down in different ways on close inspection because they’re an effort to impose a kind of order on a system that seems disorderly.
So I suppose in some ways I feel the same way about all the arguments about language purity or OOP vs FP. They’re systems imposed on top of the reality of programming, and none of them will perfectly fit it. I’d rather be flexible on that end, even if it makes teaching more complicated, since it means more of what I teach will probably actually be useful beyond the “clean room” environment of a CS course.
When I worked construction, it really surprised me how complex some of the math was that my coworkers were scribbling on scraps of lumber while we worked to solve different problems. But they were showing me how to do this with a drill in the other hand. Sometimes I like to think of this as an analogy for how teaching computer science. You need theory and you need to get actual work done. Languages like JavaScript can accomplish this, however inelegantly, and it’s one of the most ubiquitous languages on the planet now.
But yeah, sometimes I scream into a pillow when I see how my students have used it and gotten away with it.
BASIC was used for decades to teach programming to people who had never even thought about how to write a program. It was everywhere; in those days nearly every computer came with a BASIC interpreter either in ROM or the OS or both.
Today every computer you buy has a JS interpreter right there, just hidden from view. Even if it’s not the cleanest language, it’s ubiquity makes it ideal for learning how to program.
Yes, and Dijkstra had some less than nice things to say about it, too. I seem to recall a quote about teachBASIC causing brain damage. If he were alive and posting on here today, he’d probably get flagged for trolling.
Lots of languages do implicit type conversions. I may not like it, but I can live with it. Lua does it. Perl, the first language I really mastered, does it. So does PHP. But all 3 have a dedicated string concatenation operator, instead of overloading +. Overloading + isn’t by itself a bad thing. Python does it, and it’s fine there. But combine type conversions with operator overloading, and the language is unsound.
Makes sense, the only reason to use Scheme is for the section on writing the interpreter, but it made the rest of the book less accessible. Curious how they reworked things. Glad it isn’t Python.
I think this paragraph from the new foreword is relevant:
While JavaScript, like Java, was originally designed with objects and methods in mind, it also incorporated first-class functions from the beginning, and it is not difficult to use its objects to define a universal data structure. As a result, JavaScript is not as distant from Lisp as you would think, and as this edition of Structure and Interpretation of Computer Programs demonstrates, it is a good alternate framework for presenting the key ideas. SICP was never about a programming language; it presents powerful, general ideas for program organization that ought to be useful in any language.
TypeScript doesn’t fix any fundamentally wrong issues with JS (which are the worst of it from a CS rather than SE perspective); it just fixes the overall experience of writing, maintaining, and using others’ TS/JS code. That is to say, I don’t think it would have been a qualitative improvement over JS in this case, only a quantitative one.
From the list of mainstream languages, there is really not so many good candidares:
Java: class-obsessed, hard to construct functions.
Python: defs are statements, lambdas are are expressions. This is a book about CS, not programming language semantics.
C/C++: Not easy to construct anonymous functions, and then pointers.
C#: see Java, but with more lock-in.
PHP: you serious? Javascript is a perfectly designed programming language in comparison to PHP.
So at the end of the day, JS is an acceptable functional language. So why not TS? Well this is a book on general CS. If you want to talk about types, there are books way better suited for it (and in these books they laugh at TS from their dependent-types ivory towers).
If we are composing functions, what’s the type of a function that accepts two functions as parameters? Well, now we are going to waste 20 pages explaining types, TS syntax, gotchas of TS syntax, type parameters, gotchas of type parameters in TS, and so on.
Effectively, TS adds little to what the book teaches, while adding significant overhead.
I’m curious about this, because the description still mentions Scheme and writing an evaluator. The new chapter on parsing sounds nice, and makes me wonder if the evaluator is going to be for JS instead of Scheme.
In any case I might pick this up. A refresh of a favorite book is always an interesting read at least.
At the risk of forfeiting my nerd card: I first read SICP in my 40s and the big barrier to entry for me wasn’t Scheme, but rather the fact that a lot of the examples and exercises are, for lack of a better word, very math-y. I hadn’t had a reason to use things like calculus for over two decades, so I spent easily ten times as long refreshing my memory on the problem domains as I spent thinking about the programming concepts the book was trying to convey. Or rather, I did that toward the beginning of the book; later on it got easier once it was able to focus on ASTs and such.
However, those examples are probably completely fine for the book’s target audience of MIT students, who will have all those topics fresh in their heads.
There is always How To Design Programs which has been described as SICP but for humanities.
My school is holding the first session of our fundamentals of programming course in years, and none of the previous instructors left notes for the course so I decided to reboot it using this text instead of the Python one that was used before. I have enjoyed using Python to teach in the past, and I use JavaScript in other courses for practical reasons, but since the course is completely dedicated to programming, without some sort of career-based outcome at the end, I decided to give this book a shot. It’s a one-semester high-school course, so I will be curious to see how far into the book we are able to make it.
This book is excellent. I much prefer it to SICP for this very reason.
You’re definitely not the only one. I’m not sure if I even have a nerd card, but the math in SICP was too much for me. I never took calculus—I never even took trig!—so I had nothing to fall back on. The Little Schemer worked much better for me, though obviously it’s not SICP.
I had a similar experience but it was the Scheme plus the “math-y” stuff. The new edition interests me because JavaScript was the first language (for good or ill) I reacted with in any “real” way and I wonder, with SICP’s examples and such now being in the more approachable (for me) JavaScript, how approaching the book now will turn out even with its “math-y” parts (I assume) intact.
If you want to see it now, it seems to be online at https://sourceacademy.org/sicpjs/index
I’m very happy to see this book come out.
I believe a lot of people, especially intermediate/experienced programmers, don’t like tutorial books on “how to learn X language”. I myself don’t like them because I find them to be too slowly paced. I prefer to explore a specific concept or idea by writing in that language. So Structure and Interpretation of Computer Programs (SICP) was a vehicle for me to learn Scheme. I enjoyed working through the problems and exploring the ideas presented by the book. Especially the writing about data representation, which stuck with me long afterward. And as a side effect, I learned quite a lot about how to solve problems in Scheme. Which is what I wanted to get when I picked up the book in the first place.
I hope this edition does the same thing, for learners who want to explore JavaScript. There are a million reasons to learn JavaScript, as there are probably more than a billion JavaScript interpreters in the world, in people’s pockets and desktop computers. I expect that one can pick up SICP Javascript Edition to learn that language, and come away struck by the other key concepts the book has to offer.
+1. I’ve been bouncing off of LISP’s [REDACTED] syntax since 1980 and have no desire to spend a bunch of time trying to read or write it, but SICP is an important book that I’d like to read.
JS is by no means my favorite language either, but I’ve used it before, and it’s fairly readable. Its approachability and popularity should increase the audience for the book, which can’t be a bad thing.
It’s funny because I was reading through the version cndreisbach posted above, and it looks so strange to me without the S-expressions. Like, in my head the underlying assumption is that everything is S-expressions and I work in various syntactic sugars over them.
If it were sugary enough I wouldn’t mind, but I haven’t seen any LISPs that allow a more, uh, human-oriented syntax. (For example, something on the level of Smalltalk syntax would be nice.)
There is OpenDylan which is lispy but with a more algol-adjacent syntax.
You could do a more natural language version of Lisp with Racket. It has all the tools at your disposal there from the start. You might enjoy Beautiful Racket.
I’ve heard Racket has good tools for building new syntaxes (syntaces?) Maybe I’ll try it out.
For me, a lifelong beginner, I find LISPs far simpler to understand and program than most other languages.
I mean when I’m writing Haskell or Prolog or C#, they feel like sugar. In many cases I prefer sugar. It’s nice to read and helps my visual system find errors.
[Comment removed by author]
We’re talking about a language designed in ten days to enable a monkey to dance in a webpage when you hovered over it with a mouse. A language that warranted a book with a title like JavaScript: the Good Parts. A language where “3” * “3” is 9 and “3” + “3” is “33”.
Though arguably JS is closer to Lisp than Python is. Python, with its statement-orientation, pitiful lambda, lack of TCO, and bizarre idea of scope was chosen to succeed Scheme as the teaching language in the MIT course.
Designed in 10 days by a lisp hacker.
That … is debatable. Designed by someone who knew enough jargon to sound like a lisp hacker, at least.
The language is type checked, try it out using cndreisbach’s link. For example, your multiplication of strings results in:
But the
+is still working for concatenation of strings.JS from Netscape days is not the JS of today and people could use some break. The language grown. And yes, lots of the old gotchas are still there, but that is for a good reason. Either they’re needed to not break the web because you don’t want all old content suddenly breaking, or they’re misunderstood and part of some standard that people complaining are not aware of.
In your example, the plus sign is the concatenation operator between strings. That is the correct behaviour. The multiplication example works because of automatic type coercion. You don’t want the string concatenation operator to attempt to do integer coercion and sum the strings. Today, we might not want that kind of automatic coercion, but there are sites using this and changing it would break the web.
It is better to have a working and retrocompatible web than break things for language purity and elegance.
I’d argue a language with so much cruft that is strongly bound to backwards-compatibility is not the most suitable language for teaching fundamental concepts. Purity and elegance is exactly what you need when teaching fundamentals, so that the awkwardness does not get in the way of the exposition.
Speaking as a teacher, I think that teachers like the purity and elegance (and I do) because it makes it easy to teach, not because it makes learning easy or durable. So when students come up with weird ways to use JavaScript, it slows me down, but it also allows me to present a realistic picture of the way actual work in the field is probably going to be.
There has been an ongoing debate in my faith over the tension between God’s sovereignty and human will, with competing systems proposed to defend one or the other. Both of them break down in different ways on close inspection because they’re an effort to impose a kind of order on a system that seems disorderly.
So I suppose in some ways I feel the same way about all the arguments about language purity or OOP vs FP. They’re systems imposed on top of the reality of programming, and none of them will perfectly fit it. I’d rather be flexible on that end, even if it makes teaching more complicated, since it means more of what I teach will probably actually be useful beyond the “clean room” environment of a CS course.
When I worked construction, it really surprised me how complex some of the math was that my coworkers were scribbling on scraps of lumber while we worked to solve different problems. But they were showing me how to do this with a drill in the other hand. Sometimes I like to think of this as an analogy for how teaching computer science. You need theory and you need to get actual work done. Languages like JavaScript can accomplish this, however inelegantly, and it’s one of the most ubiquitous languages on the planet now.
But yeah, sometimes I scream into a pillow when I see how my students have used it and gotten away with it.
BASIC was used for decades to teach programming to people who had never even thought about how to write a program. It was everywhere; in those days nearly every computer came with a BASIC interpreter either in ROM or the OS or both.
Today every computer you buy has a JS interpreter right there, just hidden from view. Even if it’s not the cleanest language, it’s ubiquity makes it ideal for learning how to program.
Yes, and Dijkstra had some less than nice things to say about it, too. I seem to recall a quote about teachBASIC causing brain damage. If he were alive and posting on here today, he’d probably get flagged for trolling.
Lots of languages do implicit type conversions. I may not like it, but I can live with it. Lua does it. Perl, the first language I really mastered, does it. So does PHP. But all 3 have a dedicated string concatenation operator, instead of overloading +. Overloading + isn’t by itself a bad thing. Python does it, and it’s fine there. But combine type conversions with operator overloading, and the language is unsound.
And yet C++ remains very popular…
Lots of unsound things are very popular: gambling, porn etc.
https://twitter.com/gvanrossum/status/1838308947
And “hello” ^ true is 1.
No, in this book:
Line 1: Operator '^' is not allowed.Their heavy use of the ternary operator in code snippets strikes me as very odd:
Of course JavaScript doesn’t have
cond(which is what the original book used) but what’s wrong with anifstatement?The problem is an if statement is a statement and they want an expression.
Why do they want an expression? The function would behave the same if written with early return or with an if-tree.
Makes sense, the only reason to use Scheme is for the section on writing the interpreter, but it made the rest of the book less accessible. Curious how they reworked things. Glad it isn’t Python.
[Comment removed by moderator pushcx: Dismissive scorn isn’t funny. If you don’t like it, click ‘hide’ or filter out the tag. ]
I think this paragraph from the new foreword is relevant:
There are also the usual pragmatic reasons to choose JavaScript as a teaching language.
Why would this be so terrible?
There’s a whole bunch of places to get surprised by Javascript:
https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f
Typescript would have been a better choice.
TypeScript doesn’t fix any fundamentally wrong issues with JS (which are the worst of it from a CS rather than SE perspective); it just fixes the overall experience of writing, maintaining, and using others’ TS/JS code. That is to say, I don’t think it would have been a qualitative improvement over JS in this case, only a quantitative one.
From the list of mainstream languages, there is really not so many good candidares:
Java: class-obsessed, hard to construct functions.
Python: defs are statements, lambdas are are expressions. This is a book about CS, not programming language semantics.
C/C++: Not easy to construct anonymous functions, and then pointers.
C#: see Java, but with more lock-in.
PHP: you serious? Javascript is a perfectly designed programming language in comparison to PHP.
So at the end of the day, JS is an acceptable functional language. So why not TS? Well this is a book on general CS. If you want to talk about types, there are books way better suited for it (and in these books they laugh at TS from their dependent-types ivory towers).
If we are composing functions, what’s the type of a function that accepts two functions as parameters? Well, now we are going to waste 20 pages explaining types, TS syntax, gotchas of TS syntax, type parameters, gotchas of type parameters in TS, and so on.
Effectively, TS adds little to what the book teaches, while adding significant overhead.
I’m curious about this, because the description still mentions Scheme and writing an evaluator. The new chapter on parsing sounds nice, and makes me wonder if the evaluator is going to be for JS instead of Scheme.
In any case I might pick this up. A refresh of a favorite book is always an interesting read at least.
Looks like the custom language in this book is Source. Implements a subset of JS syntax.