"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…
The tyranny of the Hollerith punched card
141–148 of 148 posts
Re: The tyranny of the Hollerith punched card
#142Earlier 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…
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
#143Earlier 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…
Re: The tyranny of the Hollerith punched card
#144I 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.
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
#145Earlier 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…
Re: The tyranny of the Hollerith punched card
#146Earlier 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.
Re: The tyranny of the Hollerith punched card
#147Personally, 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…
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
#148Punched 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…