Live data from Hacker News

Structure and Interpretation of Computer Programs – JavaScript Adaptation

sicp.comp.nus.edu.sg

91–100 of 188 posts

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#91
post #52

Earlier quoted context omitted.

There is a simple explanation of course. You are not the intended audience. Ditto for the blockbusters you mentioned.

I'm with you. As much as I find most remakes terrible, to say others should not enjoy them is a form of gatekeeping. If people who would otherwise not enjoy any of the insights to be gained from SICP do get into it through this version, great.

I think the target audience is people who don't like to learn, and I find that worrying in the context of programming.

It's not like code examples in a book are intentionally obfuscated. They are also not some atrocious pile of spaghetti code you may have to put up with at work. I think any foreign PL programming book is a joy to read next to working as a software maintainer. And while the original book aspires to be a general programming book (the title!), I think we should allow Scheme programmers to have their poster child book/success story.

I also have a modest, optimistic interest in Rust, and tinker with it from time to time, but I don't think everything should be converted to Rust. The language team is open about sacrificing readability for other values, like execution speed, memory safety, concurrency, correctness. But with Rust at least the occasional rewriting hype can be justified as "testing the limits of the new language" and "optimizing" - because the language is pretty damn efficient. With Javascript it's... what? Some kind of idealism about running all programs in a browser sandbox? And isn't it a bit ironic that an idealistic book about software architecture is rewritten in an ad-hoc language, with a minefield of bad features you're not supposed to use but you will encounter at work?

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#92
post #78

Earlier quoted context omitted.

Typical dramatic Hacker News user. JS is a great language and enjoyed by millions of developers.

> JS is a great language literally no one believes this

It's certainly been pleasant so far as I've been learning 2d game development!

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#93
post #78

Earlier quoted context omitted.

Typical dramatic Hacker News user. JS is a great language and enjoyed by millions of developers.

> JS is a great language literally no one believes this

I love ES5. The language has gone downhill though.

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#94
post #35

Earlier quoted context omitted.

Simple question: do you know enough lisp to write a self hosting interpreter in it? People talk up their language until they learn lisp then this happens: https://www.draketo.de/proj/py2guile/

Can lisps place arbitrary code in types and formally verify complex properties of stateful systems--all in the same language? Doubt it. Lisp isn't the epitome of power.

Checkout Little Typer and Clojure.Spec.

> Lisp isn't the epitome of power.

Lisp is the epitome of simplicity. If the foundations based on simplicity you can do very powerful things.

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#95
post #87

Earlier quoted context omitted.

> Rather, you are going to use the things you learned through SICP on a job. That's my point. Is that bad somehow that it's written in a familiar and accessible language for the majority? One can sharpen its knowledge without the barrier to understand a new language and syntax.

If learning a new language and syntax is a barrier, you will not be able to follow SICP anyway, since it includes developing multiple languages in various paradigms.

Oh, okay. I thought I was just lazy, not dumb. My bad.

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#96
post #3

There's kind of a reason why SICP was written in Scheme in mind and not a blub language...

Of course SICP is brilliant in Scheme. But hello? There is no such thing as a “blub language.” Your comment misrepresents the entire point of the original PG essay! The point is that givens some fictional language called “Blub” for the sake of the essay, some programmers believe that their language has everything that could possibly be useful, productive, expressive, &c. But PG’s contention that languages exist on a…

Considering everything is being shoved into the web paradigm and written in JS even when it's wildly wrong for the job, I think it fits the description perfectly.

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#97

Earlier quoted context omitted.

Yes, it's such a great language that `{} + []` is a valid program.

Do you find yourself accidentally doing that often? A few of the things from the "Wat" video fall into that category. "Things no one would have ever thought to try, yet a dynamic language will fully allow". If you want to point out valid concerns with JS, the double-equal implicit coercion is a far more frightening "gotcha".

Few people do that outside of code obfuscation contests, but the point is JS has heaps of gotchas like that, each waiting to bite you. How about:

x = 5;

(no var declaration). Extremely easy to do by accident. Lots of these will be left for backwards compatibility. In JS errors often go silent and I developed a strong dislike for any language that does that, including Vimscript and Lua (and I do like Vim).

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#98
post #97

Earlier quoted context omitted.

Do you find yourself accidentally doing that often? A few of the things from the "Wat" video fall into that category. "Things no one would have ever thought to try, yet a dynamic language will fully allow". If you want to point out valid concerns with JS, the double-equal implicit coercion is a far more frightening "gotcha".

Few people do that outside of code obfuscation contests, but the point is JS has heaps of gotchas like that, each waiting to bite you. How about: x = 5; (no var declaration). Extremely easy to do by accident. Lots of these will be left for backwards compatibility. In JS errors often go silent and I developed a strong dislike for any language that does that, including Vimscript and Lua (and I do like Vim).

Problems like this can be easily caught by linters like eslint or standardjs.

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#99
post #78

Earlier quoted context omitted.

Typical dramatic Hacker News user. JS is a great language and enjoyed by millions of developers.

> JS is a great language literally no one believes this

I like JS. I use JS daily. JS is part of the workflow for nearly everyone I know who works with code. For me, ES6 is fantastic to use. Some of the better books on JS [I'm thinking specifically of Haverbeke's "Eloquent Javascript"] are general computing classics in their own right.

I used to be a snob about JS, due to the fact that in the 90s / early 2000s, it had major shortcomings and produced a lot of slow, crashy web pages. But when I learned modern JS, I realized that it is now a fully mature language equal to any other, and easily used in a huge variety of contexts [thanks in no small part to Node]

Re: Structure and Interpretation of Computer Programs – JavaScript Adaptation

#100

Earlier quoted context omitted.

Yes, it's such a great language that `{} + []` is a valid program.

Do you find yourself accidentally doing that often? A few of the things from the "Wat" video fall into that category. "Things no one would have ever thought to try, yet a dynamic language will fully allow". If you want to point out valid concerns with JS, the double-equal implicit coercion is a far more frightening "gotcha".

Not lexically, no, but dynamically, sure, all the time. JS lets me receive an arbitrary value in a variable `foo`, and "add" it to another arbitrary value in a variable `bar`, without having any opportunity to specify what semantics I mean by "add." Fixing the semantics of the operation is the whole point of specifying it!

Personally, I favor languages that go "almost too far" in the opposite direction, e.g. Elixir. In Elixir, operator[] (a.k.a. the Access protocol) is generic across several types, but the semantics are very strictly constrained; not only does the access have to "mean" getting some kind of element from a container, but it's also only defined where it has a fixed O(1) time-complexity.

This sort of design being conventional in Elixir, means that you can usually predict, just from the lexical environment (a.k.a. "the code on the screen") what the runtime behavior will be of said code—which includes being able to "read off" a time/space complexity for the code—without needing to check how each ADT involved has implemented its generics, let alone having to check for implicit type coercions.

Post reply on HN