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 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.
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.
If you really want a blog post to describe how JavaScript is eating the world, I suggest it isn’t “Beating the Averages” by Paul Graham.
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.
"Do you know enough lisp to write a self hosting interpreter in it?"
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.
Thank you for writing this up Reginald. I appreciate seeing the journey that someone such as yourself has taken in learning these ideas, and the perspective that it has imparted along the way.
"When we admit we know nothing, then we are free to think anything."
As a C developer: while I could probably do that given a few months, I've somehow managed 25 years without needing to interpret C? It's cool and all, but in terms of product requirements tends not to be high on the list?
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 have written interpreters in python and god help me lex and yacc. The point is that writing one in scheme is so easy you almost think that the language was designed with that in mind, it was in case the sarcasm doesn't get through the text.
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.
No. You can write a compiler for any language in Scheme, but it's disingenuous to say that Scheme has that language's features. There are many languages with way more powerful features than Scheme if you're comparing type systems.
Lisp in general is not the epitome of simplicity. Lisp-2s like Common Lisp add some cognitive load for those used to simpler languages (although Lisp-2s have their advantages).
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.
You're mistaking Lisp for a programming language. Which Lisp is not. Lisp is an idea (or rather a set of ideas), based on which different PLs can be implemented.
That's fine as long as we have both a canonical version written in Scheme and good "translations" to other languages---including "blub". Good translations should not diminish the value of the canonical SICP. It can be argued that this particular translation is not good; I guess not, as SICP JS's version of metacircular interpreter does interpret (a subset of) JavaScript! The cost is of course this complex definition [1] of which language metacircular interpreter is written in and implements.
Were you going to let the rest of us mere mortals in on the reason?
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.
A long essay could be written about that. A few quick things. There's Scheme's simple syntax, which doesn't get in the way of what the book is actually teaching. The fact that, of the mainstream programming languages, Javascript is the most crufty and full of gotchas, with all kinds of weird, unexpected behaviours even experienced developers can't always keep track of, many caused by bugs in the first version. Javascript's tendency to fail quietly when other languages would shoot out error messages makes it an awful language to experiment and play around in. Javascript Stockholm Syndrome. Decades of tradition. The entire last section of the book's intimate relationship with Scheme.
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?
> Were you going to let the rest of us mere mortals in on the reason?
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.
Why? Why does a textbook about fundamental principles need to be 'adapted' to technology currently in use in industry?
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].
In America, at least, that's still not what we use in industry. So the top response to my comment is a proposal to make this classic American book even less practical here!
Why does that matter? You are not going to get paid to work through the SICP exercises on a job. Rather, you are going to use the things you learned through SICP on a job. Like deciding when JavaScript is the right tool and when it isn't.
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.
I don't know anyone who first read this book outside of college. Its concepts aren't exactly directly applicable to typical work. If you're given the task to build something in Javascript for work, it's probably not a metacircular evaluator or a register machine simulator, or even a closure-based object system.
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.
That might change now. Someone might pick this up after completing a few JavaScript chapters in a JS specific book. I haven't read the book yet so I can't comment on the concepts, but based on your list it's a great resource for any newbie programmer, especially to those who are self taught like me.
> 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.
It is a great book for self-taught programmers. But the book is about programming language concepts and paradigms, and explores these though the development of multiple languages, interpreters and compilers. It is fundamental to the book that you have to learn a bunch of small languages. Scheme just makes it really easy to implement new languages.
SICP is about exploring various programming concepts and paradigms like functional, object-oriented, constraint-based, lazy evaluation and so on. Scheme happens to be the perfect vehicle for this, since its support for code-as-data makes it much easier to implement new sub-languages and evaluation forms.
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.
If you’ve read SICP and saw how the abstractions were slowly layered on top of each other which scheme is amazing for with its simplicity - no I don’t think a weird prototypal language like JS is sufficiently like scheme enough to communicate the beauty of programming like SICP does.
“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.”
It's a wonderful read, but having used JS since well before it attained its current status as a combination floor wax and dessert topping...
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."
"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."
Hey, I'm not claiming that JS is Scheme, or that Scheme is defined by closures :-)
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...
This rebuttal isn't worth much, as it was written back when js was a much different language, some 2 years before let/const, promises and probably half of what modern js developers use day-to-day. It is also way too snarky to take it seriously. Not gonna lie, it was a fun read though.
I wasn't trying to flamewar, but my post was kind of snarky and I should have expanded upon it. It's just that when I see something like "SICP in teh script" I can't but question the value of that, since much of the elegance and staying power of SICP is inseparable from the fact that it was designed for a homoiconic language with simple syntax and easy metacircularity.
Every single language in the industrial use today is pretty much influenced by Lisp. For that reason alone every self-respected programmer should get familiar with a Lisp - Racket, Clojure, Fennel, CL, etc.
Is that sarcasm? I can't even tell any more. Assuming it's not:
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.
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.