The Tyranny of the Hollerith Punched Card (2012) | Hacker News Reader

The Tyranny of the Hollerith Punched Card (2012)

pub.gajendra.net

36 pointsvu3rdd28 comments

Personally, while my windows are far wider than 80 characters, my code generally use shorter lines for a simple reason: readability. It's faster for me to scan a code fragment if I need to move (scroll the code, move my eyes) only on one axis. I use wider windows because it is convenient to split in two, to let me switch between files while keeping other files up in a fixed location.

The 80 width "limit" has survived to the extent it has not just because of tradition and compatibility, but also because it fits well within the range of what is most comfortable for most people.

Add to that the desire to ensure fixed-formatted text like code will be readable also on other peoples screens, and it becomes relatively irrelevant if you can fit 200 character lines on your screen and have eyesight that makes that comfortable even when using smaller screens, and don't mind moving your head all over the place.

That this is the top comment restores my faith in humanity, because it is exactly what I came to say: the adherence to 80 columns has nothing to do with refusal to accept change, and everything to do with enforcing readability. If a function is so many scopes deep that 80 columns has become unruly -- or if function or variable names are so long that this is an unacceptable limitation -- that's a reflection on the code, not on the 80 column limitation. The code should be refactored, intermediate expressions assigned to local variables, etc. -- all of which greatly assist readability.

Additionally, and as others have observed as well, the author (mistakenly, in my opinion) assumes that 80 columns was imposed by the punchcard rather than the punchcard reflected an approximation of readable line length. That this line length has an innate readability can be confirmed with this experiment: take a book off of the bookshelf, open to a random page and input a random line of text in your fixed-width text editor. Hardcover or paperback, small font or large, old book or new, you will find that the line is almost always less than 80 columns -- and often surprisingly close. One can quibble about the exact number, but it is clear that there is an innate connection between line length and readability -- and that enforcing that line length is an easy way of enforcing minimum standards of readability.

It also make code review easier, I can easily fit two versions of the same code side-by side on the screen with room for line numbers, blame, and diff characters leaving room for another window for man pages and other commands. Plus it prints nicely without wrapping one file portrait or two in landscape.

Another interesting question: Where does the traditional 25-line height of a default terminal window come from?

Obviously it came from the 80x25 character mode displays of old CRT monitors. The IBM PC had an 80x25 monochrome display, but it was just mimicking older CRTs from the '70s.

Where did those displays get their dimensions: usually 80x25, sometimes 80x24?

It can't be punched cards. There's nothing particularly special about a deck of 25 cards vs. 21 or 29 or whatever.

It isn't the Teletype machines we used back in the day. Those use a continuous roll of paper.

In fact the first time I saw someone using a "glass teletype" at Tymshare where we all coded on Teletypes, I wondered what you would do when something scrolled off the top of the 25 line screen. Teletypes were noisy, but the paper coming out the top gave you an infinite scrollback buffer!

So why 25 lines?

I think it came from the standard coding forms used for FORTRAN and other languages in the '50s:

http://www.atkielski.com/PDF/data/fortran.pdf

(BTW if you want an authentic FORTRAN Coding Form of your own, that PDF prints beautifully on 8.5 x 14 legal-size paper.)

There you have it: six groups of three lines each, 24 lines on your coding form. So an 80x24 display was a perfect match for a standard coding form.

Add a status line at the bottom of the CRT and you have your 80x25 terminal.

My theory's more boring: By the time CRT-based terminals became popular, CRTs were basically square. And many of the characters of the Roman alphabet are typically rendered about twice as high as they are wide. Then add in a half-line or so of line spacing, and you are now at 26 or 27 lines.

I think the more compelling reason for 80x24 is that it works out reasonably well to do the arithmetic for it by bit-shifting. 64x16 displays used to be common because that works out even better. I think the IBM PC went to 80x25 because that's as many as you can fit in 2048 bytes without going over, and they were willing to spend a lot more chips on video than earlier microcomputers were.

Coding forms? No. Commonly available CRTs were designed for 525 line alternate frame TV, which really give about 262 lines of resolution. That gives a just-barely legible 10 dots for a text line on a 24 line display.

-dB

Common CRT capability is also how we got the 320x240 (bad TVs) and 640x480 (better TVs) resolutions.

It's interesting that this old saw comes up with the implication that 80 columns is not enough. Back in the day, Forth programmers wanted to put their source in binary length blocks. They picked 64 columns rather than 128. Forth is a particularly concise language, but the point still exists.

Why is more always considered better?

  Why? Because (and here, we finally get to the real answer), 
  that's how wide a Roman chariot needed to be, in order to 
  accommodate the width of the war horses pulling it. So, in 
  some sense, the width of cars is not only an artifact of 
  the way that things had always been, but is also an 
  extension of the tyranny of Caesar. Remember that the next 
  time you go pick up some groceries.

