Jsonnet – A data templating language

As a person who has done every exercise in SICP, that argument is total bullshit.

Let's go through the list of things that the author says Javascript doesn't have:

2. Lexical block scope

JS has lexical function scope, so it would trivial to convert a "lexical javascript" to a "function lexical javascript." I think it's unfortunate that JS doesn't have lexical block scope, but it's trivial to implement through nested function definitions, so I don't think it's a real problem.

3. TCO

This isn't a feature of a language, it's the feature of a compiler. It just so happens that the Scheme spec requires the compiler to have TCO. But if the Scheme spec didn't mention this, would it make a Scheme something different?

4. Continuations

Continuations are very rare in Scheme, or any language for that matter. I think someone would be hard-pressed to argue that it's fundamental to Scheme.

6. S-expressions

There are many extensions to JavaScript, (JSGEN in Allegro, and various other libraries in SBCL), that allows one to write Javascript in S-expression syntax. So maybe while Javascript doesn't use S-expressions, one can very trivially transpile S-exp JS to normal JS.

8. Macros (he probably should have said hygenic macros)

It's pretty easy to implement a hygenic macro system on top of Javascript. In fact, people have already done so, one example is sweet.js.

9. Distaste for mutation

I'm not sure that distaste for something can be part of a language spec. But it's a non-argument: if all JS programmers suddenly had a "distaste for mutation" would it be anymore or less like Scheme? I don't think it matters at all. This point is about culture, not language spec.

So, in conclusion, from the above points, one could trivially write a Javascript to Scheme compiler that would have all the features of Scheme, except maybe call/cc. If this is what you define as Scheme, sure, fine, you win: Javascript isn't Scheme. But for the rest of us, it doesn't really matter and JS is damn close to Scheme from a practical perspective.

Moreover, it wouldn't even be that hard to add call/cc to JS! So I don't think that or any of the author's points are very valid.

I agree, Jsonnet looks really nice.

One thought I had though is that I wish they didn't use the % operator for string interpolation though and rather the more recent f-string syntax. I wonder whether it will be possible to add that or if there is a reason to prefer one over the other in this context?

I had that question and also the "just kidding" question when I heard the name. What can you do, naming things is hard.

JavaScript does have lexical block scope since ES6, with the `let` and `const` statements.

And continuations are implemented by convention in nodeJS (through callbacks)

It even is specified as including TCO, a classic scheme feature, but so far it is implemented only in Safari.

Non mutation also seems to be a trend in web development, again thanks to `const`. The only things that make JavaScript not scheme, then, are syntax and the lack of macros. (Which is kind of a result of the more complex syntax)

Jsonnet has been around for a while, but it looks like stale. Its stdlib is limited and nonstandard and the whole lazy evaluation is something new developers struggle with. I've been using it at work for 2 years and it's sad that it hasn't moved much. I think it lost a huge opportunity if it had more active and more open for innovation development. I'm sorry to say that, but the lead is busy with stuff and is highly opinionated. Also, Jsonnet is slow. We have a few hundred Jsonnet templates and it takes a very long time to compile, which is a pity given it's written in C (now being slowly and painfully rewritten in Go for whatever reasons).