Originally Posted on Medium
I spent 7 months working on a new programming language called MSON. Here is a nerdy post about why I did it, how it ...
For further actions, you may consider blocking this person and/or reporting abuse
This is the future of programming. I've been doing this in other projects it works well. Warning, because this is a DSL it lacks proper refactoring tools other than Find/Replace. Not as nice as a real language. I'm sure those tools are on the radar.
Yeah, I think this is the future!
I think MSON sits somewhere in between a DSL and a fully-fledged language. It has high-level programming concepts like inheritance, composition, etc... That being said, you can't program just anything in MSON so it isn't quite a "full" language.
Actually it is a DSL, and there are no refactoring tools for this. For example, assume the project has 100 MSON files. A change comes in that requires renaming a simple property. With today's tools we just rename the property in one place, one time. With DSLs you have to rename them everywhere. This is what MSON would have to do now. And it can lead to future problems big time depending on the situation.
Another problem is with refactoring. Assume you want to refactor things into pure function like parts. How will all the refactorings be changed to just that one part? Each refactoring could reduce 10 lines of code to 1 line of code which points to the pure refactored function. Not all of those 10 lines of code would be the same if parameters are heavily used.
Good points here. There is a concept of reusable components, including actions, that allow you to keep it DRY. Combine them with inheritance and template parameters and you have the same freedom as a fully-fledged language. The only lock in is in the component names, which is similar to how you define a class/module name in any mainstream language
I have just tried the BasicApp in a codesandbox, one question I have,
Why should I use a component's name as a string, instead of referring to it as to an object?
e.g. there's field
component: "Form",so how do I know what's the name of the component that will be used?
I can import a component via
import { Form } from 'mson-react'but when I use it as
component: Form, // this doesn't workUsing strings is very error-prone, you can't check if the name is correct, so things might not render, and you don't know why.
The error that appears on wrong naming is
const app = compiler.newComponent({____________________^
Great question! If we were to use objects instead of strings, the definition would be JS and not JSON. By keeping it JSON there is native support for many things like storing JSON in a DB. Moreover, there are tons of tools that work with JSON that we can leverage, eg JSON editors, YAML to JSON converters, etc...
The MSON compiler attempts to validate some of these values (types) upfront. It wouldn't be too difficult to run the MSON compiler as a linter.
It's funny because we are doing this more and more at work: make apps that our CSM can tweak easily with a config file at the top or in a given folder. Reading the comments, I see we are not alone at all.
You are pushing the concept very far, but still I really like the idea—although I am afraid in real life scenarios those MSON files will grow very large!
Congrats on the great work!
Thanks! My thought is that if we have an open extensible layer, we can build together
this reminds me of Amundsen's DARRT, so: REST
why not go full REST?
Hey @nothingness! Not sure I follow. Could you please elaborate?
what you develop here is comparable to Amundsen's DARRT: github.com/mamund/api-starter especially around Actions
why not use Link Relations in the JSON like w3c's Hydra, Siren, Collection-JSON. looks like you have created a kind of approach to underpinning these RESTful approaches.
Interesting, I think DARRT looks like a useful way for developing a backend (REST API). Ideally, one of MSON's goals is to declare both the frontend and backend with a single set of models. The backend I've been playing with uses GraphQL, which provides a very rich, and widly adopted, querying layer
Goes it bit further than this, because Amundsen is literally talking about generic clients that "share understanding" (therefore, they share models, and of course servers can invalidate cache; but the idea is evolution of one model between client and server — so you're not fundamentally deviating from Amundsen and Fielding's and et al's goal: you may want to check out Amundsen's Hypermedia-oriented Design and also ALPS) but there are affinities between what you are doing and what Mike Amundsen/Roy Fielding/etc had been establishing in Hypermedia-Oriented systems for scale-free (and potentially coordination-free) systems that do not require context-free grammars but expected message modeling as formal input recognition in governing program semantics conforming to consistency as logical monotonicity (CALM conjecture) rather can Strong Consistency models
Nerdy, I love it!!!!
Great job 👍, I'll try it out soon.