The idea is to represent the code as data not to write the data by hand. Nor to read it in JSON format. This aproach enables projectional editing (term popularized by Intellij in their MPS) that has much more potential then traditional text editors.
Why? Because we can write the code once and generate multiple versions of binaries choosing implementation language that suites the best the target evironments with their constraints. For example runs in the browser and also super fast on the desktop.
I actually faced this when migrating a gui component from SWT (Java) to Javascript). It felt such a waste of time to rewrite everything.
What you put in the JSON is effectively just a serialized AST for a specific language. Yes, it's JSON, but it's not just JSON - the structures and values have syntax and form that goes beyond JSON, much the same as how source languages go beyond ASCII or Unicode.
Plenty of compilers transform the AST in the middle, applying optimizations and so forth - applying transformations to JSON isn't fundamentally different from applying transformations to an AST. It's a model, with a specific schema, and you transform it. The back-end of the compiler ultimately transforms the final AST into some other source language or binary form.
Why? Because we can write the code once and generate multiple versions of binaries choosing implementation language that suites the best the target evironments with their constraints. For example runs in the browser and also super fast on the desktop.
That just explains why we have high-level languages and compilers.
From what you've explained, all you're proposing is a high-level language with a syntax that happens to be a superset of JSON.
I mean, yes, you'd be able to parse it using a standard JSON parser - it would work sort of like a high-level lexer, but you would still need to build all of the remaining parts of a compiler. (And probably a highly specialized editor as well, since working with these bulky JSON structures in a text editor would be... less than appealing.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The idea is to represent the code as data not to write the data by hand. Nor to read it in JSON format. This aproach enables projectional editing (term popularized by Intellij in their MPS) that has much more potential then traditional text editors.
Why? Because we can write the code once and generate multiple versions of binaries choosing implementation language that suites the best the target evironments with their constraints. For example runs in the browser and also super fast on the desktop.
I actually faced this when migrating a gui component from SWT (Java) to Javascript). It felt such a waste of time to rewrite everything.
But it's still a language.
What you put in the JSON is effectively just a serialized AST for a specific language. Yes, it's JSON, but it's not just JSON - the structures and values have syntax and form that goes beyond JSON, much the same as how source languages go beyond ASCII or Unicode.
Plenty of compilers transform the AST in the middle, applying optimizations and so forth - applying transformations to JSON isn't fundamentally different from applying transformations to an AST. It's a model, with a specific schema, and you transform it. The back-end of the compiler ultimately transforms the final AST into some other source language or binary form.
That just explains why we have high-level languages and compilers.
From what you've explained, all you're proposing is a high-level language with a syntax that happens to be a superset of JSON.
I mean, yes, you'd be able to parse it using a standard JSON parser - it would work sort of like a high-level lexer, but you would still need to build all of the remaining parts of a compiler. (And probably a highly specialized editor as well, since working with these bulky JSON structures in a text editor would be... less than appealing.)