37 ms·

> Unlike traditional text-based editors, these tools treat code as a structured tree rather than a flat sequence of characters. This is such an obvious lie...

> Unlike traditional text-based editors, these tools treat code as a structured tree rather than a flat sequence of characters. This is such an obvious lie... Of course, even the disastrously bad editors like VSCode or IntelliJ tools understand code to have structure and allow interaction with that structure. Hell, even text editors not intended to deal with code will usually be able to deal with some structure, like identifying words, lines, perhaps even paragraphs and operating on them. > No syntax errors. Zero time is spent on missing quotes, semi-colons or other details. Usually paid for by inability to copy and paste chunks of code... not sure if it's worth the price. > Better type information. Because the program is always in a valid state the type checker can always run and give meaningful feedback. Why would you want to run typechecker all the time? What's the benefit? I run it when I'm interested in the results... otherwise it's just noise. By the time I'm interested in results, I'd get code in a decent enough shape to compile, so it won't be a problem. Other known downsides of this approach: having to access the code in places where the editor isn't available, s.a. reading diffs, debugging, running third-party tools unaware of structured format (which, given how our programming practices have developed, will be inconsistent between versions and platforms). All in all, I've seen these attempts multiple times before, and it always looks like the benefits simply aren't worth the effort. Or, maybe, too many stars need to align in order for this to actually become really useful in the day-to-day programming work, and so it doesn't happen because of some circular dependency where the tools won't be built, until the product is good enough to use, but the product is never good enough to use because there aren't any tools?

lsaferite 2y ago
> disastrously bad editors like VSCode or IntelliJ tools I'm curious, what code editor(s) do you hold in high esteem?
- crabbone 2y ago
  Editors that are geared towards advanced users, i.e. they allow mostly or completely keyboard-driven interaction (to increase precision of actions), editors that are rich in the way that they understand and navigate text, i.e. they offer multiple paradigms of text navigation, be it by structure, by line, by mini-map, the "jedi" style. Editors that allow substantial automation and extensibility without a massive effort on the user end, possible ad hoc, rather than requiring a full-fledged programming project. Editors with multiple existing integrations with third parties, but also allowing for a relatively easy addition of such interactions. Editors that aren't overly reliant on third-party software to function (i.e. can function when X-Server isn't available, or when Web isn't available). Some anti-features that are preferably be missing from good editors: unnecessarily constraining user to the choices the editor designer or the editor administrator deemed necessary. Excluding particular functionality from automation or requiring substantial workarounds in order to automate particular aspects (eg. having functionality associated with a button that can only be clicked by positioning the mouse cursor over it, or, even worse, functionality that is only available through drag-and-drop). Reliance on modal windows. Automatic editing and formatting of editor-related configuration files in a way that doesn't preserve user's edits and formatting. In other words, it's possible to take a decent editor, like Emacs or Vim and turn it into a bad editor like VSCode or IDEA by doing bad things to it because the base is very extensible. But, in general, excluding the administrative / repackaging component, editors like Emacs or Vim will win in this contest.

lsaferite 2y ago

> disastrously bad editors like VSCode or IntelliJ tools I'm curious, what code editor(s) do you hold in high esteem?

crabbone 2y ago
Editors that are geared towards advanced users, i.e. they allow mostly or completely keyboard-driven interaction (to increase precision of actions), editors that are rich in the way that they understand and navigate text, i.e. they offer multiple paradigms of text navigation, be it by structure, by line, by mini-map, the "jedi" style. Editors that allow substantial automation and extensibility without a massive effort on the user end, possible ad hoc, rather than requiring a full-fledged programming project. Editors with multiple existing integrations with third parties, but also allowing for a relatively easy addition of such interactions. Editors that aren't overly reliant on third-party software to function (i.e. can function when X-Server isn't available, or when Web isn't available). Some anti-features that are preferably be missing from good editors: unnecessarily constraining user to the choices the editor designer or the editor administrator deemed necessary. Excluding particular functionality from automation or requiring substantial workarounds in order to automate particular aspects (eg. having functionality associated with a button that can only be clicked by positioning the mouse cursor over it, or, even worse, functionality that is only available through drag-and-drop). Reliance on modal windows. Automatic editing and formatting of editor-related configuration files in a way that doesn't preserve user's edits and formatting. In other words, it's possible to take a decent editor, like Emacs or Vim and turn it into a bad editor like VSCode or IDEA by doing bad things to it because the base is very extensible. But, in general, excluding the administrative / repackaging component, editors like Emacs or Vim will win in this contest.