On Sun, Nov 5, 2017 at 8:22 AM, Michael Lewis <m...@lew42.com> wrote:
> Raul-Sebastian Mihăilă just made a post here about some mixin syntax. I > didn't read it (sorry). > > But, it got me thinking about a concept I've been thinking for years: *syntax > is the problem*, and there's a better solution. > > If you define syntax as a human <--> computer language (a human-readable > and computer-readable form of text), you necessarily need a very strictly > defined syntax. One missing curly, and you're f'd. > > Duh, we all know this. Hang onto your pants for a second, let's explore > an alternative. > > What if we edited scripts more directly in AST form (abstract syntax > tree). Developers could implement their own UI to manipulate this AST. > There are many, many benefits to this, I'll get to in a second. > Assuming you're bringing this to TC39 because you think the committee can contribute to this effort, there seem to be a few separable questions here: 1. Would there be benefit to standardizing an AST? 2. Would developers benefit from being able to manipulate ASTs? 3. Should TC39 organize efforts to realign JS development around AST manipulation? TC39 has already debated some AST proposals. You could add your use case to those. You really don't need them though. Babel didn't wait. I'm unsure why manipulating ASTs is a benefit. It seems tools that manipulate ASTs can simply have a parser tacked on the front and a serializer tacked on the back and manipulate text files. This is what the refactoring tools in IDEs like Eclipse do. Even if these tools are wildly popular, the syntax won't be going away though. Backwards-compatibility requires EcmaScript be embeddable in HTML, SVG and a number of other textual formats. It seems to me, that TC39 need not be involved in the process of specing tools for manipulating ASTs and even if TC39 gives a full-throated endorsement to such tools, it would still have to spec syntax. First, let's remember what everyone in the JS community is doing right > now: running their code through transpilers. (I refuse to do this, that's > why I'm unemployed - I strongly dislike the concept). What is a > transpiler? It's an unofficial middleman that interprets the syntax, > converts it to an AST, performs transformations, and then returns the AST > to syntax form. > Suddenly, scripting in AST form doesn't sound so crazy. > How does (developers would be better off authoring ASTs) follow from (tools like transpilers use ASTs internally)? Clearly, you wouldn't be writing JSON. We would be using a GUI to create > the AST. And this is the greatest benefit: moving away from *syntax*, > and moving to a GUI. > There's a whole literature on end-user programming that others have referenced. None of it has caught on with professional developers. How are the GUIs you propose different from past efforts? Most Lisp syntaxes map directly to the AST with just a bit of syntactic sugar. There are also plenty of fine GUIs. You can have an awesome GUI for building an AST and still have syntax so that you can review code on long plane trips. > Then, instead of babel plugins that provide alternative *syntax*, you > could have plugins that provide alternative *experiences.* > > What would designing a class look like, if using a GUI? > > 1. Click [ create new class ] > 2. Click [ add new method ] > > I can do this in Eclipse. Most of the time I just type "class." There seems little benefit to a GUI that replaces repetitive typing with repetitive clicking, and I'm not familiar enough with the terms you use to know why I would want to plug-in experiences. > Or, click the [ extend ] button next to an existing class... > > This is the future. > This is an odd choice of tense. > I have to go eat breakfast, but I'd love to discuss this future if anyone > is interested... > I hope you had an awesome breakfast! Maybe someday we'll all Click [ eat brekkie ].
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
