The banana/monkey story is not actually true, it was not tested as described, and a somewhat similar test did not have clear results.
http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...
The tyranny of the Hollerith punched card
11–20 of 148 posts
Re: The tyranny of the Hollerith punched card
#1250-75 characters is the optimal line width for the human eye to scan: http://baymard.com/blog/line-length-readability
For code it also seems most of the text reside on the left. Opening an extra wide window to display text for the occasional long line seems a waste of screen space.
Re: The tyranny of the Hollerith punched card
#13Going to go with the fact that original cards were the same size as paper currency at the time and re purposing of equipment to handle paper currency was the expedient thing to do.
Re: The tyranny of the Hollerith punched card
#14The 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.
Re: The tyranny of the Hollerith punched card
#15While 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)
Re: The tyranny of the Hollerith punched card
#1650-75 characters is the optimal line width for the human eye to scan: http://baymard.com/blog/line-length-readability
For code it also seems most of the text reside on the left. Opening an extra wide window to display text for the occasional long line seems a waste of screen space.
Indeed. The rule for prose is that a text block width should be somewhere between 2.5 and 3.5 full alphabets. This takes into account the variable spacing of different characters. This is to strike a balance between having inconsistent space or too much hyphenation (if the line is too short) and the eye's ability to find the next line when scanning leftwards from the end of the previous line (which is difficult if the line is too long).
Code is different in several ways. Firstly, code is generally shown in monospace typeface. Secondly, breaking lines too early can be even worse for code than for prose. Thirdly, even with a long line limit, code will generally have lots of short lines anyway, and this helps the eye find the next line when reading. The long lines (as long as they aren't all long) stick out from the rest of the code text, making it easier to read.
Re: The tyranny of the Hollerith punched card
#17I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. For car width, I think that that's also a pretty reasonable width, since it'…
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.
Re: The tyranny of the Hollerith punched card
#18I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. For car width, I think that that's also a pretty reasonable width, since it'…
> For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle.
How do you know the width of a standard human isn't determined by 2000 years of people choosing partners that would fit beside them on a cart comfortably.
Re: The tyranny of the Hollerith punched card
#19I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. For car width, I think that that's also a pretty reasonable width, since it'…
Agreed, 80-chars may be an accident of history, but it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text.
It gets tiring listening to devs rage about the 80-char limit, then go on to produce code that's basically unreadable because it scrolls way off the screen.
Re: The tyranny of the Hollerith punched card
#2050-75 characters is the optimal line width for the human eye to scan: http://baymard.com/blog/line-length-readability
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.