Live data from Hacker News

The tyranny of the Hollerith punched card

pub.gajendra.net

141–148 of 148 posts

Re: The tyranny of the Hollerith punched card

#141

"number of characters per line" made sense when we all used text-based monitors with a fixed number of characters on the screen. Nowadays, most people are using graphic displays, at a very high resolution, with beautiful, mathematically described fonts, which can be resized at will. So why are we restricting ourselves to an arbitrary number? 80 seems too low, no matter if you are writing javascript callbacks or writi…

Has anyone ever designed a visual editor or IDE where the syntactic and semantic elements were differentiated using font SIZE as well as the usual colouring and face variation (bold, italic, underline) we normally get? I could imagine having class names in a larger, heading type font size, for example. Code folding could be used, with attributes like access modifiers aligned underneath. Code blocks could be displayed as actual boxes, with borders and fills?

Re: The tyranny of the Hollerith punched card

#142
post #125

Earlier quoted context omitted.

> Note that ergonomics has nothing to do with the success of 80 columns I don't think that's true at all. While 80 columns becoming initially common for displays was no doubt a product of the H-card, the fact is that there was reasonably widespread support even fairly early in the pre-GUI PC era for alternatives -- both more and less, but probably most notably in use 132 columns -- for display, printing, etc., and th…

The vertical height of characters was dictated by the number of scan lines in the display. It was impractical to use displays that weren't compatible with TV standards, so that meant 240 non-interlaced scan lines. 10 pixels is about the smallest height you can make a font including line spacing, so that's how you get 24 rows. Once you have the number of rows, you want the number of columns to have a good balance. 80…

It's 9 vertical pixels, actually. Standard CGA font was 8x8, using the last column for character spacing, and the last row for descenders:

http://www.seasip.info/VintagePC/Images/cga.png

So then you need one more row to separate lines (or live with the occasional joined characters, as CGA did with its 640x200 resolution).

Re: The tyranny of the Hollerith punched card

#143
post #81
post #75

Earlier quoted context omitted.

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

132 was too long given the resolution of displays at a time. I don't think it necessarily says anything about the easiness of parsing a string that long per se.

Re: The tyranny of the Hollerith punched card

#144
post #19

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

It goes both ways. If you break in the middle of the line just because you need to follow the standard, you may end up breaking in the middle of a construct that is really meant to be read as a whole; and having to move your focus to from the end of one line to the beginning of another is quite disruptive to the flow.

I'm also not convinced that 80 chars "happens to line up quite well with the human eyes ability to track horizontal lines of text". It's claimed often, but in the absence of any actual studies, the best you can really say on this is that it is your subjective experience. Mine is different - I find 100-120 columns per line to be eminently more readable.

Until the aforementioned study determines what the average peak readability length of _code_ (which I think is likely to be different from regular text, because the semantic units are different between the two), we'll just have to agree to disagree.

Re: The tyranny of the Hollerith punched card

#145
post #85

Earlier quoted context omitted.

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.

strpbrk() is a bit too short for my taste, but I'll choose that over FindFirstOccurrenceOfAnyCharIn(). There's "long and descriptive", and there's "too long". Think about it: there's a reason why human languages are filled with pronouns, because if you use the full name for everything, communication will soon become tedious and it will become actually harder to understand. Any desire for a long and descriptive name s…

Human languages also solve it by taking into account context - and so do PLs. For example, if your language can overload functions based on argument types, then "Char" is already redundant.

Re: The tyranny of the Hollerith punched card

#146
post #88
post #85

Earlier quoted context omitted.

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.

Long variable names are great. When used in conjunction with redundant variables for intermediate computation results (effectively naming those results), they can make a terse but complex expression much easier to read and understand, to the point where something that required a comment no longer does so.

Re: The tyranny of the Hollerith punched card

#147
post #108

Personally, I agree with the author and generally have argued against hard line-length limits. Today's computers have different screen characteristics than even 15 years ago and we're at a much greater loss of vertical length than horizontal length so it bugs me when I pull up code that has less-readable statements broken apart over ten lines, doing one thing, and leaving 80% of my screen empty when readability would…

I have often argued that 16:9 is a terrible ratio for office work. 4:3 was a great ratio for creating documents since they are almost necessarily longer than they are wide. The relevant portion of most spreadsheets is rather wide, since you don't necessarily care about looking at every row at once; however menu bars and other information is generally placed horizontally across the screen, eating up valuable real-esta…

Completely agree! I resisted replacing a laptop for more than 2 years because all of the options available were 16:9 and I had an nice, high-resolution 4:3 display. That was years ago.

In my basement office, I have both of my displays set at a vertical orientation. When I took a new job, which has me working full time out of my home, I vowed to get used to using my laptop's display (and purchased a laptop based almost entirely on the display characteristics) because I wanted to be able to code wherever I was. This resulted in my writing an extension for Visual Studio to help identify certain code blocks I often scroll around aimlessly for and using parts of the IDE that I hadn't often used due to being able to see even terribly written classes all on one screen.

With a few adaptations, which included relaxing my style rules, I'm as productive on my 1080P display as I am with those two monitors. Some things are more difficult, but its made up for by being able to get up and work outside, up the road or on the beach up north, when I run into a wall with a coding problem. I require fewer breaks because I work feels less like work when you can change your environment on a whim rather than adapt to it.

Re: The tyranny of the Hollerith punched card

#148
post #140

Punched cards were a pain to work with. We used to have a 40,000-card master file that we had to run through twice a day on a Univac 1001, at 1,000 cards/min. per feed, plus jams. The racket was deafening. When the card reader jammed, it destroyed the card. We had to retrieve the bits of card, and tediously re-create the card on an IBM 026 keypunch, one column at a time. One time a card got caught between two pinch r…

> except they had another word for the "F" I believe you're allowed to say "Fuck" and it's various declensions on HN now! I'm always particularly intrigued by people who write things like "Sh#t" or "F#ck" because it's unclear who they are censoring for, and indeed why. If it was simple prudishness, I assume they would either use some twee alternative or mis-spelling, but simply eliding one letter suggests they themse…

I was just trying to convey the sensitivities of the era. As a Quebecker, I am not averse to expletives :o)
Post reply on HN