[interpol_p]

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]

"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]

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]

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]

"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]

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]

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]

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]

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.

[johndriscoll]

To your repeated point: It's been my experience that better knowing what the code is doing leads to improving it. I am not a smart or clever person. I can only see one focal point at a time. But with enough time (and a trivial screen resolution) I feel that I can understand and improve on something as complex as the operating system running my computer, which is some very big software with parts of it (big and small) written in the early 80's on 80 character wide screens. This probably applies to everyone's operating system, so I'm just using it to juxtapose my next subject, which is the nightmare project (and I'm not making any of it up).

Looking back on the nightmare project almost makes me cry until I manage to suppress its memory. The difference between this project and my operating system is that my operating system is written by people who need to maintain software for a long time and, at some random point in the future, will need to rely on the maintainability of the code they wrote a lifetime ago. My nightmare project was not written with the project in mind, let alone the future of the project. Its problems were far removed from screen resolution. Its problem was the programmer. The programmer made it as painful as possible for me to understand what ze had written.

There was no abstraction and the code's entry point invoked every procedure the project directly in various loops. There was no difference represented between the software's big wheels and tiny gears. This made large scale changes difficult because dependent code had no typed contract, just access to buffers and primitives passed around in what was essentially a big main().

There was no cohesion of modules in the project and procedures just appeared together grouped seemingly at random and given names project1.x, project2.x, etc. Even if I had enough screen real estate to have the whole project's source open simultaneously, I would have been just as lost as when I was trying to wrap my head around a single file.

There was never a consideration for inversion of control and all the flow parameters were hard coded paths in giant conditional nests all throughout the project. That made simply guessing which code paths to analyze for a given input difficult.

Seeing more bad code doesn't make fixing it any easier and seeing more good code doesn't help me understand it any faster. When it comes to code, there are many factors influencing how productive I will be at working on it and screen resolution should be down there on the list, hopefully near the bottom.

"You may not realise this, but"

Was that necessary?

"committing those shortcuts to muscle memory makes using graphical applications just as fast, if not faster, than many tasks on the command line."

What's even better about the command line is that you can pipe input and output between applications. Chaining commands and remaining on the cli is faster for me than switching between applications and opening files. Most UIs have no way to define macros for commonly used procedures, whereas you can script anything cli-based.

"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."

I do. I lack the sensory to monitor more than a couple metrics at once. I prefer profiling data that can be captured and analyzed later.

[interpol_p]

> To your repeated point: It's been my experience that better knowing what the code is doing leads to improving it. I am not a smart or clever person.

Here is the example I am dealing with right now. I have spent the last few months designing and implementing a complex system. It consists of hundreds of components and tens of thousands of lines of code. This project is reasonably small and I can keep most of the mental model "in my head" at once. So it's appropriate to edit on my laptop screen — or any screen. I can usually think of which symbol I need to jump to and within seconds I can be positioned in the editor, at that symbol.

Today I have had to take that component and push it into the rest of the system, which is hundreds of thousands of lines of code and it is a codebase that I have created over three years. I can't keep this all in my head, and this is where having a large screen produces noticeable productivity improvements and speed improvements to problem solving.

It is not a matter of not being able to jump around the code instantly from my keyboard — I can do that easily. It is knowing and remembering where to go and what I'm supposed to be working on. It is trying to maintain context while handling the many hundreds of errors that come about due to the necessary integration, API and architectural changes.

When I have a large screen I can afford to maintain a long list of files in a column on the left, I can see more large files at once. This allows me to constantly refresh my memory. I can glance at the data in front of me to determine what symbol I need to jump to next. I often mentally blank out when dealing with this level of scale — that "what was I about to edit?" feeling. When I am only on my laptop screen I have to start pulling up code, tracing a path back through it to redevelop context. When I have a large screen I can (usually) rebuild this context by glancing at the existing information.

(Note that this is not a messy project, I have spent a long time and given very careful thought to its design. It is just large and necessarily complex because of what it has to do. A bigger screen makes it faster to develop large scale interactions in such a project.)

> Was that necessary?

I'm sorry about that. It wasn't.

> What's even better about the command line is that you can pipe input and output between applications.

I have nothing against the command line — I use it all the time. I just like to take the most efficient path when working and sometimes that is not the command line. But that is tangential to the large screen point above.

> I do. I lack the sensory to monitor more than a couple metrics at once. I prefer profiling data that can be captured and analyzed later.

I had meant to ask if you analyse your profiling data on the command line. Do you?

[johndriscoll]

My operating system is a huge and complex beast. But a lot it, if not most of, is modularized in a way that extending it never requires my touching any of its source files. It assumes a mission statement to the user (I'll make one up and say it's "I will organize your computer's resources and let you use them easily") and code contracts that allow multiple components to serve this goal. Internally, the components are abstracted into statements of a very simple logic-flow.

This paradigm persists in many components themselves, from the bootloader to the end-user. When I want to update something in user space, it involves, from my perspective, no interaction with the operating system (even though it is really the one doing everything). Conversely if I want to do something as advanced as completely rewrite my filesystem implementation (something my operating system is very dependent on), I can, and without ever needing to touch my operating system's source. I could come up with any ridiculous way for a filesystem to work, and my operating system would be cool with it, and would operate the same way because if its modularized and abstracted design.

I would say these are incredibly good design features and that you would have to be extremely hard pressed to find a system that inherently cannot be designed in such a way as to mitigate maintainability and trivialize extensibility. Is your top-level project inherently so complex that adding smaller pieces requires that much screen real estate? If so, you have my sympathies.

> I had meant to ask if you analyse your profiling data on the command line. Do you?

Yes, my command-line editor has some powerful cvs support and manipulation features that make slicing the data up very easy.

[interpol_p]

My argument is that in some cases large displays make coding more efficient.

In particular when navigating a large codebase, rewriting or refactoring an existing design, and other similar tasks. Your argument sounds to me like "If I write perfect code, I will never need to touch old code again and thus do not need a large screen."

It doesn't matter how big or well designed something is. There are going to be cases where you need to revisit, redesign, or rewrite. Your suggestion that you should just write code perfectly the first time assumes you know the perfect design for the problem at hand — the perfect design is not obvious in many cases, not until your code is used in production and many features have been added on top of it do you begin to think that you can revisit it.

In my case, I am writing a graphics engine, code editor, parser/AST builder, documentation viewer, and project management system. As well as managing documentation and strings localised in 20 different languages.

I have re-written the code editor three times now, each time I have carefully considered the design and how I could proceed with a multi-threaded, efficient editor free from rendering bugs and able to handle large amounts of data. At this point I think I have a great design and implementation, but it is far from perfect. Much of it was developed on my plain old small laptop screen.

Recently I pulled all old networking code from the system and re-wrote it using newer and better high-level APIs that have since become available. This task was benefited by a larger screen because I could look at old and new implementation, while looking at a second new implementation from a different area of the code base as reference — while also still having room for API documentation and related files. It just made things faster, it would still be possible on a small screen.

When I profile the OpenGL graphics engine being able to correlate performance graphs with locations in the code, while displaying GPU buffer contents is something that would feel quite clunky on the command line. It's also faster to be able to glance at this data with my eyes without having to flip between windows / contexts.

So my top level project is complex, but I never claimed it required much screen real estate. It can be more comfortable and faster to perform certain tasks with a large screen — which reduces the need for mental context switching. That's what I'm arguing and I find it hard to understand why you are arguing against this point.

> If so, you have my sympathies.

Your attitude seems quite condescending. As if my code is poorly designed and unmaintainable. This is not the case.

As I said: coding does not require extra screen real estate. It can just be more comfortable and more efficient when you have it.