The thing about text is that it is barebones. Everyone can agree what the structure of text is (a stream of bytes with some ascii like encoding).
For representing code as more than text, you will lose so much tools that can handle your code, it's a massive set back. Add to that how much effort it takes to get people onboarded on your new representation, and things look bleak for adoption.
Finally, programmers really like looking under the hood. And with plain text, you know exactly what your code looks like in bytes.
That's a bug. Programming is hard, and you want the best, most powerful tools to handle it as you can - which means putting effort into making specialized tools instead of using generic ones like text editors.
> For representing code as more than text, you will lose so much tools that can handle your code, it's a massive set back.
No tools existed without first being built, so this isn't special. Rust didn't have any tools before people started building tools for it, for instance.
Moreover, the tools that we have now that are text-specific are pathetic. You can view the first n lines of a file? Wow, very impressive /s. More complex things like grep are just as realizable in a structure editor, and in order to use them for non-trivial stuff, you'd have to write structural regular expressions and implement mini-parsers anyway - things you would get for free if you just kept code as structure.
> Add to that how much effort it takes to get people onboarded on your new representation, and things look bleak for adoption.
You're misreading my argument. I'm not saying that people will adopt structured code (a descriptive statement), I'm saying that people should adopt structure code (a normative statement) because it'll be much better for them.
Also, you're making the assumption that onboarding is hard, and that compatibility layers can't exist - neither of which are true.
> Finally, programmers really like looking under the hood. And with plain text, you know exactly what your code looks like in bytes.
The average programmer probably looks at their code with a hex editor once in their life - this isn't really a good argument. Moreover, the vast majority of programmers already tolerate not looking under the hood in dozens of different ways - most use VM's like CPython/JVM/JS VMs, opaque frameworks like React/Angular, graphics APIs like OpenGL/DirectX/Vulkan, complicated editors like Visual Studio Code/Emacs, and far more without ever looking under the hood of any of those - so there's no reason to not add another layer (especially because you can build that layer to be easy to peer through) for the sake of productivity.
For representing code as more than text, you will lose so much tools that can handle your code, it's a massive set back. Add to that how much effort it takes to get people onboarded on your new representation, and things look bleak for adoption.
Finally, programmers really like looking under the hood. And with plain text, you know exactly what your code looks like in bytes.