3 ms·

Or, hear me out - instead of trying to work around a legitimate feature of Unicode, you could stop storing your source code as text, because it isn't. Code is n

Or, hear me out - instead of trying to work around a legitimate feature of Unicode, you could stop storing your source code as text, because it isn't. Code is not text - it's a tree of objects, and representing it as a flat sequence of text characters causes many problems and inefficiencies (including this one!) that could be mitigated if you just stored and manipulated it as a tree. The only reason why text was justifiable as a storage and manipulation format for code in the first place was because early computers (probably?) couldn't handle a tree format. That excuse has been invalid for several decades now, as is the idea that "everything is plain text". Code isn't plain text - if it was, then you could make arbitrary edits without syntax errors, but you can't, because code has structure. Start treating it that way.

shaunxcode 5y ago
Yes! This would also do away with a whole class of conflicts related to whitespace/formatting.
- throw10920 5y ago
  Exactly! Imagine a version control system where you get diffs on the AST tree, instead of the characters that make up the source (add an `if` and suddenly dozens of lines have "changed"), or the tabs/spaces flamewar evaporating instantly.
  - account42 5y ago
    Nothing is stopping your current version control tool from parsing the code and showing a structural difff now.
rocqua 5y ago
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.
- throw10920 5y ago
  > The thing about text is that it is barebones. 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.
scintill76 5y ago
Also helps with naming. Only need a value once or twice? Don’t bother trying to name it, just link it into the tree where it’s needed.
- db48x 5y ago
  You can actually do that in Lisp. Lisp code is commonly thought of as a tree, but it is really a bunch of linked lists. The links can be arranged in any way you want. http://www.lispworks.com/documentation/HyperSpec/Body/02_dhp.htm http://www.lispworks.com/documentation/HyperSpec/Body/02_dhp... The example shows this with some made–up data, but you can use it with arbitrary code as well. It is very easy to use it to create circular lists, which when executed are infinite loops. Naturally the only sane thing to do is to keep your code strictly a tree.

shaunxcode 5y ago

Yes! This would also do away with a whole class of conflicts related to whitespace/formatting.

throw10920 5y ago
Exactly! Imagine a version control system where you get diffs on the AST tree, instead of the characters that make up the source (add an `if` and suddenly dozens of lines have "changed"), or the tabs/spaces flamewar evaporating instantly.
- account42 5y ago
  Nothing is stopping your current version control tool from parsing the code and showing a structural difff now.

rocqua 5y ago

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.

throw10920 5y ago
> The thing about text is that it is barebones. 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.

scintill76 5y ago

Also helps with naming. Only need a value once or twice? Don’t bother trying to name it, just link it into the tree where it’s needed.

db48x 5y ago
You can actually do that in Lisp. Lisp code is commonly thought of as a tree, but it is really a bunch of linked lists. The links can be arranged in any way you want. http://www.lispworks.com/documentation/HyperSpec/Body/02_dhp.htm http://www.lispworks.com/documentation/HyperSpec/Body/02_dhp... The example shows this with some made–up data, but you can use it with arbitrary code as well. It is very easy to use it to create circular lists, which when executed are infinite loops. Naturally the only sane thing to do is to keep your code strictly a tree.