SICP: JavaScript Edition available for pre-order (opens in new tab)

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?

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.

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

    list("sequence",
         list(list("constant_declaration",
                   list("name", "size"), list("literal", 2)),
              list("binary_operator_combination", "*",
                   list("literal", 5), list("name", "size"))))

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?)

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.

But, they disappear and are mostly non-issues once you use the alternate system/language regularly for a while. Some I think you will come to see as benefits, sensible, or find that there are trivial workarounds.

One quick improvement. The more commonly used contemporary syntax in JS for something like your list.forEach example is: `list.forEach((item, i) => ...)` —writing out the full `function` keyword is indeed an eyesore :)

I don't think I'm correct here. However, be that as it may, in my code, when I moved that second variable before the loop and initialized it there with a let, the behavior somehow changed.

Why do you try to code JS without reading about the language? It's the only language where people consistently try this kind of thing.

> false != x

Referential equality operator is `!==` (which isn't so different from lisp where you have eq, eql, equal, string=, etc). Fun fact: Eich didn't have type coersion in the language at first. It was added at the insistence of developers (something he regrets, but Microsoft forced this to stay in the spec)

> function () { switch (WTF) { } }();

A lot of languages don't make switch statements into expressions. The fact that JS can do this via a function while most other popular languages cannot do it at all is a benefit if anything (there is a proposal to allow these to be expressions). More generally, prefer this

    let foo
    switch (abc) {
      case "blah":
        foo = 123
        break;
    }

It actually gets this from Java. Eich was told to make the language look like Java and he did.

> dict[key] = (dict[key] || 0) + 1;

Your code is potentially bad. `||` uses "falsey" values. If the key is zero, the left-hand side will return false forcing the right-hand side. Use `dict[key] ?? 0` instead as it will only return the right-hand side if the left side is `undefined` or `null`.

If it is a pure dictionary, you are using the wrong construct too. Use `Map` instead

    let dict = new Map()
    dict.set((dict.get(key) ?? 0) + 1)

You get a value rather than a reference. I believe the JIT can optimize this pattern. If you are really fixated on using a reference, store an object with a value instead so you can grab and keep an object reference.

> What is "function scope" and why even have something so idiotic?

In lisp, you'd use `(let ((foo 123)) (print foo))` to set an explicit scope. ES4 proposal had a let block which I think would have been a better idea than the current stuff. Function hoisting generally occurs in other languages one way or another, but is hidden from the user.

> for (let i = 0, j = 0; ....

Yep, this is one more reason why the correct fix was a let block with `let (i=0, j=0) for (; ...)` or 1et for (var i=0, j=0...`

> Appending together Lists has functional semantics, like Lisp:

Array.prototype.concat goes back to at least the ES3 spec as does Array.prototype.push. At the time, arrays were either implemented as hashtables or linked lists. My guess is that adding a single entry to the hashtable only occasionally caused a resize while concatenating N lists was almost guaranteed to do so. I think they decided that it was easier for implementors to just create a new reference.

Since ES5, most new array APIs have favored returning new lists for everything. I think there's a case for making new versions of those older APIs that behave immutably.

> if (foo.bar.indexOf[key] < 0) { code }

This could happen in any language with a methodNotFound handler. For what it's worth, `if (foo.bar.contains(key)) {code}` would be the better way of writing it. I think Typescript would also catch this (though I'm not 100% as I don't remember ever having made that particular mistake).

> Every damned object is a dictionary with properties you can access as strings with square bracket indexing, and that is always safe: it yields undefined if the property is not found.

Garbage In; Garbage Out. At least it handles that garbage in a safe manner. What more could you ask from a dynamic language?

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.

Guilty here too, just not in python.