On one hand, I don’t use fonts with ligatures (I use Triplicate by the OP, very happy with it), and usually work without colorful syntax highlighting.
The assumption is that code is read more often than it is written, and I have no idea how my code will be read in future—thus the rule of thumb: if I understand it when it’s plain text monochrome, then the next maintainer (or future me) will be able to understand it with syntax highlighting on. I’m already biased to understand my own code more easily than anyone else, so I shouldn’t need extra visual aids if I’m not the only one who’ll work with it.
Plus, ligatures, syntax highlighting and auto-completion strike me as, in a sense, attempts to create a rudimentary GUI (TUI) to AST on top of plain text—but due to limited capabilities to work with it’s always semi-broken: syntax highlighting is off, ligatures have false positives, etc.
On the other hand, the idea that “we must keep using plain text” strikes me as somewhat stuck in the past.
The age of syntax-tree-driven, program-as-structured-data version control and editing capabilities must not be far off. At that point, we’ll likely get much greater flexibility—highlighting/autocompleting not just tokens but entire patterns (for adequately structured programs), exposing new refactoring operations, and more. We might start seeing cases where a genius high-level architect may not be that proficient at editing programs in plain text, and it’ll be obvious in hindsight.
(As an aside, I’m a little sour that GitHub/MS threw resources onto black-box ethically questionable Copilot rather than structured code.)
On the third hand (one foot?), there’s something to be learned from ligature+syntax highlighting+linting text-based authoring experience as a GUI—generalizing a little, we don’t have many other GUIs that attempt to present source data nicely while maintaining it zero-effort for you to drop into low-level edit mode. I wish whatever next-gen structured code authoring experience comes next has implementations that preserve this feature.
Code completion is basically the way you get structured code capabilities in a non-structured editor. Ah, but it was invented to solve an input problem in Alice Pascal (circa 1985) which was totally a structured programming environment, so in a way code completion is a product of the environments you are wishing for.
I don’t know if I’m “wishing for” such environments, I just strongly suspect they will arrive (or they technically should, if they overcome industry’s inertia).
ALICE offered structured editing in a world where graphical output was so limited (and the lacking capability to just enter text in freeform was definitely a dealbreaker). I wonder how such an IDE could look today if rethought from fundamentals after all the advances in making and displaying GUIs.
They've been arriving for the last few decades, but haven't been successful yet. No one has really thought through a fluid efficient editing experience for them that can leverage the benefits of structure without the stilted input entry that the structure seems to imply so far...and our understanding of UI hasn't gotten much better than it was before. Someone might crack it someday, I hope.
The problem is versioning code as structured data. It is not yet here, but there are very recent advances (Pijul et al). Freed from the shackles of LoC, GUIs can do all sorts of magic with structured.
On one hand, I don’t use fonts with ligatures (I use Triplicate by the OP, very happy with it), and usually work without colorful syntax highlighting.
The assumption is that code is read more often than it is written, and I have no idea how my code will be read in future—thus the rule of thumb: if I understand it when it’s plain text monochrome, then the next maintainer (or future me) will be able to understand it with syntax highlighting on. I’m already biased to understand my own code more easily than anyone else, so I shouldn’t need extra visual aids if I’m not the only one who’ll work with it.
Plus, ligatures, syntax highlighting and auto-completion strike me as, in a sense, attempts to create a rudimentary GUI (TUI) to AST on top of plain text—but due to limited capabilities to work with it’s always semi-broken: syntax highlighting is off, ligatures have false positives, etc.
On the other hand, the idea that “we must keep using plain text” strikes me as somewhat stuck in the past.
The age of syntax-tree-driven, program-as-structured-data version control and editing capabilities must not be far off. At that point, we’ll likely get much greater flexibility—highlighting/autocompleting not just tokens but entire patterns (for adequately structured programs), exposing new refactoring operations, and more. We might start seeing cases where a genius high-level architect may not be that proficient at editing programs in plain text, and it’ll be obvious in hindsight.
(As an aside, I’m a little sour that GitHub/MS threw resources onto black-box ethically questionable Copilot rather than structured code.)
On the third hand (one foot?), there’s something to be learned from ligature+syntax highlighting+linting text-based authoring experience as a GUI—generalizing a little, we don’t have many other GUIs that attempt to present source data nicely while maintaining it zero-effort for you to drop into low-level edit mode. I wish whatever next-gen structured code authoring experience comes next has implementations that preserve this feature.