JSON is widely used and understood, easy to parse and serialise to, and fundamentally simpler than most alternatives.
You could argue that S-expressions are 'simpler' than JSON, but they didn't take off, for whatever reason - I'm not going to go into opinions on why I think that is, because that never tends to go well on HN :)
On the other hand, students of the past will notice that Jsonette looks awfully similar to Ant build files, which sucked. JSON/XML/YAML is a horrible way to construct general-purpose programs. Computing languages exist for a reason.
I think we are finally starting to accept that Turing-complete data is a bug, despite what the Lisp people have been saying for 50 years, and is not a feature on the Internet. Microsoft served as the poster child in the 90's.
The tension, I strongly believe, comes during debugging. When you are trying to figure out why the data doesn't look right, the less the code resembles the data being emitted, the harder it is to locate the source of the error. Templating engines get pretty close to addressing that concern, in ways that transforms or generators don't. So we keep trying to invent a better one. But once you let a little logic in, everybody wants all the logic.
Ant found the Uncanny Valley, in a way that few other tools have managed. I think I'm okay with your implication that it was actually worse than XSLT, which is saying a lot.
[edit] Ant is also the reason I shift uncomfortably whenever someone announces proudly that a tool was 'designed and implemented on a plane trip'. I'd rather have code you wrote when drunk than code you made while stuffed in a sardine can, subjected to noise levels that OSHA would have issues with, and suffering from altitude sickness. You literally designed this while your brain wasn't getting enough oxygen.
"The interchangeability of code and data gives Lisp its instantly recognizable syntax. All program code is written as s-expressions, or parenthesized lists. A function call or syntactic form is written as a list with the function or operator's name first, and the arguments following; for instance, a function f that takes three arguments would be called as (f arg1 arg2 arg3)."Lisp interpreters tend to be dead simple to implement.
1 - https://news.ycombinator.com/item?id=4487462
2 - https://github.com/search?utf8=%E2%9C%93&q=%22application%2F...
3 - https://github.com/search?utf8=%E2%9C%93&q=%22application%2F...
When the article's author describes both code and data using JSON, it sounds a little strange to me. While JSON is capable to describing nested data structures, JSON's syntax is much more verbose than s-expressions. I feel that since s-expressions have been around for about 60 years that the author should be familiar with them and address why a JSON encoding is superior to s-expressions for this use case.
(x . (y . (z . NIL))) <=> ['x', ['y' , ['z', null]]]I should have said:
(x . (y . (z . NIL))) <=> ['x', 'y', 'z']