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

91–100 of 148 posts

Re: The tyranny of the Hollerith punched card

#91

Post by kiruwa »

sklogic wrote: post #88
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.

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.

Including class variables? Their context is far larger than the immediate code you're looking at, longer/descriptive names seem basically required there, as they have essentially similar scope to functions. (Same logic applies to making them longer) You'll note... that was my original example.

Re: The tyranny of the Hollerith punched card

#92

Post by sklogic »

kiruwa wrote: post #91
sklogic wrote: post #88

Earlier quoted context omitted.

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.

Including class variables? Their context is far larger than the immediate code you're looking at, longer/descriptive names seem basically required there, as they have essentially similar scope to functions. (Same logic applies to making them longer) You'll note... that was my original example.

> Including class variables?

You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.

Re: The tyranny of the Hollerith punched card

#93

Post by kens »

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

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…

The jump to 80-column video displays was due to late 1960s CRT-based computers for data entry such as Four Phase and Viatron, which allowed people to enter punched card data on a screen and edit it. These of course had 80-column input. These were followed by more general purpose video displays like the VT50, which also had 80 columns for compatibility with punched card systems. This led to terminal emulator windows such as xterm using 80 columns. It is a clear historical path. (I don't know why you're bringing the Apple II into this.)

Re: The tyranny of the Hollerith punched card

#94

Post by kiruwa »

sklogic wrote: post #92
kiruwa wrote: post #91

Earlier quoted context omitted.

Including class variables? Their context is far larger than the immediate code you're looking at, longer/descriptive names seem basically required there, as they have essentially similar scope to functions. (Same logic applies to making them longer) You'll note... that was my original example.

> Including class variables? You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.

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 (like vim!) have solved this non-problem anyways.

Re: The tyranny of the Hollerith punched card

#95

Post by Nano2rad »

jahewson wrote: post #47
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.

Most of this line length theory isn't backed up by any science. Newspapers are a particularly poor example as their line lengths are typically much too short to provide "good" readability. It's also worth noting that newspapers traditionally used columns because they allow individual articles to be typeset and then divided into pieces later during composition. Not because they offer some kind of readability advantage…

Maybe 80 is standard for code. Newspaper may have another ergonomic standard, also bible.

Re: The tyranny of the Hollerith punched card

#96

Post by outworlder »

"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 writing Scheme code. Or doing python with a 4 space indentation. But it may be too much for older folks.

I feel that the reason we have computers is to deal with this kind of stuff, so why can't we do whatever we want and have the computer display the way we like?

Re: The tyranny of the Hollerith punched card

#97

Post by dragonwriter »

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

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 they were used where they offered superior utility. But, outside of a few niches, 80 columns stuck even in the face of alternatives, and the reason it did so was ergonomics.

Re: The tyranny of the Hollerith punched card

#98

Post by ptx »

Karunamon wrote: post #63
tamana wrote: post #23

Earlier quoted context omitted.

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

If you weren't forced to indent when appropriate, and chose not to, I think that would damage readability even more.

There are contexts when Python doesn't force you to, such as the example the article shows as "ways [that] actually make our code less obvious and less readable":

  err("HTTP 403 Forbidden -"
  " Does your bitbucket user have rights to the repo?\n")
But if you indent it properly, I don't think it's less readable than the extra-long-line-with-scrolling:

  err("HTTP 403 Forbidden -"
      " Does your bitbucket user have rights to the repo?\n")
The other example,

  build_url = "{url}/pipelines/{pipeline}/jobs/{jobname}/builds/{buildname}".format(
      url=os.environ['ATC_EXTERNAL_URL'],
      pipeline=os.environ['BUILD_PIPELINE_NAME'],
      jobname=os.environ['BUILD_JOB_NAME'],
      buildname=os.environ['BUILD_NAME'],
  )
could perhaps be written as

  urltmpl = "{url}/pipelines/{pipeline}/jobs/{jobname}/builds/{buildname}"
  build_url = urltmpl.format(
      ...
or like this:

  build_url = "/".join((os.environ['ATC_EXTERNAL_URL'],
                       "pipelines", os.environ['BUILD_PIPELINE_NAME'],
                       "jobs", os.environ['BUILD_JOB_NAME'],
                       "builds", os.environ['BUILD_NAME']))

Re: The tyranny of the Hollerith punched card

#99

Post by ptx »

mavhc wrote: post #87
ptx wrote: post #84

> But breaking the statement arbitrarily at some point > seems more like saying that you have to end a sentence > at the end of each line, whether the sentence is finished > or not because, you know, that's the way it's always been > done. (I know it's not a perfect analogy.) Isn't it more like line-breaking sentences at the edge of a paper page, which we do, and which is perfectly reasonable because of the page's fi…

Sounds like lines should change width more often to make such silly bugs noticeable so they can be fixed.

What's the silly bug? How should it work if it were fixed?

Re: The tyranny of the Hollerith punched card

#100

Post by jcranmer »

endymi0n wrote: post #71

Related: Why the space shuttle size is related to a horse's back end :) http://www.astrodigital.org/space/stshorse.html

That is more fiction than fact.

The first railroads in the US and UK standardized fairly quickly on 4'8½", but that's not the only size (even today!). The Great Western Railway, for example, was infamously at a 7' gauge. Even in the US, most railroads in the south converged on a 5' gauge until they shifted to 4'9" (not 4'8½"!) on May 31, 1886. The gauge differences in very early (1820s and 1830s) railways were just as diverse as the coal tramways that proceeded them--which means you basically have every value between 4'6" and 5' as the actual track gauge.

Of course, that belies the fact that your track gauge does not determine what you can stick on a train. That's the loading gauge, and these are nowhere near as consistent. The UIC standard loading gauge in Europe is 3.15 m wide, while the standard US loading gauge is 3.25 wide--and they both share the 4'8½" track gauge. (Note: the actual adherence to these standards, particularly in 100+ year-old railways, is a different matter.)

Post reply on HN