Plain text is only storage, I happily posit plain text as storage is not the issue. It's the tooling above that's lacking. From editors to source control, it's

Plain text is only storage, I happily posit plain text as storage is not the issue. It's the tooling above that's lacking. From editors to source control, it's all text/buffer/line/character oriented, which does have its benefits. Sure there's syntax highlight, folding, symbol search and whatnot but semantically these tools only superficially understand code itself and certainly don't operate on code, they only pretend to and are fundamentally text editors. We're getting there with LSPs and error-tolerant parsers but they still map back to text for us to interact. Tools like gofmt, black, ruby standard and such already kind of abstract away text as storage: you write code in whatever way and it gets transformed right under your feet. In some way as a dev you already don't care about the text, it gets handled for you, but it still maps back to text because editors can't handle anything else. Similarly LSPs are in my mind quite nerfed because they have to do a whole back and forth to text dance. Vim text objects kind of goes into that direction as well, where you think about higher level constituents than text (arguments, methods, etc). Imagine being able to bind the understanding of LSPs right into semantic Vim language objects without them having to go through text! I dream of an editor where I can open a bunch of functions or classes or namespaces (not files) in buffers that have understanding of the constituents, and it would all map back to files for storage behind the scenes. I believe it doesn't have to go full tilt Smalltalk-like; the Closure conf Overtone demo from years ago is almost there, although not quite.