The translation is pretty direct, so the data structures are more idiomatic to Scheme than they are to JavaScript. I think that's OK.
I do wonder if it wouldn't be simpler to write a Scheme interpreter in JS (or take one of the undoubtedly existing ones) and make the book interactive with that.
This version feels more like something that has added value if you already know JS, not so much when you're learning JS
Totally agreed, which I think is a strength of SICP. I know historically it was for learning computer science, but I've gotten so much out of reading it, despite not being a newcomer to the field.
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 continuum of power (a gross oversimplification), and when a programmer believes that their “Blub” is as powerful as possible, they have closed their mind to more powerful/useful/expressive ideas.
But that’s as true of Scheme as it is of JS: If someone believes that LISP was the zenith of programming, and everything else since then has just been wankery, if they think we have nothing to learn from Haskell, or Julia, or Joy... Then for them, Scheme is Blub.
Blub is a mindset, not a language. Sure, some communities might be infested with Blub programmers, but nevertheless, languages themselves are not Blub.
Now, if someone says that SICP in JS proves that Scheme is no better than JS, well... That person has a Blub mindset. But teaching some of the same principles as SICP using JS is not in and of itself the Blub mindset.
Summary:
Blub is a mindset, not a language.
All languages are Blub languages if someone has the Blub mindset.
SICP in JS in-and-of-itself is not Blub.
JS in-and-of-itself is not Blub.
It’s actually “Worse is Better” by Richard Gabriel. I don’t think people are writing JavaScript tooling while saying that JS is just as powerful as Haskell or Lisp. What they’re saying is that its ubiquity is valuable and for their use case, ubiquity and network effects trump productivity and/or “power” however we might want to define them.
Oh, are you the great decider who decrees what we can and can't use certain programming languages for?
Which essay is that? I'd be interested in reading it.
People talk up their language until they learn lisp then this happens: https://www.draketo.de/proj/py2guile/
Short answer: Yes.
Long answer: No!
I learned Lisp and TI-Scheme in the early 80s, and somewhere around then we did some SICP-like stuff in undergrad CS.
I later came upon SICP and worked my way through it, having the usual "Aha!" moments. I thought I knew something about Lisp and Scheme at that point. I built some self-hosted interpreters using the following pattern:
1. Write an interpreter for a minimal subset of Scheme in a host language.
2. Write an interpreter for a more full-featured Scheme in the subset of Scheme.
At some point, I read LiSP [0], and I discovered that what I thought was enlightenment was actually but a hint of the delights to come. The entire book is about teaching programming through the device of building interpreters and compilers.
So my next pattern was something like:
1. Write a minimal Scheme interpreter in a host language.
2. Write a Scheme compiler in Scheme.
3. Bootstrap the compiler by running in in the interpreted Scheme.
4. Now you have a compiled Scheme implementation written in Scheme.
5. Build out more features.
And now, this approach is one of my go-to tools. A few years ago, I was playing with Turing Machines, and I used a "constructive proof" approach: If we want to demonstrate that a Turing machine with tape that has one end is just as powerful as a Turing Machine with a tape that stretches to infinity in both directions, write a compiler from one kind of Turing Machine to the other. And so on and so forth to prove that being able to write an infinite number of different symbols is no more powerful than writing 0s and 1s. Or that a multi-dimensional Langdon's Ant is no more powerful than a Turing Machine...
Interpreters and Compilers are very powerful tools for constructive reasoning.
But the point of the discussion around Scheme for this purpose is how easy it makes writing Interpreters and Compilers. On the one hand... Shrug... Since we can write interpreters and compilers in any language.
On the other hand, a tool that removes a lot of the accidental complexity in writing interpreters and compilers changes the way we think about writing interpreters and compilers, much as parsing text using a language built around pattern matching (like SNOBOL and its descendants) changes the way we think about parsing text.
So... We are probably in deep agreement about the value of SICP in Scheme, and the value of Lisp in general, not just as a language, but as a way of changing the way we approach solving problems.
And as for knowing enough... The truth is, every time I sit down with certain programming ideas, I learn more and realize that what I thought I knew was incomplete.
So in a very real sense, I suspect that no, I don't know nearly as much as I think I know.
---
[0]: Lisp in Small Pieces: https://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec/d...
Most languages are vulnerable to contexts where their particular gimmick doesn't work. You probably wouldn't write an interrupt handler in Lisp. You wouldn't write a bootloader in it either (although you might choose Forth, the other fanatic minimalist language). Conversely C gives you no runtime dynamism. Endless people try to write language-to-Verilog converters and are disappointed.
I think it's good to offer a version of SICP adapted to a language that's used today very prominently and is relevant to many current jobs in the industry.
The fact that this is a book about learning to program, not about maximizing your potential for jobs. It's a compsci book to learn to be a good programmer, not a book about synergizing industry trends to build your resume.
When SICP was written, most people still wrote in Assembly for most things but COBOL, ADA, and old-school FORTRAN were also popular. Part of the longevity of the book is its appropriate choice of language.
Would it be as enlightening to write a series of JS compilers in JS? Or are they writing Lisp compilers in JS? Doesn't that miss the entire point of the book?
Scheme (in contrast to Java etc) is special because of its very easy syntax and how it is evaluated. Since SICP is about syntax/structure and its evaluation/interpretation you should really stick to lisp.
> I think it's good to offer a version of SICP adapted to a language that's used today very prominently and is relevant to many current jobs in the industry.
I don't. Maybe this Javascript-Version is also a great book, but if you don't know scheme/lisp and wonder why scheme is a better choice for SICP I encourage you to read the original.
The Feynman Lectures uses an example of a screw jack with 10 threads per inch, and a 20" lever. Should we update this to a name brand screw jack with 8 or 16 threads per inch, and an 18" breaker bar, because those are common in industry today?
Be sure to extend the introduction of that chapter to include a history of this particular screw jack company, and who currently holds the trademark, and all the major companies that make screw jacks today, and typical uses of jacks, and how they're constructed [1].
Well, it would certainly help to change the examples to proper SI units.
Because it's widely used in the industry.
SICP is not about learning any particular language, it is about learning concepts which will make you understand JavaScript much better than anyone who only knows JavaScript.
If having to learn a new language like Scheme is an impediment to starting SICP, then you will not get past the first chapter anyway.
I'm just imagining someone taking the text of Crockford's talks on Javascript, removing all his clear description of the language features, and replacing it with highly opinionated non-technical terms of derision like this.
Though not instructive, it would be really fun to read.
And I write JS for a living.
although I don't necessarily agree that JavaScript is so minimal anymore.
About JavaScript features:
“Don’t tell me it’s got lexical scope, because JavaScript’s scoping is an abomination in the face of God. Guy Steele isn’t even dead and JS scope makes him pre-emptively roll in his not-yet-occupied grave. Likewise, claiming JS is homoiconic because you can eval strings of code is nonsense. If that’s the only criteria for homoiconicity, then C is too, since you can treat an array of bytes as code and jump to it.”
Wonderful.
- Wikipedia
Do you mean modern PHP? "The source code of the Viaweb editor was probably about 20-25% macros." So are you suggesting they should have started work by extending PHP with Lisp's macro system? Or just worked an order-of-magnitude faster to make up for not having one?
Or do you mean the actual PHP that was available when they started Viaweb? It's hard to imagine how Personal Home Page Tools 1.0 (not even called a 'programming language' at the time) would have been at all a reasonable alternative to ANSI Common Lisp. It was a few C files that could do basic variable substitution and output HTML tags to stdout. It couldn't do loops or if-statements, much less access files or databases.
and what does it matter anyway? the concepts are the same.
TIL: https://www.merriam-webster.com/words-at-play/what-does-crom...
[0] https://books.google.com/ngrams/graph?content=adaption%2Cada...
Is Javascript the new pseudocode? Honestly I'd rather be forced to learn a new language to understand a book than to read the book adapted to JS.
I think most of the comments below are entirely missing the point & thinking of this as JS hatred. Its more about...cultural degradation...Pedestrianization. sicp was holy grail. you looked up to it, you cherished it, it was something few people have partaken of & it was nice that way. then gradually that got diluted over time. berkeley did the python3 gig & that itself was icky but now this is a whole new low. sicp in js ?! jesus. what next ? are we going to sicp in qbasic ? why not a sicp do-over in Visual Basic so all them fogey 90s microsoft-for-life developers! developers! developers! on win95 code up COM DLL interpreters in Notepad++ ? where does the madness end ?
sicp & scheme. buttons & bows. mac & cheese. bread & butter. things that go together.
Now, sicp & js is...is..what is it ? mustard & jam ?
you know what would be real cool ? sicp in J !!! Now that's a marriage made in heaven. if i was a rich vc i would happily fork over a million for a sicp in J effort. the apl family has so much to offer! now that i recall, there was actually an effort called aprol http://www.cs.trinity.edu/~jhowland/aprol.paper.pdf
Anyway, how did you like the Pacino remake of Pippi Longstocking?
If people who would otherwise not enjoy any of the insights to be gained from SICP do get into it through this version, great.
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?
It adds zero value to any discussion. It's nothing more than a desperate attempt to gain some internet points.
It's a popular language and it has flaws, but that doesn't automatically make it worthy of the amount of hate it receives here. This type of discussion has more in common with /r/iamverysmart than it does with valuable discourse that HN used to be known for.
"Learn less edition", or "2D remake"
So please stop with that strawman.
I'm just glad JS is as good as it is, considering it didn't have to be good. It could have been even worse and still would have succeeded due to its monopoly.
When an intriguing movie - or book - comes out, it's often intriguing because it's quite different. When you convert it to a common language - or Hollywood - it becomes less different. Reading "Working With Legacy Code" forced me to absorb some C#, but it also allowed me an opportunity to compare it with Java, which I learned at university.
What I understand from this is that people didn't really value Python as a pseudocode language. It was just fashionable at the time. Now it's Javascript's time. I wonder what's going to be next? Golang has a chance.
This book will force you to absorb some pure, functional JavaScript. There's so much more to programming than "what language is it written in".
literally no one believes this
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]
While callbacks aren't a great way of doing continuation-passing, at least we can credit JS with making continuation-passing mainstream.
In combination with the fact that JS actually does work pretty well on both frontend and backend, it is a language I use semi-regularly for prototyping, given its flexibility. Granted, if I decide to make a "real" version of the project, I'll probably do it with a more functional language, but I think JS doesn't suck too bad.
Not everyone has the same brain as you. People enjoy things you don't understand.
Though I acknowledge its immense utility, I feel like JS always tends to go for "good enough" solutions rather than "best in class" solutions. That is its own kind of quality, but there's good reason to dislike JS for people who focus on those particular qualities in a language.
But I’ve never been in a job where we had a shot at building a world class system. Maybe I just have bad luck, but at each place I have worked the problems in the codebase are obvious and the impediments are institutional not technical.
There are hundreds of problems I could list in our current codebase that are causing slowdowns, bugs, etc. None of them are because of the programming language. They are places where someone put a square peg in a round hole, where someone copied a bug over and over because they assumed the existing code was correct, where someone used a fancy feature of the programming language that made the program worse.
None of that goes away if we start using Rust.
So yes, I agree with you if you are within striking distance of making a perfect application use a nearly perfect language.
I’ve just never been in that job. I’ve always been in the “let’s fix some of this low hanging fruit, and make sensible use of the tools we have” job.
1) Don't concatenate them in the first place
2) Use TypeScript
Pro-tip, if the world is going JS and you don't get it, it's probably you.
With JS (TypeScript) I can develop on every platform natively (React Native).
I can compile to native code. (AssemblyScript).
I'm not saying you can't do those things on other languages, but JS is becoming a powerhouse thanks to it's ecosystem.
Also, you see many other communities like Rust copying lessons learned from web developers (React/Redux/etc)
Imagine this kind of comment for any other language, C, Python, Ruby, Rust, Scheme whatever. It would be downvoted to death. And yet people still make & upvote these comments about JS despite JS being the most popular language, run on the most devices & having a massive community of people fixing its warts and modernizing JS.
There are still valid critiques of JS but they have nothing to do with Al Pacino or Bruce Willis. Please spare us, or if you want to criticize Javascript, learn something about Javascript in 2019 & criticize that.
nitpick: I personally prefer to use intermediate variables instead of nested function calls and ternary operator.
Everything is comprised of something.
Please, if you compose something many people could potentionally consume, at least dont be all esoteric and/or mystical about it. This is not a campfire, where everyone tells a story of fairies and shit. They maybe even more so eager to learn a typical umderlying layer/architecture.
