Learned how to render graphics the hard way in Apple BASIC back in grade school. Was fun.
Hm, interesting, I'm simply not sure then. Oh, well. Maybe I'll try it again another day. For now I'm content with emacs.
Installed it, why not. Tried to run it.
error opening [PathLikeWithPosition { path_like: "/home/me/test", row: None, column: None }]: NoSupportedDeviceFound
Then tried it in Xorg, and it runs normally. I guess it doesn't run in Wayland?
...
So, I gave it a short test drive. Observations:
- UI is nice and minimal
- Window splitting is useful
- Key bindings don't seem to do anything
- Command palette commands don't seem to do anything
- Editor appears to crash if I switch to a virtual terminal then back to Xorg
Suspect it's shooting to be something like sublime text. Cool, but seems like there's a lot of work to be done.
And isn't it such a dangerous overlap! The coder whose writing (in their native language) is unclear, repetitive, convoluted, or hard to follow too often produces code with the same qualities. It's even worse when the same coder believes "code is self-documenting" without considering why. Code self-documents with careful and deliberate effort, and in my experience, it is the really good writers who are most capable of expressing code in this way.
The person who changed the code, it's just ordinary maintenance. The comments may not execute, but I submit they are as much a part of the program as the executable code. Maybe over time those comments are condensed, or even removed; no different than any other refactoring or cleanup.
An autistic coder would have documented this feature to the point of pedantry.
I actually agree that "good enough" code can be self-documenting, but it isn't always enough to achieve my goal which is to make the code understandable to my audience with minimal effort. With that goal in mind, I write my code as I would write a technical document. Consider the audience, linear prose, logical order, carefully selected words, things like that... In general, I treat comments as a sort of footnote, to provide additional context where helpful.
There are limits to self-documenting code, and interfaces are a good example. With interfaces, I use comments liberally because so many of the important details about the implementation are not obvious from the code: exactly how the implementation should behave, expected inputs and outputs under different scenarios, assumptions, semantic meaning, etc. Without this information, an implementation cannot be tested or verified.
I vividly remember some of the garbage code I've written in the past. Huge interface definitions... Weird and brittle abstractions... Overly complex processes to do what should have been a simple task...
Funny thing is, I read and understood the same kinds of things as any other coder worth their salt: agile, SOLID, YAGNI, do one thing well, and so on -- but it was all just theory. It takes experience and mistakes to really grok it all.
I've had a colleague or two like that before. "I'm willing to put in the work to fix the code" is something I would hear, as if it were some kind of virtue. To their credit, people like this move mountains to make shit work, and it usually does. Yet, trying to read and understand their code (much less change it) is a Sisyphean endeavor.
Nowadays I use devil with mostly-vanilla keybindings, but I will happily recommend evil-mode for vimmers finishing their penance. For something more feature-rich, there is also doom and spacemacs.