Perhaps a controversial opinion, but to me this really just shows the major flaw with our current text-file-based model for programming languages; it mixes the actual content of our programming with its presentation. It's time we begin to move past text files for storing our programs and move to directly using a shared intermediate representation (something along the lines of an AST). Then we can move past all this nitpicking about code style, indenting, etc.
There were many attempts at that, JetBrains MPS (metaprogramming studio) comes to mind, but all them feel clunky and constrained.
Many proprietary programming systems do follow this model, like Mathematica and visual IDEs like PLC programmers. But to bring it to wide programming audience we need to agree on an open format for representing syntax trees and implement several editors for typical use cases, from ultra-lightweight slow-connection-SSH-capable to more or less fully featured IDEs. Though I don't know much details about them, tree-sitter and language server protocol could be centers of crystallization for such software. I hope we'll see interesting developments in this space.
But if you are using if/else vs .getOrElse vs map to do something the ASTs would be different.
Also the whole which package manager to use in Python, or which Async lib to use, or which part of std-lib is to be avoided in certain cases or so on.
I think those things need specific guidance and agreement. AST would help with code layout though, but lots more to do in a language with many ways to accomplish something.
I think that's an interesting solution. The thing I've always wondered about doing this though is how would it work for storing code that has syntactical errors? dartfmt has the option of just giving up as you're still left with text. What happens when you want to share code that has those kind of errors?
If we assume code is shared in AST form, but people still end up editing a text representation of the AST (rather than directly editing the AST through a visual interface, as in Scratch et al), then you just wouldn't be able to share your syntax errors - realistically you'd put them in a comment or something, or exchange out-of-band.
Sounds appealing, but I think in practice this would be very unpleasant to work with. ASTs are almost always significantly more verbose than the code that generated them which makes both reading and writing more painful.
I say this from my own experience designing a language. Writing the AST directly was at least 2x as long as the language code.
I agree with this if the AST is a YAML or JSON document, but maybe if it was visual then you wouldn't have that problem (but I imagine it would exacerbate the style problem while also eliminating many of the advantages of text formats).
I like this idea and I feel like it should exist for something like Racket. You would need to write an unparser that takes an AST (or some canonical dialect like lang/racket) and then maps it back to text (a function of target language + style config) for the purposes of editing and the saves as the AST again. While I don't think you can just invert a reader function you probably can ask an LLM to do the inversion for you and check it. It's pretty much decompilation after all.
