I did try to engage in 2016 with the WebAssembly CG, but that was a flop, as the other members mostly chose not to participate in the conversation I tried to start.
If you engage with an existing project you actually have to good arguments that convince other people. That isn’t easy but a very different problem then no business man wanting to fund it.
In any case, if we’re talking about a project like LES—I am unaware of anything else like it, so which existing project should I have engaged with in order to make it a success?
A new project needs a value proposition that allows people to make a decision that it solves their problems better then other solutions. In your description here you haven’t articulated any value proposition that would make a person prefer to write something in your framework.
The page about LES doesn’t say anything about who might have problems that LES solves and what kind of problems that happen to be.
In contrast Vue.js has a clear target audience. It’s for people who want to build larger html/js projects and thus need a js framework to manage the complexity, then it promises to be approachable, versatile and performant which are things that some of the users want.
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.
If you engage with an existing project you actually have to good arguments that convince other people. That isn’t easy but a very different problem then no business man wanting to fund it.
A new project needs a value proposition that allows people to make a decision that it solves their problems better then other solutions. In your description here you haven’t articulated any value proposition that would make a person prefer to write something in your framework.
The page about LES doesn’t say anything about who might have problems that LES solves and what kind of problems that happen to be.
In contrast Vue.js has a clear target audience. It’s for people who want to build larger html/js projects and thus need a js framework to manage the complexity, then it promises to be approachable, versatile and performant which are things that some of the users want.
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.