4 ms·

While I do a lot on the terminal, not everything is faster there. Jumping between symbols in your IDE is not going to happen faster on the command line because

While I do a lot on the terminal, not everything is faster there. Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it. Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps. There is nothing quite as good as Xcode's instruments on the command line — providing easy to navigate visual representations of your performance and memory use, graphs and other metrics. Having the instruments panel on a second screen is incredibly useful, the extra screen real estate is of real value here. Having to keep switching on a single laptop display is a pain in the ass. Obviously there are many tasks that cannot be easily sped up on the terminal, saving slices out from Photoshop (when your designer hasn't done it properly). And then getting the resulting assets into your pipeline. This stuff is benefited by extra screen space. But the main benefit is being able to see more code at once. And it is especially helpful in large re-factoring operations or with extensive debugging / performance profiling. As I said, it depends on the type of work. I can code just fine on my laptop but I tend to prefer coding focused features, or fixing isolated bugs. I find the previously mentioned profiling and architectural changes are better suited to large screens where more code / graphs / visual assets can be seen at once. You simply can't do "all these things" in a terminal. You can do a hell of a lot, but sometimes you need visuals and sometimes you need space. When you can see more code you don't have to hold as much in your working memory, your eyes can flick back and forth over your code and it makes it easier to see the dependencies and realise what you need to change.

dllthomas 13y ago
"Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it." When the lab I worked in moved between buildings, we each broke down our work stations and set them up in the new spot. I went through a good week of getting work done before I noticed that I hadn't plugged in my mouse - I just never reached for it, because virtually everything happens with a thought when my hands are on the keyboard.
- interpol_p 13y ago
  Most of the time when I'm coding I use the keyboard to jump to symbols. But when you are getting acquainted with a large codebase, reading through and clicking to jump to symbol can be a more efficient way to parse the code and understand its interdependencies. It may depend on what you use to position the cursor as well — I haven't used anything but a trackpad in the last five years, and even on that mostly I use gestures to navigate UI. Since the trackpad is almost part of the keyboard it feels very seamless to scroll/tap and type.
  - dllthomas 13y ago
    Yeah, I'm much more likely to bump a trackpad than reach for a mouse, even when the mouse gives me much more control (I always find trackpads a little finicky), just because of the distance. My hands don't need to actually go anywhere. Of course, I also bump the trackpad accidentally sometimes, but that's a separate issue...
