Hacker News Reader

Comment by lisper | Hacker News Reader

The article has the causality backwards. We don't use 80 characters because that's what the Hollerith card used, the Hollerith card used 80 characters because that's a good ergonomic width. (Or, if you prefer, the Hollerith card succeeded because it was a good ergonomic width.)

Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line, not because it's bound by the Hollerith card, but because 80 characters is a good ergonomic width.

View on HN

I researched Hollerith cards and 80-character lines in excessive detail while studying card sorters [1]. The Hollerith card is the root cause of 80-character lines, of course. Prior to 1928, Hollerith cards used round holes and 45 characters per card. IBM wanted to fit more data on a card and investigated two alternatives: binary coding so 90 characters could fit into 45 columns of holes, or rectangular holes which allowed narrower holes so 80 columns would fit. They chose the latter because it was more compatible with existing card sorting equipment, and the rest is history. Competitors used 90 column cards, but didn't achieve the same success as IBM. IBM later introduced 96-column cards, but they weren't as popular. Thus, it's just a historical accident that everyone uses 80 columns rather than 90 or 96. And 80 columns is used because that's how many could fit on a punched card the size of obsolete US currency. Note that ergonomics has nothing to do with the success of 80 columns: for the most part these cards held accounting data, not program code or text. (I wrote an article covering this in great detail but haven't posted it to my blog yet; hopefully I'll get it out soon.)

[1] http://www.righto.com/2016/05/inside-card-sorters-1920s-data...

The facts you cite are true, of course, but it does not follow that the H-card was the cause of 80-character lines. We've had plenty of opportunities to ditch that standard if we wanted to. The Apple II had 40 characters per line. That went by the wayside not because there was a compelling reason to be backwards-comatible with H-cards, but simply because 40 characters is too short. When longer lines were enabled by technology we went to 80 rather than (say) 132 because 132 is too long. We can quibble over 80 vs 90 or 96 (or 72), but it's pretty clear that the sweet spot is right in there somewhere. It is not at all like (say) electrical outlets where we really do have to do deal with all kinds of crazy incompatibilities when traveling for no reason other than historical accident.

The jump to 80-column video displays was due to late 1960s CRT-based computers for data entry such as Four Phase and Viatron, which allowed people to enter punched card data on a screen and edit it. These of course had 80-column input. These were followed by more general purpose video displays like the VT50, which also had 80 columns for compatibility with punched card systems. This led to terminal emulator windows such as xterm using 80 columns. It is a clear historical path. (I don't know why you're bringing the Apple II into this.)

You could buy an 80 column card for your Apple II. It usually needed to be turned off for games and such that were depending on the 40 column format, but that was hit or miss.

132 was too long given the resolution of displays at a time. I don't think it necessarily says anything about the easiness of parsing a string that long per se.

> Note that ergonomics has nothing to do with the success of 80 columns

I don't think that's true at all. While 80 columns becoming initially common for displays was no doubt a product of the H-card, the fact is that there was reasonably widespread support even fairly early in the pre-GUI PC era for alternatives -- both more and less, but probably most notably in use 132 columns -- for display, printing, etc., and they were used where they offered superior utility. But, outside of a few niches, 80 columns stuck even in the face of alternatives, and the reason it did so was ergonomics.

The vertical height of characters was dictated by the number of scan lines in the display. It was impractical to use displays that weren't compatible with TV standards, so that meant 240 non-interlaced scan lines. 10 pixels is about the smallest height you can make a font including line spacing, so that's how you get 24 rows.

Once you have the number of rows, you want the number of columns to have a good balance. 80 columns gives you well proportioned characters, where other alternatives e.g. 132 do not. Add that to the historic precedence and you have the makings of a standard.

Teletypes were in common use on the first time-sharing systems, and those were only 72 columns wide. Consider yourself lucky to have those extra 8 characters.

It's 9 vertical pixels, actually. Standard CGA font was 8x8, using the last column for character spacing, and the last row for descenders:

http://www.seasip.info/VintagePC/Images/cga.png

