4 ms·

I don't understand why we don't make the aesthetic aspects of syntax (e.g. block delimitation) to be a feature of the editor rather than the source of truth for

I don't understand why we don't make the aesthetic aspects of syntax (e.g. block delimitation) to be a feature of the editor rather than the source of truth for the code. For all unix profited from text I think we have the tooling necessary to move our storage and editors beyond it, and it's been obvious the entire time it comes with non-trivial liability converting to and from more reliably structured representations.

williamdclt 2y ago
I think it boils down to “text is good _enough_” (80% of the value, 10% of the complexity if even that), and it’s a format that’s incredibly interoperable. You can use tools that aren’t just language agnostic, but are not even programming-specific: notepads, grep, git, sed…
- darby_nine 2y ago
  I agree completely; I just think on a gut-level a solution would be validated with use despite the small marginal gain over text in complexity of tooling. Among RAGs, TreeSitter, and the success of LSPs, I think there's room here to synthesize some improvements. While we're on the topic, if we store only syntactically valid programs, we can express diffs in terms of semantic refactoring rather than textual changes. This would enable stuff like preserving refactoring across merges, thereby bypassing conflicts that would arise under text merges. There are limits to this of course as you can still come up with conflicts, but anything to ameliorate the nightmare of manually fixing a textural merge.
  - digging 2y ago
    Huh, your comment made me reconsider. Variable names are very important to code quality, so how would those be preserved if not using text? I suppose they could be programmatically generated to be "good" but I foresee illegible edge cases being frequent in that case.
deleted 2y ago
[deleted]
islandert 2y ago
Would the JVM ecosystem almost be a working example of this? Since there are a variety of languages with editor integration that all compile down to the same byte code, it feels pretty close to what you’re describing.
- kriiuuu 2y ago
  Unison would fit here
- darby_nine 2y ago
  The JVM languages are pretty damn close!
- kevincox 2y ago
  I believe that JVM bytecode is too low level for a source format. At the very least you would need to preserve some form of comments. Also I think JVM locals lose their names during compilation.
Nihilartikel 2y ago
I'm kind of with you here. Lispy languages have structural editing tools that make it a lot like working directly on an AST. It's a delight when you get used to it. The spacing/linebreaks are all just auto formatted and mostly an afterthought. It would only be one step further to present the code with the users choice of block start/end sequences.
- darby_nine 2y ago
  Working with paredit was certainly one of the main ingredients for structural editing (as opposed to textual editing) to click with me. I've been watching TreeSitter with great interest.
Gibbon1 2y ago
I think text based programming languages are a local minima that's it's hard climb out of. Partly because most languages aren't designed around being represented by structured data. And no one has any morden experience with that. But do imagine a world were changing the name of a field in a struct results in a single diff message, 'struct foo field bar changed to baz'. And where a change set to to a library can be mechanically applied to to code that depends on it and it just works.
quasarj 2y ago
You can have my plain text when you pry it from my cold dead fingers!
morkalork 2y ago
I always open these threads with the hope that someone will mention Fortress but so far I'm just disappointed.
cranium 2y ago
"Code-as-Text" is way too universal and deeply ingrained to change in the short to medium term. I've worked a bit with low code / no code platforms and everything becomes a mess: little to no version control, search is bad, no import or possibility to generate components programmatically,... However, I'm totally with you on having the editor show the code as you'd like. As much as I don't like tabs, at least the user could choose their preferred width for indentation. (A less disruptive Python-with-braces could be the editor showing braces but converting to spaces behind the scene.)
- quectophoton 2y ago
  > However, I'm totally with you on having the editor show the code as you'd like. Such editors would remove some categories bikeshedding, but would add brand new categories of bikeshedding. * Why did/didn't you add an empty line (EDIT: or whatever no-op visual equivalent) after that `if` block? My editor needs blocks to be separated a certain way to be able to display them nicely grouped in logical blocks! This representation of AST is so limited that we can't store such differences in style, we need editors that work at some super-AST level! * What do you mean my code is an unreadable mess with hundreds of operations? All I see in my editor is a nice single operation "copy fields from class X to struct Y". If your editor can't detect such an obvious thing from the AST and display it nicely, then find a better one. * Some codebases not even bothering with functions because the founding engineers use a specific IDE that just lets them group code arbitrarily (no no that's not reinventing functions, that's what progress looks like!), and you can't use your favorite editor because that's not on the scope of that editor, so the editor's author politely tells you to use that other editor you dislike if you really need such a thing. * I can probably come up with more scenarios if I spend more time thinking about it. And there's probably also more petty scenarios that I can't even imagine. I'm not saying such editors wouldn't be nice. Everyone has their own preferences, and some people might work better this way. Just, don't expect them to reduce the amount of petty bikeshedding in projects, much less eliminate it.
