So, how is that different from JSON? I could take the elevator pitch at JSON.org and change some words to make it about LES:
LES (Loyc Expression Syntax) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is a superset of JSON that looks similar to numerous other programming languages. LES is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make LES an excellent data-interchange language, but also a good basis for DSLs and new programming languages.
LES is built on three structures:
Blah blah blah
I guess JSON had some additional evangelism which LES does not, but I don’t know what exactly made it popular. You might say “well, JSON is valid JavaScript” but in practice that’s usually not relevant, as it is unsafe to eval() JSON, and it is virtually unheard of to go in the opposite direction and write JavaScript data in JSON style. In practice, JSON is similar to JS but is clearly distinct, just as LES is similar to JS but distinct.
To put it another way: JSON provides data interoperability. It seems like no one has to explain why this is good, it’s just understood. So I am puzzled why the same argument for code falls flat, even though I see people gush about things like “homoiconicity” (which LES provides btw) without having to explain why that is good.
P.S. no one disagreed with my arguments at the WebAssembly CG, so don’t be too quick to judge my arguments as bad.
P.P.S. and to be clear, I don’t expect the average developer to get it at this point in time, but the argument apparently fell flat even among language designers at FoC. Nobody said they didn’t understand, but no interest was expressed either.
In Client/Server world the fact that you need to package in your frontend to be read in the backend is an obvious problem. On the hand few developers have the problem of passing code between applications. The practical cases that come to my mind just use Javascript. The crossplatform code you write for CouchDB for example is in Javascript.
You might say “well, JSON is valid JavaScript” but in practice that’s usually not relevant, as it is unsafe to eval() JSON
That’s not my experience. While you might not want to call eval() in production, it seems very useful for testing purposes to be able to copy-paste the data that you send and make an object out of it.
In 2002 when JSON was first developed and found more adoption I would expect that people used a lot of eval().
P.S. no one disagreed with my arguments at the WebAssembly CG, so don’t be too quick to judge my arguments as bad.
In this context a good argument is one that convinces people that it’s valuable to adopt something and your arguments didn’t do that.
So, how is that different from JSON? I could take the elevator pitch at JSON.org and change some words to make it about LES:
I guess JSON had some additional evangelism which LES does not, but I don’t know what exactly made it popular. You might say “well, JSON is valid JavaScript” but in practice that’s usually not relevant, as it is unsafe to eval() JSON, and it is virtually unheard of to go in the opposite direction and write JavaScript data in JSON style. In practice, JSON is similar to JS but is clearly distinct, just as LES is similar to JS but distinct.
To put it another way: JSON provides data interoperability. It seems like no one has to explain why this is good, it’s just understood. So I am puzzled why the same argument for code falls flat, even though I see people gush about things like “homoiconicity” (which LES provides btw) without having to explain why that is good.
P.S. no one disagreed with my arguments at the WebAssembly CG, so don’t be too quick to judge my arguments as bad.
P.P.S. and to be clear, I don’t expect the average developer to get it at this point in time, but the argument apparently fell flat even among language designers at FoC. Nobody said they didn’t understand, but no interest was expressed either.
In Client/Server world the fact that you need to package in your frontend to be read in the backend is an obvious problem. On the hand few developers have the problem of passing code between applications. The practical cases that come to my mind just use Javascript. The crossplatform code you write for CouchDB for example is in Javascript.
That’s not my experience. While you might not want to call eval() in production, it seems very useful for testing purposes to be able to copy-paste the data that you send and make an object out of it.
In 2002 when JSON was first developed and found more adoption I would expect that people used a lot of eval().
In this context a good argument is one that convinces people that it’s valuable to adopt something and your arguments didn’t do that.