http://www.snopes.com/history/american/gauge.asp

  This item is one that, although wrong in many of its details, 
  isn't completely false in an overall sense and is perhaps more 
  fairly labeled as "Partly true, but for trivial and unremarkable reasons."

Maybe more interesting is why we've retained some of the limitations of the past, while moving beyond others. 80 characters probably isn't as constraining when your variable names are limited to 6 character (as in Fortran77), and seem more constraining for identifiers like "MemberSubmissionAddressingWSDLParserExtension".

http://www.pushing-pixels.org/2007/11/07/and-the-longest-jre...

In the early-aughts I worked for a small web software company that used Microsoft systems for development and production. We got bought out by a larger "professional" dev house (that also developed on MS products) and a new edict issued (so we could be professionals): we needed a STRICT coding standard. 80 chars per line NO EXCEPTIONS. Of course that was the only rule set in stone for all languages.

Even the plain, flat HTML files had to be less than 80 chars per line.

Any coding style that benefits from indentation is strangled by 80 chars. I still need to set up a ruler on Sublime, or else over the course of a week the lines will progressively get longer because I'm unwilling to break for just a few characters without it, but we've all decided to do 120. Hell, if only for comments, I don't want those to be newspaper columns.

If the line of code has many narrow characters (like i, l, t, f, parens, comma, and dot) and few wide characters (like uppercase or Chinese characters in your identifiers) then you can have much more than 80 characters on a line IMO.

Or were you advocating breaking the 80 chars per line restriction, but not the fixed-width font restriction?

I'd be much more comfortable with breaking the 80 chars per line restriction than using variable width fonts - often it helps readability to be able to easily line things up. The day every system I work on consistently handles tab-stops in a sensible way, I might be open to consider variable width fonts for coding.

Viewing code with a variable width font is considered madness by default, no?

You've probably seen some code in a variable-width font at some point in your life, and just never were conscious of it because it looked so right.

It's alot like syntax highlighting: people will lose their minds if you suggest that it's even possible to live without it, but the fact that they are able to read their shell input line, their less/vim :-line, their google input line when they use quotes/minus/etc, their books with code in them, ..., suggests that their complaint is not based on a _need_ for highlighting but on an expectation for it. It's the only way to explain why it's apparently necessary in one program and completely unneeded in all others.

Fixed-width fonts are like that.

Only if you put too much value on every little thing lining up. Your indentation levels will still work out, and beyond that people have better things to do than futz around lining up all their comments perfectly...

Oberon used it by default, and it makes long, multi-statement lines much more readable. Having more statements on the screen at once allows for more readability.

My day job used to involve coding in RPG which still enforced 80 column formatting as of the late 90s, where specific columns have specific meanings and are populated with indicators that represent types and instructions. This is a direct result of programs being written using punched cards, but was carried into the interactive environment as well.

Examples here: http://en.wikipedia.org/wiki/IBM_RPG#Example_code

But why was the Hollerith card 80 chars wide in the first place?

Well, it was 45 columns wide in the first place. But the 80 columns of the IBM revision is what you can squeeze into a letter size typewritten line at 10cpi, and that in turn is because, less margins, you get the ~65 characters long considered ideal for printed text.

No need anywhere to observe this limit any more. Its only in our heads folks! Just rebel. I do - my lines are as long as they need to be.

When I'm grinding out Cobol or Algol code (yes, I am a dinosaur), I stick with 80 columns per line. Because, for better or worse, that's all my compiler sees. One compiler squawks when a line extends beyond Col 80, another allows the use of Col 81-90 for a markid, but the standard editor doesn't grant access to those columns easily, so it's infrequently used. But if I'm using a more freely-formatted language, you can bet I'm ignoring the 80-column limit. But I'm still keeping my lines as short as possible, and even wrapping in some cases, because my code needs to be easy to read, and side-scrolling is the antithesis of reading easiness.

Also, when I was coding in PascalVS at the University of Pangaea, I distinctly recall becoming incensed one day over the fact that, while the Hollerith card provided 80 columns, the PascalVS compiler stopped reading earlier than that--maybe it only accepted 72 characters per line. That was irritating. And costly--we had to provide our own cards, and on a student budget, they weren't cheap!

FORTRAN is well known to have a 72 column limit. The reason is that the IBM 704 had a 36-bit word, and the card reader supplied only two words per row.

(2012) [based on the URL]

Yes. Added.

I have never worked on a software team with a hard 80-column limit, FWIW. It's always more of a suggestion.

Reply on news.ycombinator.com