voiper1 2y ago
Would VS Code support a plugin to _display_ python with brackets, but open/save to disk in standard indented format?
kevincox 2y ago
The freedom that text provides is not a blessing and a curse. Even small things like adding "paragraph break" lines in a run of code can make it more readable. Of course you can encode a limited number of these "style" features into your source AST but much like code formatters there is always a limit to helpful style that is preserved and irrelevant stuff that is rendered to each programmers preference.

williamdclt 2y ago

I think it boils down to “text is good _enough_” (80% of the value, 10% of the complexity if even that), and it’s a format that’s incredibly interoperable. You can use tools that aren’t just language agnostic, but are not even programming-specific: notepads, grep, git, sed…

darby_nine 2y ago
I agree completely; I just think on a gut-level a solution would be validated with use despite the small marginal gain over text in complexity of tooling. Among RAGs, TreeSitter, and the success of LSPs, I think there's room here to synthesize some improvements. While we're on the topic, if we store only syntactically valid programs, we can express diffs in terms of semantic refactoring rather than textual changes. This would enable stuff like preserving refactoring across merges, thereby bypassing conflicts that would arise under text merges. There are limits to this of course as you can still come up with conflicts, but anything to ameliorate the nightmare of manually fixing a textural merge.
- digging 2y ago
  Huh, your comment made me reconsider. Variable names are very important to code quality, so how would those be preserved if not using text? I suppose they could be programmatically generated to be "good" but I foresee illegible edge cases being frequent in that case.

deleted 2y ago

[deleted]

islandert 2y ago

Would the JVM ecosystem almost be a working example of this? Since there are a variety of languages with editor integration that all compile down to the same byte code, it feels pretty close to what you’re describing.

kriiuuu 2y ago
Unison would fit here
darby_nine 2y ago
The JVM languages are pretty damn close!
kevincox 2y ago
I believe that JVM bytecode is too low level for a source format. At the very least you would need to preserve some form of comments. Also I think JVM locals lose their names during compilation.

Nihilartikel 2y ago

I'm kind of with you here. Lispy languages have structural editing tools that make it a lot like working directly on an AST. It's a delight when you get used to it. The spacing/linebreaks are all just auto formatted and mostly an afterthought. It would only be one step further to present the code with the users choice of block start/end sequences.

darby_nine 2y ago
Working with paredit was certainly one of the main ingredients for structural editing (as opposed to textual editing) to click with me. I've been watching TreeSitter with great interest.

Gibbon1 2y ago

I think text based programming languages are a local minima that's it's hard climb out of. Partly because most languages aren't designed around being represented by structured data. And no one has any morden experience with that. But do imagine a world were changing the name of a field in a struct results in a single diff message, 'struct foo field bar changed to baz'. And where a change set to to a library can be mechanically applied to to code that depends on it and it just works.

quasarj 2y ago

You can have my plain text when you pry it from my cold dead fingers!

morkalork 2y ago

I always open these threads with the hope that someone will mention Fortress but so far I'm just disappointed.

cranium 2y ago

"Code-as-Text" is way too universal and deeply ingrained to change in the short to medium term. I've worked a bit with low code / no code platforms and everything becomes a mess: little to no version control, search is bad, no import or possibility to generate components programmatically,... However, I'm totally with you on having the editor show the code as you'd like. As much as I don't like tabs, at least the user could choose their preferred width for indentation. (A less disruptive Python-with-braces could be the editor showing braces but converting to spaces behind the scene.)

quectophoton 2y ago
> However, I'm totally with you on having the editor show the code as you'd like. Such editors would remove some categories bikeshedding, but would add brand new categories of bikeshedding. * Why did/didn't you add an empty line (EDIT: or whatever no-op visual equivalent) after that `if` block? My editor needs blocks to be separated a certain way to be able to display them nicely grouped in logical blocks! This representation of AST is so limited that we can't store such differences in style, we need editors that work at some super-AST level! * What do you mean my code is an unreadable mess with hundreds of operations? All I see in my editor is a nice single operation "copy fields from class X to struct Y". If your editor can't detect such an obvious thing from the AST and display it nicely, then find a better one. * Some codebases not even bothering with functions because the founding engineers use a specific IDE that just lets them group code arbitrarily (no no that's not reinventing functions, that's what progress looks like!), and you can't use your favorite editor because that's not on the scope of that editor, so the editor's author politely tells you to use that other editor you dislike if you really need such a thing. * I can probably come up with more scenarios if I spend more time thinking about it. And there's probably also more petty scenarios that I can't even imagine. I'm not saying such editors wouldn't be nice. Everyone has their own preferences, and some people might work better this way. Just, don't expect them to reduce the amount of petty bikeshedding in projects, much less eliminate it.

voiper1 2y ago

Would VS Code support a plugin to _display_ python with brackets, but open/save to disk in standard indented format?

kevincox 2y ago

The freedom that text provides is not a blessing and a curse. Even small things like adding "paragraph break" lines in a run of code can make it more readable. Of course you can encode a limited number of these "style" features into your source AST but much like code formatters there is always a limit to helpful style that is preserved and irrelevant stuff that is rendered to each programmers preference.