4 ms·
The problem is that our editors are at the core still "text" editors. That forces the tools (IDEs) to continuously synchronize the text with the parsed AST. It
by wereHamster 11y ago
The problem is that our editors are at the core still "text" editors. That forces the tools (IDEs) to continuously synchronize the text with the parsed AST.
It's trivial to get an editor right if it edits the AST directly. You skip the whole tokenization/parsing step which is where most complexity is. However, such an editor will need specific plugins for each language, and these plugins will be easier to write for languages which have a standardized AST (Haskell comes to mind). Also, users would have to give up part of the formatting (whitespace etc), and some people are very religious about that :(
- jrochkind1 11y agoIt's "trivial" once you've done a bunch of non-trivial work to make it trivial. :)
- the_af 11y agoThe counterpoint to this is that if you're not using text editors then you lose the universal property that most source code is plain text which can be edited with your preferred text editor. Plain text seems to be the most tool-agnostic representation, which for many people is a big plus. Notice that in this day and age there are still people complaining about "bloated" IDEs...
- wpietri 11y agoI think there's a useful distinction between serialization format and working format (that is, what it looks like in RAM). For a plain text editor, they're the same. But that's pretty unusual. There's reason we couldn't have an editor that works with the AST while saving everything out in plain text for interchange purposes.
- the_af 11y agoTrue. But the property you mention -- that for plain text editors the serialization and working formats are the same -- is actually a pretty useful and convenient property! I think this is why it's extremely unlikely there will ever be widespread adoption of a different format for source code. Niche tools will remain niche forever, in my opinion.
- wpietri 11y agoI think we wouldn't even have to give up whitespace, comments, and other things that get left out of ASTs. I think the problem there is that ASTs are normally thought of a one-way, compiler-friendly representation. But if we start thinking of them as a round-trip representation that is also friendly to programmers, it doesn't seem impossible to include comments and formatting as hints in the AST that compilers and interpreters ignore. Sort of the same way that many HTML and XML parsers keep track of comments and whitespace even though that generally gets ignored by code that uses the parse trees.