So then you need one more row to separate lines (or live with the occasional joined characters, as CGA did with its 640x200 resolution).

Your article is fantastic. I had no idea that:

> When the Type 80 sorter was introduced, standard AC power hadn't fully taken over and parts of the United States used DC or 25 Hertz AC.[9] Thus, the sorter needed to handle fifteen different line inputs including unusual ones such as 115V DC or 230V 25 Hertz AC.

Really enjoyable article, thank you -although, could I possible talk you into an honourable mention of the 1801 Jacqard Loom which used punch cards to store patterns? :)

[1] https://en.wikipedia.org/wiki/Jacquard_loom

Exactly, for readability a printout should be 10 characters per inch, which on 8.5 x 11 paper means 80 characters max with .25" margins on either side. It would perhaps be better argued as the tyranny of 10 point type :-)

Also books although length of pages are different have that font size.

I agree, and I was thinking the same thing as I read the article. Even so, I'm glad we're talking about history. 79 or 81 characters would be pretty much the same. You have to know the history to understand why 80 is a magic number.

And why does my terminal window have a baud rate? Why is it so slow?

Also the author seems to have missed that this char limit is changing. In Python, for example, an official style guide update in 2013 [1] allows for 100 char line length.

[1] https://www.python.org/dev/peps/pep-0008/#maximum-line-lengt...

To clarify, PEP 8 nonetheless recommends that lines be limited to 79 characters, and even recommends capping docstrings and comments to 72 characters. The python standard library follows those guidelines.

The 100-character allowance is for code "maintained exclusively or primarily by a team that can reach agreement on this issue".

The author wrote this in 2012, so at the time it may have been impossible to predict the 2013 update.

A style guide doesn't change on a whim. I can nearly guarantee the shift was visible coming down the pipeline a year earlier.

I think this might be a case of two-way causation, though.

~80 characters is a good, readable target, but that's not what we have. For a long time, we've had a militant standardization on <81 characters, even in cases where the results are obviously worse than a long line. I imagine that all of us have read or written code containing a line break that blatantly decreased clarity.

So the question remains: why 80? 80-ish, sure, but why such a fixed standard? I don't know enough history to say if that's down to Hollerith cards, or the consequences of auto-formatters, or something else, but there's a more definite question than "what's a good width" here.

> why 80?

Because 80 is a very good approximation to 80-ish.

"Ergonomic" in the same sentence as "Hollerith card" can only be tongue-in-cheek humor.

A little offtopic and showing my age, but in 1985, personal computers were still a little expensive, and my high school couldn't afford an Apple ][ lab yet, but we did have a Digital PDP-(something) mini computer with a card reader (probably a donated relic).

In my grade 10 "Data Processing" class (when was the last time you heard someone use the term Data Processing?), we had to use IBM cards with a Sharpie (the card reader was thankfully an optical reader vs a punch card reader) to write programs in BASIC (when BASIC still used line numbers). When we had tests, we had to basically write our programs at our desks on cards, run to the card reader to run and check our results on a printout. It made for some hilariously tedious debugging cycles.

If my memory serves correctly, back in that era, having an 80 column card on your Apple II was something worth bragging about.

> thankfully an optical reader vs a punch card reader

Hey, with punched cards you had: a) free confetti, b) gunfire soundtrack.

You were deprived and are in the Nile.

Yep, a pretty serious piece of kit, although you really needed a monochrome monitor for it to work properly ... regular TVs didn't have the horizontal bandwidth.

Not at all. The H-card dates back to 1890, and punched cards in general go back a lot earlier than that. Given the technological limits of the day, the H-card is actually quite a good design.

I'm seeing a general push for longer lines. I no longer religiously hold Java code at 80 personally.

I use the rule "if it fits on my screen then it's not too long". And if your code doesn't fit on my screen, I might break the line and commit.

I use a portrait-mode monitor for coding, with 128 columns. Honestly, 80 is Just Fine by me. It is a nice readable width, and I don't mind wasting ~⅓ of my screen.

> Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line,

Maybe because it was written from a terminal?

Reply on news.ycombinator.com