6 ms·

What kind of navigation are you relying on that could not possibly work faster on a terminal? Horrible ascii graphs look horrible, but they are arguably more f

by dangom 8y ago

What kind of navigation are you relying on that could not possibly work faster on a terminal? Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.

lm28469 8y ago
Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.
- TeMPOraL 8y ago
  I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs. With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.
  - NateEag 8y ago
    I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol: https://code.visualstudio.com/api/extension-guides/debugger-extension https://code.visualstudio.com/api/extension-guides/debugger-... I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
    - TeMPOraL 8y ago
      Wow, thanks! And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true! [0] - https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode [1] - https://github.com/puremourning/vimspector https://github.com/puremourning/vimspector
      - NateEag 8y ago
        Awesome - glad to be of assistance!
- flukus 8y ago
  > Navigation is rarely the limiting factor in development speed Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
  - lm28469 8y ago
    > Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. Isn't that a test coverage issue more than a navigation issue ? Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
    - flukus 8y ago
      Code coverage is really high, legend has it that code coverage was tied to bonus a decade ago. The tests typically add more mental overhead than reduce it due to this. > Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage. It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.
olig15 8y ago
Visual Assist X is a VS plugin that everyone I know seems to have pre-installed wherever they work. It allows things like jump to file/symbol using a keyboard shortcut and fuzzy search. I imagine there's equivalent with vim, etc, but I also don't see how a terminal could be better/faster. Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.
- jdright 8y ago
  I'm in gamedev too, I basically do debugging for living with eventual actual development. Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio. I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive. I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.
BurningFrog 8y ago
If anyone told you you can't navigate IDEs with a keyboard, they lied.
pjc50 8y ago
This isn't Starcraft, very few developers are limited by their APM throughput through the UI.
- gambler 8y ago
  >This isn't Starcraft, very few developers are limited by their APM throughput through the UI. Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.
  - TeMPOraL 8y ago
    > However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency. That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up. > You can become more efficient at low-level tasks by doing faster text editing. It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units. Also, for actual software engineering, nothing beats a pen and a piece of paper.
    - kbutler 8y ago
      > Also, for actual software engineering, nothing beats a pen and a piece of paper. Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.
      - TeMPOraL 8y ago
        Personally, I use pen and paper (and a whiteboard) almost exclusively to draw and jot down very short notes. I do plenty of longer outlining when designing too (much more than drawing), and that happens in my text editor (Emacs, Org Mode).

by dangom 8y ago

lm28469 8y ago

Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.

TeMPOraL 8y ago
I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs. With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.
- NateEag 8y ago
  I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol: https://code.visualstudio.com/api/extension-guides/debugger-extension https://code.visualstudio.com/api/extension-guides/debugger-... I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
  - TeMPOraL 8y ago
    Wow, thanks! And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true! [0] - https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode [1] - https://github.com/puremourning/vimspector https://github.com/puremourning/vimspector
    - NateEag 8y ago
      Awesome - glad to be of assistance!
flukus 8y ago
> Navigation is rarely the limiting factor in development speed Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
- lm28469 8y ago
  > Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. Isn't that a test coverage issue more than a navigation issue ? Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
  - flukus 8y ago
    Code coverage is really high, legend has it that code coverage was tied to bonus a decade ago. The tests typically add more mental overhead than reduce it due to this. > Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage. It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.

olig15 8y ago

Visual Assist X is a VS plugin that everyone I know seems to have pre-installed wherever they work. It allows things like jump to file/symbol using a keyboard shortcut and fuzzy search. I imagine there's equivalent with vim, etc, but I also don't see how a terminal could be better/faster. Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.

jdright 8y ago
I'm in gamedev too, I basically do debugging for living with eventual actual development. Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio. I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive. I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.

BurningFrog 8y ago

If anyone told you you can't navigate IDEs with a keyboard, they lied.

pjc50 8y ago

This isn't Starcraft, very few developers are limited by their APM throughput through the UI.

gambler 8y ago
>This isn't Starcraft, very few developers are limited by their APM throughput through the UI. Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.
- TeMPOraL 8y ago
  > However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency. That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up. > You can become more efficient at low-level tasks by doing faster text editing. It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units. Also, for actual software engineering, nothing beats a pen and a piece of paper.
  - kbutler 8y ago
    > Also, for actual software engineering, nothing beats a pen and a piece of paper. Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.
    - TeMPOraL 8y ago
      Personally, I use pen and paper (and a whiteboard) almost exclusively to draw and jot down very short notes. I do plenty of longer outlining when designing too (much more than drawing), and that happens in my text editor (Emacs, Org Mode).