dllthomas 13y ago
"Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps." Being able to see it all at once absolutely helps, but on a big enough console you can see it all just fine. Vimdiff is great. A large monitor definitely adds value there, GUI or TUI.
- interpol_p 13y ago
  Fair enough, I normally use DiffMerge and find it fairly quick at pulling relevant sections from the files being merged. But I agree that the three pane preview is a must.
  - shurcooL 13y ago
    DiffMerge is my all-time favorite visual diff tool, with 2 fatal flaws that upset me so much... 1. Unable to edit text on the left side, only the right. >.< 2. Related to 1, unable to simply paste two pieces of text into two views and compare them, the way you could on www.quickdiff.com. You have to manually create 2 files each time. So sad, because it is so good in all other ways! And it's not open source, so I can't step up and contribute. :(
johndriscoll 13y ago
Although I don't have any problem stitching side-by-side commits in a terminal, or keeping multiple text buffers akimbo in general (its what the terminal is ideal for), I can't argue with most of your points because you're probably 100% correct in the context of your environment and it's limited modes of input (mouse-centric). And you have my sympathies. Being forced to use the mouse is a drag, and I would argue, a cruel thing to do to users from an accessibility standpoint. This (without going deeply into it) is what ultimately binds me to my "limited" set of inputs: keystroke. Yet being bound to the keyboard interface has only helped my productivity. When I get improperly formatted assets from my designer (i know, right?) I can actually do all manipulation, resizing, splitting, converting from the CLI faster than I can send ze an email! (even some minor visual stuff! but my designer fucking hates when i do that so i tend not to anymore.) But your environment and my environment are likely completely different and YMMV.
- interpol_p 13y ago
  As I said, it has more to do with your working memory than with speed or ease of navigation. If you are viewing more code at once (which a larger screen allows you to do) then you can be more productive at certain tasks. I find that large architectural changes, performance profiling, and complex debugging are particular scenarios that lend themselves well to a large screen. This is the point I was making to which you replied with your preference for the command line on a small screen. I am fully aware of how to manipulate image assets on the command line. Most computer vision and computer graphics tools I have written are executed via the command line so they can be pushed into my build phase. But I deal regularly with many formats from many tools, and not all of them can be dealt with easily on the command line. The command line is not immediately better than everything — most visual oriented tools use keyboard shortcuts. You may not realise this, but committing those shortcuts to muscle memory makes using graphical applications just as fast, if not faster, than many tasks on the command line. Do you also do all your performance profiling on the command line? Because that is a situation where visual data is very helpful, and a visual interface is in general more efficient and faster to navigate than the same on a command line. As I said elsewhere, I do not use a mouse at all, so I do not have a mouse-centric workflow. I use the trackpad centimetres from my keyboard for gestures. This only requires slightly more physical motion than pressing a key, and ties itself just as strongly to muscle memory. I also use a graphics tablet for design, painting, and 3D modelling. And to repeat, my initial point relating to large screens still stands. If you can see more code at once (whether on the command line or not, who cares?) then you do not need to commit as much to your working memory, and you can more productively make large scale changes that effect a lot of dependent code. Same goes for performance profiling and debugging. The more info you can have up at once, the more you can dedicate your mind to reasoning about the problems at hand and the less you switch back-and-forth between views.

dllthomas 13y ago

"Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it." When the lab I worked in moved between buildings, we each broke down our work stations and set them up in the new spot. I went through a good week of getting work done before I noticed that I hadn't plugged in my mouse - I just never reached for it, because virtually everything happens with a thought when my hands are on the keyboard.

interpol_p 13y ago
Most of the time when I'm coding I use the keyboard to jump to symbols. But when you are getting acquainted with a large codebase, reading through and clicking to jump to symbol can be a more efficient way to parse the code and understand its interdependencies. It may depend on what you use to position the cursor as well — I haven't used anything but a trackpad in the last five years, and even on that mostly I use gestures to navigate UI. Since the trackpad is almost part of the keyboard it feels very seamless to scroll/tap and type.
- dllthomas 13y ago
  Yeah, I'm much more likely to bump a trackpad than reach for a mouse, even when the mouse gives me much more control (I always find trackpads a little finicky), just because of the distance. My hands don't need to actually go anywhere. Of course, I also bump the trackpad accidentally sometimes, but that's a separate issue...

dllthomas 13y ago

"Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps." Being able to see it all at once absolutely helps, but on a big enough console you can see it all just fine. Vimdiff is great. A large monitor definitely adds value there, GUI or TUI.

interpol_p 13y ago
Fair enough, I normally use DiffMerge and find it fairly quick at pulling relevant sections from the files being merged. But I agree that the three pane preview is a must.
- shurcooL 13y ago
  DiffMerge is my all-time favorite visual diff tool, with 2 fatal flaws that upset me so much... 1. Unable to edit text on the left side, only the right. >.< 2. Related to 1, unable to simply paste two pieces of text into two views and compare them, the way you could on www.quickdiff.com. You have to manually create 2 files each time. So sad, because it is so good in all other ways! And it's not open source, so I can't step up and contribute. :(

johndriscoll 13y ago

Although I don't have any problem stitching side-by-side commits in a terminal, or keeping multiple text buffers akimbo in general (its what the terminal is ideal for), I can't argue with most of your points because you're probably 100% correct in the context of your environment and it's limited modes of input (mouse-centric). And you have my sympathies. Being forced to use the mouse is a drag, and I would argue, a cruel thing to do to users from an accessibility standpoint. This (without going deeply into it) is what ultimately binds me to my "limited" set of inputs: keystroke. Yet being bound to the keyboard interface has only helped my productivity. When I get improperly formatted assets from my designer (i know, right?) I can actually do all manipulation, resizing, splitting, converting from the CLI faster than I can send ze an email! (even some minor visual stuff! but my designer fucking hates when i do that so i tend not to anymore.) But your environment and my environment are likely completely different and YMMV.

interpol_p 13y ago
As I said, it has more to do with your working memory than with speed or ease of navigation. If you are viewing more code at once (which a larger screen allows you to do) then you can be more productive at certain tasks. I find that large architectural changes, performance profiling, and complex debugging are particular scenarios that lend themselves well to a large screen. This is the point I was making to which you replied with your preference for the command line on a small screen. I am fully aware of how to manipulate image assets on the command line. Most computer vision and computer graphics tools I have written are executed via the command line so they can be pushed into my build phase. But I deal regularly with many formats from many tools, and not all of them can be dealt with easily on the command line. The command line is not immediately better than everything — most visual oriented tools use keyboard shortcuts. You may not realise this, but committing those shortcuts to muscle memory makes using graphical applications just as fast, if not faster, than many tasks on the command line. Do you also do all your performance profiling on the command line? Because that is a situation where visual data is very helpful, and a visual interface is in general more efficient and faster to navigate than the same on a command line. As I said elsewhere, I do not use a mouse at all, so I do not have a mouse-centric workflow. I use the trackpad centimetres from my keyboard for gestures. This only requires slightly more physical motion than pressing a key, and ties itself just as strongly to muscle memory. I also use a graphics tablet for design, painting, and 3D modelling. And to repeat, my initial point relating to large screens still stands. If you can see more code at once (whether on the command line or not, who cares?) then you do not need to commit as much to your working memory, and you can more productively make large scale changes that effect a lot of dependent code. Same goes for performance profiling and debugging. The more info you can have up at once, the more you can dedicate your mind to reasoning about the problems at hand and the less you switch back-and-forth between views.