Are 80 Columns Enough? 763
ThinkGeek writes "Dating back to the venerable DEC VT100, the 80 column terminal has served us well for over 25 years. Even now, many open source projects and common conventions require lines of code and documentation to fit on that terminal. I am not alone, judging by code I've seen in and out of the open source world, in finding that number insufficient for coding, much less more verbose writing. Given that modern graphical displays (and all popular editors) are capable of far more, is it time we came up with a new standard-sized terminal? If so, what should the new standard be?"
It wasn't the VT100 (Score:5, Informative)
Re:If your looking for logic in coding conventions (Score:5, Informative)
So in short, 80x25 optimizes memory usage.
If 80 columns ain't enough (Score:3, Informative)
Re:why is this an issue (Score:3, Informative)
Actually most IDE-s wrap it, and while it may be confusing at times, it works mostly well.
Well, most wrap it, except Eclipse. Power of the open source, huh*
* I am an Eclipse user.
Re:why is this an issue (Score:2, Informative)
To be able to have two windows side by side (Score:2, Informative)
80 characters are the most useful convention (Score:1, Informative)
it allows me to keep two or more code files open with no or only limited
overlapping on my 1600x1200 screen. So I don't need to switch between
windows that often. A similar reason applies to administrative work.
Often, I have to use multiple terminal windows in parallel to analyse problems.
Output that relies on a larger width than 80 characters is a real
pain in this context. Since there is no standard, I rescale the window
to get the whole line, just to find out a few pages down that there
is still a longer line. Moving then to other tasks in the same terminal
window, much output requires a lot less than 80 characters. So suddenly
most of the window estate remains unused and I have to scale it down
to make room for other windows on my screen. So I am constantly
resizing my windows.
Also, as others have already said, more than 80 characters are really
bad ergonomically. Even 80 characters are likely already too much.
A good way to reduce the required space for coding is to reduce the
indentation. In our company, we reduced it to two characters, be it
Java, C, Perl or XML. We also abstain from other fancy code formatting
that would waste space, e.g. aligning the right sides in a block of
multiple assignment statements, or indenting following parameters in
the same depth of the first parameter. This works well.
Re:It wasn't the VT100 (Score:1, Informative)
No, it does not. That is an urban legend.
Re:It wasn't the VT100 (Score:2, Informative)
>Urban myth perhaps? There's no relation between screen widths and punch cards.
No myth. FORTRAN before 1977 was firmly attached to 80-character records
with the last eight used only for sequence numbers. If you wanted your terminal
to read/write a FORTRAN program (common 'way back then), it needed 72
characters across. Some terminals (Tektronix 4010 for instance- my first bitmap
screen) had exactly 72 characters.
It bit me once or twice; if a filename was over 72 characters it crashed a shared-resource
analysis program. When we pressed the author, he refused to increase the
filename buffer size, citing the terminal width. Never liked that guy.
Buffersize chauvinism....
Also the ASR33 teletype used 8.5" paper and 10 characters per inch.
Technically, it wasn't limited to 80 characters, BUT if you went over, you
weren't gonna autowrap! The 14" paper in a fullsize lineprinter allowed 132
characters, which is another 'standard' we hear about.
FORTRAN and ASR33 both predate VT100 screens (and VT54 screens, too).
Additional historical info (Score:5, Informative)
Re:First Column! (Score:5, Informative)
This sort of 'data processing' long preceedes programmable digital computers. And the irony is that it's the kinda thing that many people in IT are still involved with. They're only incidentally involved with computers.
Re:First Column! (Score:2, Informative)
Re:First Column! (Score:5, Informative)
IBM's most popular punch cards [wikipedia.org] from the 1920's onwards were 12 rows by 80 columns. A standard 80 x 25 video display can thus display two such cards stacked atop each other, with one row left over for displaying status information.
The cards were initially not intended for binary encodings (although that became possible later), and thus there was no "power of two" basis for them. The 12 rows were enumerated as 0 - 9, with two extra punch zones that acted, in effect, as control characters.
The choice of 80 columns was pretty much arbitrary -- indeed, IBM also made 51 column and 96 column cards at various points. 80 columns was big enough to record an 80-digit decimal number, and had no real special significance that I'm aware of.
And now you know how the worlds most popular punch cards continue to influence our computing experience.
Yaz.
Re:First Column! (Score:4, Informative)
According to a computer documentation class I took (i.e., writing tech manuals), optimal numbers of letters per line for reading is 50-70. With 80 characters per line, most lines will wrap around to be on the high end of that range. As far as readability is concerned, 128 would be "right out".
Anyone know how many average characters per line old-school typewriters had?
Re:First Column! (Score:3, Informative)
Punched cards, baby (Score:3, Informative)
Punched cards (which is how I first programmed) came in 80 and 132 character widths. Since
IBM machines read the punched cards, it was natural for IBM systems to be built on the same widths.
I remember vividly email in the 1980's where if you sent emails with long lines to people on IBM mainframe
machines, the results were basically undefined. Every time that would happen, I would think "punched
cards strike again!"
Re:First Column! (Score:4, Informative)
http://www.boglewood.com/timeline/attila.html [boglewood.com]
http://ancienthistory.about.com/cs/attilathehun/a
http://en.wikipedia.org/wiki/Attilla_the_hun [wikipedia.org]
http://www.newadvent.org/cathen/02061b.htm [newadvent.org]
Also, that the Huns were not the descendants of the Hungarians is a bit in question (see http://en.wikipedia.org/wiki/Maygar [wikipedia.org]).
All this in a story about 80 column terminals. This is, like, a tangent of a tangent of a tangent. But then again, that's what makes
Re:First Column! (Score:4, Informative)
1.
2. Try forths 16 lines of 64 columns.
3. One screen is 1 KB of text, simple.
4.
5. Room on the 80 col screen
6. for line numbers and border.
7.
8. Factoring out code to shorter lines
9. makes for more readable code.
10.
11. Forth also has a shadow screen
12. of comment for each screen of code.
13. Code and shadow both fit on 132 column.
14.
15. Way too simple for amazing complex code.
Re:First Column! (Score:2, Informative)
1) 10cpi (aka Pica) and;
2) 12cpi (aka Elite).
Re:It wasn't the VT100 (Score:3, Informative)
[0] They were bit-addressable video graphics terminals, and didn't scroll. So whenever you hit return on the bottom line, the cursor would just wrap around to the top line and print over whatever was already displayed, so you had to keep smacking the Clear button. Especially amusing when you make a typo in your source and the compiler spits out ten screenfuls of errors...
Re:First Column! (Score:4, Informative)
Dude, that is so not true.
Each column of a punched card was one byte. Each card contained 80 bytes of data, which was one line on a terminal.
Re:First Column! (Score:3, Informative)
80 COlumns is the number of characters of 12 point fixed on a page of paper if you have decent margins. It probably goes back to Gutenberg or Caxton - anyway at least 400 years.
By now people have adapred to it, and our eyes expect 80 columns.
Re:It wasn't the VT100 (Score:4, Informative)
The first railway, colliery lines for transporting coal in the UK were pulled by horses.
Re:why is this an issue (Score:2, Informative)
Enjoy.
Re:First Column! (Score:3, Informative)
Systems Hungarian or Apps Hungarian? [joelonsoftware.com]
Re:First Column! (Score:2, Informative)
Thus a layout was chosen, which was not based on ergonomic principles, but to slow the typer done.
I'm mildly surprised that people still believe this. I thought it had been well-debunked. [straightdope.com]
Re:Not arbitrary. (Score:2, Informative)