There's kind of a reason why SICP was written in Scheme in mind and not a blub language...
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.
People talk up their language until they learn lisp then this happens: https://www.draketo.de/proj/py2guile/
> 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.
And of course, Lisps that include meta-object protocols (Flavours, Common Lisp again, &c.) deliver power, very elegantly, but for people unfamiliar with them, there is a learning curve to climb.
That is exactly the reason why Scheme was chosen for SICP.
“Lisp dialects strive for elegance.”
Elegance is not always synonymous with simplicity. For example, Smalltalk’s use of Class and Metaclass is very elegant, but most programmers encountering this for the first time would not call it “simple.”
After they got over the hump and grok how the two things work together to serve as the foundation for Smalltalk’s OOP and allow programmers to alter Smalltalk’s OOP... Then the elegance emerges.
I think elegance is a measure of the simplicity of a tool relative to the complexity of the problem domain, whereas simplicity feels like a more absolute measure.
This is the Lisp I manual:
http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Man...
Lisp is usually an academic language, which means research into type systems and type safety frequently takes place in it.
ACL2 is a theorum prover written in Common Lisp [0]. And not just a random project either, but something AMD, ARM, IBM, etc. have used.
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.
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...
"When we admit we know nothing, then we are free to think anything."
Which essay is that? I'd be interested in reading it.
Oh, are you the great decider who decrees what we can and can't use certain programming languages for?
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.
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.
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 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?
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].
Because it's widely used in the industry.
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.
I'm curious who's reading SICP who finds it difficult to grok in Scheme, or more useful in Javascript. What are you doing in the industry that familiar syntax is top priority?
I would think that other books, specific to Javascript, would be a much better fit for people writing pretty much anything in Javascript.
> What are you doing in the industry that familiar syntax is top priority?
The question is more like: "Do I want to invest time into learning a new language just to read and comprehend new and interesting concepts?".
With endless knowledge out there, I usually gravitate towards the least friction.
> I would think that other books, specific to Javascript, would be a much better fit for people writing pretty much anything in Javascript.
I don't think of this book as the ultimate JavaScript book. It just uses it as the most accessible language out there, and that matters a lot imho.
Well, it would certainly help to change the examples to proper SI units.
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.
The scoping for "JavaScript, The Good Parts" is exactly the same scoping as Scheme. You can write expressive programs without ever using var, let, or const just using binding to named function arguments, which is very close to thinking in lambdas.
Of course, that style of JavaScript isn't what most people think of, and without macros, you can't build fuller-featured syntax on top of "The Good Parts."
And that's the real problem with treating JS as "a kind of Lisp." It's true that you can program in a certain minimal SICP-like style in JS, but if you have to write a Babel plugin to implement a new feature made out of closures and argument bindings... Then you really aren't programming in "a kind of Lisp" any more.
"to be fair, it does have some stuff in common. So maybe it’s a fair comparison? I guess the real way to tell would be to compare Scheme to some other languages. The big feature that everyone harps on is closures. Maybe just having closures means you’re basically Scheme.
If that’s true, then C#, Lua, D, Erlang, Haskell, PHP, Scala, Go, Objective-C, Python, Ruby, and Smalltalk are basically Scheme. In other words, if JavaScript is Scheme by that criteria, then every language is Scheme, which of course means none of them are."
Just to add, Perl has closures too:
https://www.perlmonks.org/?node_id=690
and to quote again:
"This is why the “JS = Scheme” meme drives me crazy: it makes us dumber. It’s a thought-terminating cliché. It carries negative informational content and makes people actually know less about languages than they did before."
My personal "What makes Scheme, Scheme" predates current Scheme implementations by decades. But I go with, "There are five special forms that are essentially axioms of the language, and everything else is made by combining those forms with each other."
The deep elegance of building a rich language on top of a handful of axiomatic features is what makes Scheme feel Scheme-ish to me.
I understand that Scheme has evolved since everything was implemented in terms of the special forms, but still...
- 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.