The tyranny of the Hollerith punched card • Hacker News Board

Re: The tyranny of the Hollerith punched card

#81

Post by lisper » Mon, Jun 06, 2016, 5:02 PM UTC

kens wrote: post #75

lisper wrote: post #14

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 c…

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 a…

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.

Re: The tyranny of the Hollerith punched card

#82

Post by Glyptodon » Mon, Jun 06, 2016, 5:02 PM UTC

A someone who believes proper non-abbreviated naming is essential to maintainable code I think the 80 char/line practice should be dead already.

A couple 14 char class names and some indentation and suddenly everything is a formatting contortion, even if the average content length of a line is well under 80, occasional outliers and moderate indentation (at least 3 or 4 indentation levels are common in object oriented languages from class declaration to control flow) and it's well worth it to use 120 char lines.

(And if you write Java you probably need even more space to handle stuff since class names are often a ridiculous number of words long...)

Outside of programming languages, I also think the 80 char limit is terrible for readable html or html templates.

Re: The tyranny of the Hollerith punched card

#83

Post by kiruwa » Mon, Jun 06, 2016, 5:03 PM UTC

hughes wrote: post #62

kiruwa wrote: post #50

80 is an _awful_ width for code in a programming paradigm encouraging long variable names. If you're comparing two values from class.accessor, you fly right past 80 characters if you have any indentation at all. Namespace hierarchies pretty much put you over the limit if you use named constants in your constructors. If you actually use long/descriptive variable names, you can mentally process much wider text quickly,…

Has anyone tried enforcing a variable-reference-per-line limit? Eg. if the limit is 4, then these two lines equally hit the limit: foo = bar(baz, qux) myClassInstance.someWritableVar = lib.someFunction(param1, MyOtherClass.constants.FOO) The second line is well over 80 chars, but may be as understandable as the first.

It effectively limits all functions that return a value to 2 parameters. I rarely go over that, but it would seem a bit arbitrary to bump into.

Re: The tyranny of the Hollerith punched card

#84

Post by ptx » Mon, Jun 06, 2016, 5:04 PM UTC

  > But breaking the statement arbitrarily at some point
  > seems more like saying that you have to end a sentence
  > at the end of each line, whether the sentence is finished
  > or not because, you know, that's the way it's always been
  > done. (I know it's not a perfect analogy.)

Isn't it more like line-breaking sentences at the edge of a paper page, which we do, and which is perfectly reasonable because of the page's fixed size?

Sure, you can design your document for a different paper size, but then you have to reconfigure the printer for that size, make sure you have the right paper size loaded in the printer (and change it back afterwards!), get new envelopes in the new size, get new binders...

Similarly, if I read a program wider than 80 characters, I have to resize my terminal window and my Emacs window. When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines, unless I remember to resize things back to normal, which in turn perpetuates the problem. So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) or we could just decide to stick to the standard 80 columns which, as many comments here have pointed out, is a reasonable choice to standardize on even if it's arbitrary.

Re: The tyranny of the Hollerith punched card

#85

Post by kiruwa » Mon, Jun 06, 2016, 5:07 PM UTC

sklogic wrote: post #65

kiruwa wrote: post #50

80 is an _awful_ width for code in a programming paradigm encouraging long variable names. If you're comparing two values from class.accessor, you fly right past 80 characters if you have any indentation at all. Namespace hierarchies pretty much put you over the limit if you use named constants in your constructors. If you actually use long/descriptive variable names, you can mentally process much wider text quickly,…

> 80 is an _awful_ width for code in a programming paradigm encouraging long variable names Which is exactly why all such paradigms are _awful_.

All hail strpbrk()!

Do you have any defense of that? I'd be interested to read it.

I think every article on coding advice I've read for the last decade favors long and descriptive function/variable names.

Re: The tyranny of the Hollerith punched card

#86

Post by Nano2rad » Mon, Jun 06, 2016, 5:08 PM UTC

ChuckMcM wrote: post #55

lisper wrote: post #14

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 c…

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.

Re: The tyranny of the Hollerith punched card

#87

Post by mavhc » Mon, Jun 06, 2016, 5:09 PM UTC

ptx wrote: post #84

> But breaking the statement arbitrarily at some point > seems more like saying that you have to end a sentence > at the end of each line, whether the sentence is finished > or not because, you know, that's the way it's always been > done. (I know it's not a perfect analogy.) Isn't it more like line-breaking sentences at the edge of a paper page, which we do, and which is perfectly reasonable because of the page's fi…

Sounds like lines should change width more often to make such silly bugs noticeable so they can be fixed.

Re: The tyranny of the Hollerith punched card

#88

Post by sklogic » Mon, Jun 06, 2016, 5:10 PM UTC

kiruwa wrote: post #85

sklogic wrote: post #65

Earlier quoted context omitted.

> 80 is an _awful_ width for code in a programming paradigm encouraging long variable names Which is exactly why all such paradigms are _awful_.

All hail strpbrk()! Do you have any defense of that? I'd be interested to read it. I think every article on coding advice I've read for the last decade favors long and descriptive function/variable names.

Descriptive function names - yes, of course. With one function call per line.

But long variable names?!? There is no place for such an abomination under this sun.

Re: The tyranny of the Hollerith punched card

#89

Post by alayne » Mon, Jun 06, 2016, 5:12 PM UTC

lisper wrote: post #14

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 c…

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

Re: The tyranny of the Hollerith punched card

#90

Post by [deleted] » Mon, Jun 06, 2016, 5:12 PM UTC

lisper wrote: post #14

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 c…

[deleted]