At no point in my entire existence would I subject myself to JavaScript voluntarily ever again. I would write my own damn scheme environment and use that instead of this.
SICP in JavaScript
41–50 of 126 posts
Re: SICP in JavaScript
#42I might be wrong, but I feel like writing SCIP on JS is like "Sustainable Energy using Oil." Not quite the right analogy... JS isn't as bad as Oil. But you get the idea... Kinda... don't make sense?
from old an lisp neckbeard - python and js are both just lisps with off syntax. the both fit pretty well. the reader is a little funny.
Re: SICP in JavaScript
#43I think SICP and Scheme go together like horse and carriage, and neither Python, JavaScript or other "real world" languages should taint the insight gained from that wonderful pairing.
Because Scheme - being a LISP - has the same syntax for code and data, metalinguistic abstraction is facilitated. Nobody should have to read through boilerplate code to dig up the core message of SICP.
I took the Algorithmics I course based on SICP/Scheme in 1993 at the University of Erlangen, and although I never used Scheme or CommonLISP in production, it made me a better programmer regardless in what language. Thanks to Abelson and Sussman!
Re: SICP in JavaScript
#44Earlier quoted context omitted.
Unfortunately there is no if-expression in JS so sometimes it's awkward _not_ to use ternaries in multi-line statements - for instance, when writing in an expression only context like a string interpolation or JSX. It's also just annoying to not be able to assign conditionally without using it, instead of a more clear and readable if/else. It's one of the more annoying nits of the Algol legacy. Oh, but fully agreed,…
If you want the equivalent of if-expression in JS, I think it is much better to make a separate function with a number of returns. In this case the function is already there: function deriv(exp, variable) { if (is_number(exp)) { return 0; } if (is_variable(exp)) { if (is_same_variable(exp, variable)) { return 1; } else { return 0; } } if (is_sum(exp)) { return make_sum(deriv(addend(exp), variable), deriv(augend(exp),…
It's subjective, but seconded (switch statements are also great for this because they make fall-through logic more obvious).
I'll add a couple of things onto this: early returns are very helpful for me in avoiding nesting if statements (although that's less applicable in this specific example).
function op(cond) {
if (cond) {
//do something
}
}
function op (cond) {
if (!cond) { return; }
//do something
}
And don't be afraid to still use ternary operators non-nested. There's a sibling comment complaining about the nested if statement. If that really bothers you, you can still do:
if (is_variable(exp)) {
return is_same_variable(exp, variable) ? 1 : 0;
}Re: SICP in JavaScript
#45Earlier quoted context omitted.
Beat me to it :) It's not the biggest thing in the world, and I don't want to distract from the rest of the book, but this is a situation where writing a one or two line helper function: const _ = (cond, a, b) => cond ? a : b; would have made the code much more readable without much downside that I can see -- at least to my subjective opinion. Maybe I'm missing something. Edit: comment below correctly points out that…
JS is not lazily evaluated so that means `a` and `b` would both be evaluated regardless of the result of the cond expression. To make a proper version you have to complicate things by calling it like this: _(cond, () => a, () => b) And _ becomes: const _ = (cond, a, b) => cond? a(): b(); And it does matter in this case when looking at the last condition which signals an error (does not return an error value if I unde…
That is an excellent point, thanks for pointing that out.
I'm not sure it matters here, the error you're pointing out looks to be getting returned (unless I'm misunderstanding what the book intends the `error` function to do), and creating an Error in Javascript is fine, it doesn't break your program until it's actually thrown.
Edit: just looked at your comment again, and you're saying it does actually throw the error rather than returning it :) So double-corrected on my part :)
But your point stands regardless. There will be scenarios where what you're talking about matters -- JSX also follows this pattern of immediate evaluation and yeah, I see errors from that plenty of times. So it's good to mention.
Re: SICP in JavaScript
#46It seems like they have attempted to write scheme using JavaScript syntax to avoid having to make any significant changes to the non-code sections of the book. Here is an excerpt, it's not good: function deriv(exp, variable) { return is_number(exp) ? 0 : is_variable(exp) ? is_same_variable(exp, variable) ? 1 : 0 : is_sum(exp) ? make_sum(deriv(addend(exp), variable), deriv(augend(exp), variable)) : is_product(exp) ? m…
The tragedy of JS if blocks being statements not expressions is made explicit here
They are, but you use ?-: instead of if-else
Re: SICP in JavaScript
#47I think SICP and Scheme go together like horse and carriage, and neither Python, JavaScript or other "real world" languages should taint the insight gained from that wonderful pairing. Because Scheme - being a LISP - has the same syntax for code and data, metalinguistic abstraction is facilitated. Nobody should have to read through boilerplate code to dig up the core message of SICP. I took the Algorithmics I course…
I think SICP would be just peachy in Elixir, but I’m coming around to the notion that keeping functional programming for functional programmers is a form of professional neglect.
Functional core, imperative wrapper is one of the few sane ways to build a large (Conway’s Law afflicted) system, and too many of my peers never studies SICP in school. They don’t even know the damage they do, and as we’ve learned in many, many other circles, vilifying people does not get them to change. It’s a tool of last resort, and most often used to publicly label someone for ostracism, not help.
So excuse me, but y’all are crazy. We need SICP for JavaScript developers more than we need SICP for every functional language in the world, combined. And JavaScript is only one corner of the programming world.
Write functional code in a language that does not force you to write functional code. Take the training wheels off. Live in the real world.
Re: SICP in JavaScript
#48Earlier quoted context omitted.
Unfortunately there is no if-expression in JS so sometimes it's awkward _not_ to use ternaries in multi-line statements - for instance, when writing in an expression only context like a string interpolation or JSX. It's also just annoying to not be able to assign conditionally without using it, instead of a more clear and readable if/else. It's one of the more annoying nits of the Algol legacy. Oh, but fully agreed,…
If you want the equivalent of if-expression in JS, I think it is much better to make a separate function with a number of returns. In this case the function is already there: function deriv(exp, variable) { if (is_number(exp)) { return 0; } if (is_variable(exp)) { if (is_same_variable(exp, variable)) { return 1; } else { return 0; } } if (is_sum(exp)) { return make_sum(deriv(addend(exp), variable), deriv(augend(exp),…
if (is_same_variable(exp, variable)) {
return 1;
} else {
return 0;
}
return +is_same_variable(exp, variable)Re: SICP in JavaScript
#49I think SICP and Scheme go together like horse and carriage, and neither Python, JavaScript or other "real world" languages should taint the insight gained from that wonderful pairing. Because Scheme - being a LISP - has the same syntax for code and data, metalinguistic abstraction is facilitated. Nobody should have to read through boilerplate code to dig up the core message of SICP. I took the Algorithmics I course…
In most implementations neither Python nor JS (except perhaps partially in Safari) is up to the task of even running the code of SICP properly, due to not having things like TCO.
So the code for versions of the book written using those languages would need to be restructured, losing a big chunk of elegance and possibly destroying the actual lessons about how to express oneself as a computer programmer.