Live data from Hacker News

The tyranny of the Hollerith punched card

pub.gajendra.net

41–50 of 148 posts

Re: The tyranny of the Hollerith punched card

#41
post #4

Earlier quoted context omitted.

I think the biggest problem with translating this into code widths is that we use indentation liberally. Seeing 6-12 characters taken up by whitespace is nowhere near uncommon. So, given that, perhaps 80 characters isn't so tyrannical...

I've seen code where 20-odd characters were taken up by whitespace. Of course, at that point, you really want to split it out into different, named functions... code like that is unreadable for entirely different reasons than line lenth. Similar things the case for almost every single case where a line might become "too long" - I don't think the length is actually the issue so much as the complexity.

but "20-odd" (let it be 24) is just 3 * 8, which is something like this. I don't see how this is already screwed up for complexity.

  class A
  {
        A::a()
        {
              if (expr) {
                    do1();
              } else {
                    do2();
              }
        }
  }

Re: The tyranny of the Hollerith punched card

#42
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…

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

Re: The tyranny of the Hollerith punched card

#44
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…

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...

Re: The tyranny of the Hollerith punched card

#45

While the first example of car sizes and Roman chariots is likely incorrect (as the article itself points out, and it's also suspiciously familiar to the debunked railroad gauge/Roman chariot story[0]), I'm always fascinated by stories like this. It underlies the organic nature by which many of our systems have grown. The same kind of "cruft" you see in systems and designs that have been around for a long time (Why i…

Or the reason for the JHKL vim arrow keys - I've read quite often how ergonomic that is, but it's just historical: http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys... (then again, maybe the original keyboard maker put them there for ergonomic reasons)

I always thought it was because on slow modem connections the traditional arrow keys could become unreliable. Vim supports use of the arrow keys, but back in the day when I tried to use them over a modem occasionally the sequence would be interpreted as escape then garbage, breaking me out of editing mode and sending some unsuppported command to the vim. That's why I learned to use hjkl instead. Those keys are also reliably placed on Qwerty keyboards, whereas any other keys may or may not remain in a sensible location, especially back in the old days before keyboard layouts settled down.

Re: The tyranny of the Hollerith punched card

#46

Earlier quoted context omitted.

I've seen code where 20-odd characters were taken up by whitespace. Of course, at that point, you really want to split it out into different, named functions... code like that is unreadable for entirely different reasons than line lenth. Similar things the case for almost every single case where a line might become "too long" - I don't think the length is actually the issue so much as the complexity.

but "20-odd" (let it be 24) is just 3 * 8, which is something like this. I don't see how this is already screwed up for complexity. class A { A::a() { if (expr) { do1(); } else { do2(); } } }

I think most people have converged to 4 space tabstops, so 24 spaces means 6 levels of indentation.

Re: The tyranny of the Hollerith punched card

#47
post #22

Earlier quoted context omitted.

80 characters seems really narrow. IDEs like IntelliJ put a guideline at 120 characters, which basically allows two full width editing windows side by side (depending on your font size) at the pretty standard resolution of 1920x1080. We've all got widescreen monitors now, right? So it makes sense that people are going well past 80 characters.

As another commenter noted, it's not (just) about screen width. It's about having a text width that allows your eyes to track both column boundaries as achoring points. If a text is too wide, your eyes will have trouble finding the start of the next line. For the same reason, newspapers use multiple columns, even though the paper itself would allow for 200-character lines.

Most of this line length theory isn't backed up by any science. Newspapers are a particularly poor example as their line lengths are typically much too short to provide "good" readability.

It's also worth noting that newspapers traditionally used columns because they allow individual articles to be typeset and then divided into pieces later during composition. Not because they offer some kind of readability advantage.

Re: The tyranny of the Hollerith punched card

#48
This is one of my major pet peeves

Except for Linux Kernel people (who actually have to work and debug stuff in the builtin 80x24 screen) there is no excuse for not using something bigger

Having to break a line because it's 81 characters and your linter is going to complain is completely and utterly ridiculous

It's 2016. How long since the first IBM PC again?

Yes, it's a tyranny. I don't care if the average is around 80 columns, I care about having a hard limit

My current terminal is 110 chars wide, and that's because I use a bigger font.

Re: The tyranny of the Hollerith punched card

#49
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…

"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.

Re: The tyranny of the Hollerith punched card

#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, invalidating the research the "80 character optimization" was based on.

Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".

Post reply on HN