Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tyranny of the Hollerith punched card

pub.gajendra.net

Post reply on HN
Print view View original

61–70 of 148 posts

Re: The tyranny of the Hollerith punched card

#61

Post by jhardcastle »

ChrisArgyle wrote: post #44
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…

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

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

Re: The tyranny of the Hollerith punched card

#62

Post by hughes »

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.

Re: The tyranny of the Hollerith punched card

#63

Post by Karunamon »

tamana wrote: post #23
strictnein wrote: post #17

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.

80col is narrow for Java because Java has very long method names, explicit tyle declarations, and class names on static methods.

Python too, because you're forced to indent. One line of moderate length explanatory text out to console in the middle of an if: block, and you have to resort to silly tricks[1] to remain PEP8 compliant.

[1]: https://tkware.info/2016/05/08/a-case-for-increasing-pep8-li...

Re: The tyranny of the Hollerith punched card

#64

Post by marcosdumay »

You know, those kinds of history forcing itself into modern standards only happen when the historic one isn't inconvenient.

When compatibility is a burden, people do work hard to break it.

Anyway, there's a "(2012)" missing on the title, and even that makes the article kinda late to the discussion. By that time, most people already didn't care about the 80 lines limits.

Re: The tyranny of the Hollerith punched card

#65

Post by sklogic »

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

Re: The tyranny of the Hollerith punched card

#66

Post by lukeschlather »

strictnein wrote: post #38
tremon wrote: post #22

Earlier quoted context omitted.

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.

I don't think we read code the same way we read normal text. If you have this in your code: qry.setParameter("a", a); qry.setParameter("b", b); qry.setParameter("foo", foo); qry.setParameter("bar", bar); After the first "qry.setParameter" you're no longer reading anything but the parameters and your eyes are moving vertically. Or if you have something like this: Query qry = getEntityManager().createNamedQuery("User.f…

Just for the record, that bit of code gets cut off at ", Long." for me, and then there's a scrollbar. (I always read HN zoomed-in.)

Re: The tyranny of the Hollerith punched card

#67

Post by penguinduck »

tremon wrote: post #22
strictnein wrote: post #17

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.

Newspapers can be extremely unreadable though for this exact reason. They often use 30 character columns, then have an article consisting of 5 or more such columns of text. I often "get lost in the sentence" when reading this format and have to backtrack. It would be interesting to know why they do this. It is definitely not readability.

I think on a mental level, the problem is that when the lines are this short, the grammar is extremely broken up, so you need to "cache" 4-5 lines of context to understand anything. When it's 80 per line, lines are parsed in a more independent fashion.

I think 70-100 is perfect, depending on other factors.

Screenshot of what I mean: http://www.trbimg.com/img-5667d3f6/turbine/la-la-na-menace02...

Re: The tyranny of the Hollerith punched card

#68

Post by mturmon »

ddebernardy wrote: post #56
derekp7 wrote: post #35

Out of curiosity, where did the 132 column standard (for wide carriage printers) come from (why 132, not 130 or 120)?

Likely because of the VT100: http://vt100.net/docs/tp83/chapter5.html > 132 column × 14 lines (VT100, VT101, VT125) display > Allows you a larger format for detailed or spread sheet work so you can preview reports prior to printing. (Note: The advanced video option, which is standard with the VT102 and VT131, provides 132 column × 24 lines display.)

I'm not sure what the vt100 resolution was, but later terminals allowed you to download your own bitmaps. According to (http://www.vt100.net/docs/vt510-rm/DECDLD.html), these bitmaps were:

  "10 pixels wide for 80 columns, 6 pixels wide for 132 columns."
If their baseline was 800 pixels (80 cols * 10 pix/col) then 132 is the largest number of columns fitting into 800 pixels at 6 pix/col.

Re: The tyranny of the Hollerith punched card

#69

Post by lukeschlather »

raverbashing wrote: post #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…

If eyes were easily repairable I might agree. But I figure at some point in my life (even though I keep my fonts larger than I need to) I'm going to need even larger fonts. I'd rather write code my future self will have less trouble reading, especially since I might be sharing my code with others who have poor eyesight now.

Re: The tyranny of the Hollerith punched card

#70

Post by vertex-four »

andrey_utkin wrote: post #41
vertex-four wrote: post #20

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 don't actually know of any project which uses 6 or 8 characters per indentation level.
Post reply on HN