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

121–130 of 148 posts

Re: The tyranny of the Hollerith punched card

#121

Post by benjohnson »

kens wrote: post #107
torgoguys wrote: post #39

Apologies for being somewhat off topic, but does anyone know where I can go these days to get some cards punched (for a small museum display)? Given how common punchcards were, it has been difficult to find someone. Anyone out there have access to an old IBM 026, 029, 129?

The Computer History Museum in Mountain View has 026 and 029 keypunches. Go to the 1401 demo and they'll probably let you punch a card. Or let me know what you need punched and I'll see what I can do. What museum are you getting this for? If you're in the bay area, you should go see the IBM 1401 demo; it's cool to see a punched card computer in operation. Demos are Wednesdays and Saturdays; schedule is http://www.com…

The Living Computer Museum in Seattle has a keypunch - ask a docent and they'll turn the machine on, give you a card, and a bit of instruction and you can have at it.

Re: The tyranny of the Hollerith punched card

#122

Post by Declanomous »

mdip wrote: 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-estate.

I've tried rotating my monitors so they are long in the vertical direction, which is great for reading, but doesn't account for the space needed on either side of a document for supporting information, or what have you.

Re: The tyranny of the Hollerith punched card

#123

Post by kiruwa »

to3m wrote: post #113
kiruwa wrote: post #83

Earlier quoted context omitted.

It effectively limits all functions that return a value to 2 parameters. I rarely go over that, but it would seem a bit arbitrary to bump into.

You can press the Return key? :) const uint64_t *p=bsearch(&ref->u, df->file_offsets, df->num_file_offsets, sizeof df->file_offsets[0], &CompareU64s); That's from emacs. It's a bit hit or miss whether editors do something nice like the above, or just indent the arguments by one stop, but other options seem to be fairly rare. I generally have one function call per line for ease of debugging. Nothing worse than having…

Eh, seems fine, just seems odd to be forced to do that for a three-argument function.

Re: The tyranny of the Hollerith punched card

#124

Post by kiruwa »

yongjik wrote: post #117
kiruwa wrote: 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…

The problem with these examples of verbose functions is not that they're verbose, it's either that they encompass too much functionality or poorly describe what they do.

Re: The tyranny of the Hollerith punched card

#125

Post by mark-r »

dragonwriter wrote: post #97
kens wrote: 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…

> 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 columns gives you well proportioned characters, where other alternatives e.g. 132 do not. Add that to the historic precedence and you have the makings of a standard.

Teletypes were in common use on the first time-sharing systems, and those were only 72 columns wide. Consider yourself lucky to have those extra 8 characters.

Re: The tyranny of the Hollerith punched card

#126

Post by kiruwa »

sklogic wrote: post #101
kiruwa wrote: post #94

Earlier quoted context omitted.

Are we anti-OOP then? And no, I don't believe you. Making your variable names more descriptive does not make your code less readable. Even when it's not strictly necessary, it's not harmful to comprehension UNLESS you refuse to move from a completely outdated line width. Some people argue that it takes longer to type and edit. But as we all know, we spend far more time reading than writing code, and modern editors (l…

It takes longer to read , and this is what is important. And, yes, OOP is a filth.

I don't think either of these are true, but now I understand where you're coming from.

Re: The tyranny of the Hollerith punched card

#127

Post by kiruwa »

kazinator wrote: post #118
kiruwa wrote: 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.

Defense of strpbrk and strspn: The "break" and "span" terms were familiar from a time when more people knew the Snobol language, which has two frequently useful pattern matching operators: BREAK and SPAN. Snobol's BREAK(S) pattern matching operator matches the input up to but not including the single-character match for any of the characters in set S. The set S delimits or "breaks" the sequence. SPAN(S) matches a seq…

Sure, within the context of this generation of string-handling functions, the particular example of strpbrk makes sense.

But there's a reason that this sort of name has been left behind in modern APIs.

Re: The tyranny of the Hollerith punched card

#128

Post by _acme »

jandrese wrote: post #45
a_bonobo wrote: post #15

Earlier quoted context omitted.

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

There were no "traditional arrow keys" on the terminal that vi was developed on, but arrows were printed on the hjkl keys; see https://en.wikipedia.org/wiki/Arrow_keys#HJKL_keys.

Re: The tyranny of the Hollerith punched card

#129

Post by kazinator »

kiruwa wrote: post #127
kazinator wrote: post #118

Earlier quoted context omitted.

Defense of strpbrk and strspn: The "break" and "span" terms were familiar from a time when more people knew the Snobol language, which has two frequently useful pattern matching operators: BREAK and SPAN. Snobol's BREAK(S) pattern matching operator matches the input up to but not including the single-character match for any of the characters in set S. The set S delimits or "breaks" the sequence. SPAN(S) matches a seq…

Sure, within the context of this generation of string-handling functions, the particular example of strpbrk makes sense. But there's a reason that this sort of name has been left behind in modern APIs.

Yes; that reason being that we don't have the same strict limits on number of characters in an external name, and we simply have too many API's to remember to be able to give six character mnemonics to them.

Short names are not left behind in core languages. For instance, a function that gives the length of a list, string or other sequence is often called length or len, and not length_of_sequence or whatever.

Arc, in which HN is programmed, has reduced "lambda" to "fn". "fn" is the same sort of shortening as using "pbrk" for "pointer to break".

Ruby has shortened "print" to "p".

For the basic core of a language, shortening names is good. When you're reading code, the short names by their very brevity tell you "I'm a thing in the core language, and not some external API to some add-on lib", which also has connotations of "I might be useful in many contexts; it may be worth it to learn about me and remember me".

Re: The tyranny of the Hollerith punched card

#130

Post by mkehrt »

Glyptodon wrote: post #82

A someone who believes proper non-abbreviated naming is essential to maintainable code I think the 80 char/line practice should be dead already. A couple 14 char class names and some indentation and suddenly everything is a formatting contortion, even if the average content length of a line is well under 80, occasional outliers and moderate indentation (at least 3 or 4 indentation levels are common in object oriented…

This is the first reasonable thing I've read in this post. I can't believe that upthread someone actually proposed limiting variable names to four characters to keep the 80 char limit!
Post reply on HN