4 ms·

If you really care about the process and how everything works, I don't see how you can beat vim/emacs + command-line. Ultimately text interfaces will always be

If you really care about the process and how everything works, I don't see how you can beat vim/emacs + command-line. Ultimately text interfaces will always be easier to manage and give the lowest resource utilization

MaulingMonkey 10y ago
> If you really care about the process and how everything works, I don't see how you can beat vim/emacs + command-line. Ultimately text interfaces will always be easier to manage A few things I think text interfaces are, or tend to be, terrible at: Profiling information (can't beat flame graphs) Graphics debugging, previewing UI layouts (text is terrible at displaying the results of pixel shaders) Discoverability (VS has so much UI up front to discover that it's literally overwhelming for some, a vim user will hit the manual to figure out how to even get into insert mode...) Manipulating and viewing many tree and node based structures (shader graphs, parallel stacks, ...) Even basic scrolling (map style scrollbars are wonderful for large files in alien codebases...) Even basic intellisense requires text interfaces to awkwardly pretend they're a real user interface with ncurses or the like. VS has it's drawbacks - it's a hard-to-extend monolith, there are too many blocking operations are on the UI thread, it hits the disk too much, etc. - but I've seen these issues in text based tools as well. The problem isn't that it should be text based. > Ultimately text interfaces will always [...] give the lowest resource utilization I want to maximize the useful utilization of my time. "Lowest resource utilization" is not a goal. "Most efficient resource utilization" might be getting there, but I'll happily eat some wasted CPU time on the off chance it'll mean less wasted mind time. Powered down silicon is a wasted investment.
- brian-armstrong 10y ago
  Although I can't contend the other points, I've had good experience with profiling in the command line. I find that quantified tick counts/cpu time is actually easier to read than are flame graphs edit: but yeah, if you're doing graphics work, you certainly want a graphical editing environment
- throwanem 10y ago
  I mean sure, if you're manipulating data that isn't textual, you're going to want some non-textual interface to it. Code is text. Editing it as text makes a lot of sense. As for your points about map scrollbars and completion UI, I can't speak for Vim, but Emacs has had graphical capabilities for a long time and does both of those things quite handily. I don't see the point of map scrollbars and I use code completion only sporadically, but they're there if you want them, as are many other perhaps surprising things, and Emacs doesn't feel a need to show off and get in my way as I've found more heavyweight tools like Visual Studio to do. (And what a world we live in, where Emacs can reasonably be called lightweight by comparison with anything...)

MaulingMonkey 10y ago

> If you really care about the process and how everything works, I don't see how you can beat vim/emacs + command-line. Ultimately text interfaces will always be easier to manage A few things I think text interfaces are, or tend to be, terrible at: Profiling information (can't beat flame graphs) Graphics debugging, previewing UI layouts (text is terrible at displaying the results of pixel shaders) Discoverability (VS has so much UI up front to discover that it's literally overwhelming for some, a vim user will hit the manual to figure out how to even get into insert mode...) Manipulating and viewing many tree and node based structures (shader graphs, parallel stacks, ...) Even basic scrolling (map style scrollbars are wonderful for large files in alien codebases...) Even basic intellisense requires text interfaces to awkwardly pretend they're a real user interface with ncurses or the like. VS has it's drawbacks - it's a hard-to-extend monolith, there are too many blocking operations are on the UI thread, it hits the disk too much, etc. - but I've seen these issues in text based tools as well. The problem isn't that it should be text based. > Ultimately text interfaces will always [...] give the lowest resource utilization I want to maximize the useful utilization of my time. "Lowest resource utilization" is not a goal. "Most efficient resource utilization" might be getting there, but I'll happily eat some wasted CPU time on the off chance it'll mean less wasted mind time. Powered down silicon is a wasted investment.

brian-armstrong 10y ago
Although I can't contend the other points, I've had good experience with profiling in the command line. I find that quantified tick counts/cpu time is actually easier to read than are flame graphs edit: but yeah, if you're doing graphics work, you certainly want a graphical editing environment
throwanem 10y ago
I mean sure, if you're manipulating data that isn't textual, you're going to want some non-textual interface to it. Code is text. Editing it as text makes a lot of sense. As for your points about map scrollbars and completion UI, I can't speak for Vim, but Emacs has had graphical capabilities for a long time and does both of those things quite handily. I don't see the point of map scrollbars and I use code completion only sporadically, but they're there if you want them, as are many other perhaps surprising things, and Emacs doesn't feel a need to show off and get in my way as I've found more heavyweight tools like Visual Studio to do. (And what a world we live in, where Emacs can reasonably be called lightweight by comparison with anything...)