> An analogy I like is a powered exoskeleton: if you had one you could run faster and jump higher and all these good things: but then when it breaks or you're not wearing it you've less native ability and no familiarity with the unassisted world, which makes you dependent on the tools.
Assistive technology is the result of historical progression, so why eschew auto completion because it might fail when you don’t eschew your computer which might fail as well? Should we all just be programming on pen and paper because that’s lower down the progression stack and has less chance of failing? You know that argument was probably made in the 70s by some old school programmer when those fancy new interactive terminals started coming out (I believe dijkstra actually said something to this effect, but can’t find a source).
> Should we all just be programming on pen and paper because that’s lower down the progression stack and has less chance of failing?
Yes. Not because of the resiliency (it's hard to imagine a failure mode where pen-and-paper programming would be the only option) but because it makes you better at your craft.
I mean, sure. We should always know the stack down to the electrons. Not only should we learn to code on paper, but build our own adders from primitive boolean logic gates. But this doesn't really follow (most of) us out of our BS computer science program (or perhaps until we have to do programming interviews).
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.
I wish people wouldn't indulge in these luddite fantasies of some ancient caste of ninja programmers. It's blatantly wrong to the point where I'm not sure if the above is not meant as a joke.
It's also insincere: do you regularly write out code with pen & paper? No, of course not. Nobody does. Just like nobody reads all the fine print, checks the emergency exits every time they enter a building, has an emergency drinking water reservoir, or a go-bag for volcano emergencies: these are teenage fantasies of what grown-up life should be like. Believing and propagating these ideas only sets you and your listeners up for failure.
I spend a lot of time thinking through problems with pen and paper, and also highlighter and printer, and whiteboard. I've found this class of tools often lets me focus on a problem with less distraction.
It's not always the right tool, and of course the code must be typed up sooner or later.
I often work in environments where the development cycle time is terribly slow for one reason or another, which puts a premium on thinking through things ahead of time.
Assistive technology is the result of historical progression, so why eschew auto completion because it might fail when you don’t eschew your computer which might fail as well? Should we all just be programming on pen and paper because that’s lower down the progression stack and has less chance of failing? You know that argument was probably made in the 70s by some old school programmer when those fancy new interactive terminals started coming out (I believe dijkstra actually said something to this effect, but can’t find a source).