Speaking of little tragedies, some tragedies got me thinking a long time ago.
My biggest one was the fact that most programming languages (1) aren’t compatible...Python doesn’t Interop with C# doesn’t Interop with C++… So people struggle to keep reinventing the wheel in different languages and only rarely is a job done well; And (2) popular languages aren’t powerful or extensible (or efficient) enough—e.g. I made a prototype unit inference engine for an obscure language in 2006 and still today not a single one of the popular languages has a similar feature. So I set out to fix these problems 13 years ago in my free time… and I’m still stuck on these problems today. I wished so much I could spend more time on it that in 2014 I quit my job, which turned out to be a huge mistake, but never mind. (There are web sites for my projects which go unnoticed by pretty much everyone. My progress has been underwhelming, but even when I think I’ve done a great job with great documentation and I’ve tried to publicize it, it makes no difference to the popularity. Just one of life’s mysteries.)
Anyway, I’ve come to think that actually there are lots of similar problems in the world: problems that go unsolved mainly because there is just no way to get funding to solve them. (In a few cases maybe it’s possible to get funding but the ideas man just isn’t a businessman so it doesn’t happen… I don’t think this is one of those cases.) For any given problem whose solutions are difficult and don’t match up with any capitalist business model, they’re probably just not going to be solved, or they will be solved in a very slow and very clumsy way.
I think government funding for “open engineering” is needed, where the work product is a product, service, or code library, not a LaTeX jargonfest in a journal. Conventional science itself seems vaguely messed up, too; I’ve never seen the sausage get made so I’m unfamiliar with the problems, but they seem rather numerous and so I would qualify the previous statement by saying we need open engineering that doesn’t work as badly as science.
UBI might work as an alternative. It would lack the motivating structure of a conventional job, but if I could find one other UBI-funded person who wanted to do the same project, maybe we could keep each other motivated. I noticed a very long time ago that most successful projects have at least two authors, but still I never found a second person who wanted to work on the same project and earn zero income.
There are web sites for my projects which go unnoticed by pretty much everyone.
When wanting to create change you have the choice to engage with the existing system or do something outside of the system.
Here you made a choice to be outside of the system and thus don’t affect the system. Many languages have open design processes and engaging with those is the key of creating change.
We don’t live in a world where all the programming languages we have are closed source with closed language design.
It has not escaped my notice that hopping on a bandwagon is an easier way to gain attention, but a lot of people have had success by starting their own projects.
How is what I did different from Ruby, Python, Vue, Unison, V, Nim, or any of those projects where people make general-purpose libraries to supplement the standard libraries? And in particular, how is my LeMP front-end for C# different from C++, which began as a C preprocessor called “C with Classes”?
A tempting answer is that I was simply 20 years too late to be able to do something new, but V and Vue are quite recent examples. 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? 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.
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.
Speaking of little tragedies, some tragedies got me thinking a long time ago.
My biggest one was the fact that most programming languages (1) aren’t compatible...Python doesn’t Interop with C# doesn’t Interop with C++… So people struggle to keep reinventing the wheel in different languages and only rarely is a job done well; And (2) popular languages aren’t powerful or extensible (or efficient) enough—e.g. I made a prototype unit inference engine for an obscure language in 2006 and still today not a single one of the popular languages has a similar feature. So I set out to fix these problems 13 years ago in my free time… and I’m still stuck on these problems today. I wished so much I could spend more time on it that in 2014 I quit my job, which turned out to be a huge mistake, but never mind. (There are web sites for my projects which go unnoticed by pretty much everyone. My progress has been underwhelming, but even when I think I’ve done a great job with great documentation and I’ve tried to publicize it, it makes no difference to the popularity. Just one of life’s mysteries.)
Anyway, I’ve come to think that actually there are lots of similar problems in the world: problems that go unsolved mainly because there is just no way to get funding to solve them. (In a few cases maybe it’s possible to get funding but the ideas man just isn’t a businessman so it doesn’t happen… I don’t think this is one of those cases.) For any given problem whose solutions are difficult and don’t match up with any capitalist business model, they’re probably just not going to be solved, or they will be solved in a very slow and very clumsy way.
I think government funding for “open engineering” is needed, where the work product is a product, service, or code library, not a LaTeX jargonfest in a journal. Conventional science itself seems vaguely messed up, too; I’ve never seen the sausage get made so I’m unfamiliar with the problems, but they seem rather numerous and so I would qualify the previous statement by saying we need open engineering that doesn’t work as badly as science.
UBI might work as an alternative. It would lack the motivating structure of a conventional job, but if I could find one other UBI-funded person who wanted to do the same project, maybe we could keep each other motivated. I noticed a very long time ago that most successful projects have at least two authors, but still I never found a second person who wanted to work on the same project and earn zero income.
When wanting to create change you have the choice to engage with the existing system or do something outside of the system.
Here you made a choice to be outside of the system and thus don’t affect the system. Many languages have open design processes and engaging with those is the key of creating change.
We don’t live in a world where all the programming languages we have are closed source with closed language design.
It has not escaped my notice that hopping on a bandwagon is an easier way to gain attention, but a lot of people have had success by starting their own projects.
How is what I did different from Ruby, Python, Vue, Unison, V, Nim, or any of those projects where people make general-purpose libraries to supplement the standard libraries? And in particular, how is my LeMP front-end for C# different from C++, which began as a C preprocessor called “C with Classes”?
A tempting answer is that I was simply 20 years too late to be able to do something new, but V and Vue are quite recent examples. 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? 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.
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.