Hacker News Reader

Comment by sago | Hacker News Reader

Right, and that means we can have more code on screen, and docs and tests, and shell. Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces.

The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time.

What proportion of your code lines are > 80 cols? Multiply that by the amount of extra width to get the wasted screen estate. I'll take that and put more code/docs/tests/output on my screen at the same time and have to toggle less.

The idea that this is about teletype is very amusing, but rather naive.

View on HN

>Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces.

Even on a widescreen laptop you can have 2 > 100 lines windows side by side. And for multi-monitor setups you can go even wilder.

>The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time.

If you have tons of junk in front of you, you're not focusing on your code as you should be.

Right, I can fit 2x100 cols, or 3x80 cols + a project view. So I can see my code, its tests, and either the shell (i.e. test results, ipython, debugger, tail -f logfile) or a web browser for documentation.

Is that junk?

How many of your lines require that 100 columns, in your average code?

Of course, this can just descend into a pissing contest. The point isn't who-has-the-most-windows, but that the logic of 80cols has a practical point, and programmers who continue with the default have reasons that aren't just about teletype or not moving with the times.

>* So I can see my code, its tests, and either the shell (i.e. test results, ipython, debugger, tail -f logfile) or a web browser for documentation.*

Did someone stole the lower part of your screen? Or do you have all views in parallel, instead of say stacked vertically?

I could cut half of my editors off, of course. But then I'm loosing even more context. And I have a shell output that is full width but not very tall, so I can't see as much context, and I have to scroll my code more. Again, this isn't a pissing contest. The point is that there are reasons people prefer it. What are you trying to argue? It seemed you were trying to suggest it is purely a historic throwback and pointless.

It all comes back to this question: what proportion of lines in your code use more than 80 cols? If it is a small proportion, the geometry is simple: you waste more screen by having longer lines.

>It all comes back to this question: what proportion of lines in your code use more than 80 cols? If it is a small proportion, the geometry is simple: you waste more screen by having longer lines.

It's obviously always gonna be a small proportion. Nobody write > 80 lines all the time (or should).

But just because you accept > 80 lines doesn't mean you have to have the editor to > 80 width. You can just let it either wrap them or cut some lines off and scroll when you want to check them (what I do).

I don't buy that somehow this "80 characters per page" is some magic number that holds true from the teletype days to today, and it should be respected regardless of font size, monitor width, etc.

> it should be respected regardless of font size, monitor width, etc.

I don't think anyone would suggest it is magic. It is a convention that is somewhere near to being good, and is so widely used that it is heavily tool supported, so you should have a good reason not to use it.

Actually, 80 is a bit of a misnomer, PEP8 has it at 79, git convention is 72 (50 for first line, to allow git log to display sha-summary inline and fit into 80 cols), etc.

> You can just let it either wrap them or cut some lines off and scroll when you want to check them (what I do).

Ah, I see. In which case I take back many of my objections. I see what you're saying now. Thanks.

I rarely find myself wishing to split my screen. It's not that I don't know that I can, and occasionally I will (especially if two pieces of code happen to be VERY tightly coupled, with lots of passing back and forth between the two). In general, however, I find that since I am only reading one line of code at a time, having two editor windows up is pointless. It's like having two browser windows instead of two tabs in a browser window.

Plus, with most editors that can jump in / out of functions, it's not like I'm losing my place. In fact, my editors all save my place in files on exit.

Interesting, do you do much unit testing for code you write?

And you know you can put different parts of the same file in columns too? I often need to write code that is coupled to another part of the same file.

80 columns of text is wonderful in my dual window vim with NERDTree on the left. All my screens are some version of the 1680x1050 aspect ratio and it fits perfectly. I'm always using 2 windows for simultaneous code/test writing, diffing, and multiple windows into different parts of the same buffer, multiple files open etc.

Unfortunately, at my current job, we don't seem to believe much in unit testing. There's some indication this may change in the near future.

Additionally, I have two screens, and since I mainly use a tiling window manager, 80 columns works... okay. But 80 columns isn't usually where my splits end.

Interesting point with the same file in columns. It's rather that I do that. More often I'll be looking at the same file across two branches. I am kind of surprised that we don't see more plugins doing 80 column lines, in sequence, to fill the screen however. More lines on the screen seems to be the craving that vertical monitors + high-res monitors aim to satiate.

Reply on news.ycombinator.com