12 ms·

The tyranny of the Hollerith punched card

123 points by wtbob 10y ago

patrickmay 10y ago
50-75 characters is the optimal line width for the human eye to scan: http://baymard.com/blog/line-length-readability http://baymard.com/blog/line-length-readability
- falcolas 10y ago
  I think the biggest problem with translating this into code widths is that we use indentation liberally. Seeing 6-12 characters taken up by whitespace is nowhere near uncommon. So, given that, perhaps 80 characters isn't so tyrannical...
  - vertex-four 10y ago
    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.
    - andrey_utkin 10y ago
      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(); } } }
      - zokier 10y ago
        I think most people have converged to 4 space tabstops, so 24 spaces means 6 levels of indentation.
        sixothree 10y ago
        Namespace, class, method, loop, conditional brings us to 20.
      - vertex-four 10y ago
        I don't actually know of any project which uses 6 or 8 characters per indentation level.
        andrey_utkin 10y ago
        8 chars is default tab size. So e.g. "git diff" shows you 8-position tabs. Github (and Bitbucket, etc.) diff visualizer also shows it as 8 positions. Any editor should use 8 by default, too. And, believe me or not my space-loving friends, tab-indented codebases still exist.
        vertex-four 10y ago
        My editor definitely puts tabstops at 4. Weird.
        khedoros 10y ago
        My first change to any editor is to set tabstops at 4 characters. That's the standard policy at my employer, and I like it for my own projects, as well.
- OneOneOneOne 10y ago
  For code it also seems most of the text reside on the left. Opening an extra wide window to display text for the occasional long line seems a waste of screen space.
  - mnw21cam 10y ago
    Indeed. The rule for prose is that a text block width should be somewhere between 2.5 and 3.5 full alphabets. This takes into account the variable spacing of different characters. This is to strike a balance between having inconsistent space or too much hyphenation (if the line is too short) and the eye's ability to find the next line when scanning leftwards from the end of the previous line (which is difficult if the line is too long). Code is different in several ways. Firstly, code is generally shown in monospace typeface. Secondly, breaking lines too early can be even worse for code than for prose. Thirdly, even with a long line limit, code will generally have lots of short lines anyway, and this helps the eye find the next line when reading. The long lines (as long as they aren't all long) stick out from the rest of the code text, making it easier to read.
  - tamana 10y ago
    That's why your editor has soft line break capability.
- LionessLover 10y ago
  First, we are not reading text but code. Second, we code very differently then we used to - several layers of indentation are common now but were not when the limit was seen as reasonable.
- jahewson 10y ago
  It's nice that some typographers think this but the claim doesn't seem to be backed up by any evidence.
stygiansonic 10y ago
While the first example of car sizes and Roman chariots is likely incorrect (as the article itself points out, and it's also suspiciously familiar to the debunked railroad gauge/Roman chariot story[0]), I'm always fascinated by stories like this. It underlies the organic nature by which many of our systems have grown. The same kind of "cruft" you see in systems and designs that have been around for a long time (Why is it the "Referer" header in HTTP? Why do we still call it Ajax/XHR when XML is rarely used?) is seen in many aspects of life. Etymology is choke full of them. Consider the word, "consider" - its roots may have meant something like "consult the stars" at one point in time. (I think I first read about this in Sagan's Cosmos) 0. http://www.snopes.com/history/american/gauge.asp http://www.snopes.com/history/american/gauge.asp 1. http://www.etymonline.com/index.php?term=consider http://www.etymonline.com/index.php?term=consider
- a_bonobo 10y ago
  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/ 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)
  - jandrese 10y ago
    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 reliably placed on Qwerty keyboards, whereas any other keys may or may not remain in a sensible location, especially back in the old days before keyboard layouts settled down.
    - _acme 10y ago
      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 https://en.wikipedia.org/wiki/Arrow_keys#HJKL_keys.
benbenolson 10y ago
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's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle. Now we only need to think of things that have developed for historical purposes, yet are not reasonable defaults.
- DanBC 10y ago
  > 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. Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks. What's current best practice? Or is it just down to the project style guide?
  - andrey_utkin 10y ago
    I guess these are enough general: put operator sign before line break; don't break inside of the most nested expression; don't break between variable type and name... There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
  - zyxley 10y ago
    gofmt comes to mind here. It renders the particulars of what you do while writing a non-issue by taking any valid Go input and producing a "canonical" final formatted version.
audeyisaacs 10y ago
Cars are pretty well sized for fitting two people side by side(and the appropriate controls). 80 columns is a pretty good length for lines of text. I see no tyranny here.
Sindisil 10y ago
I've heard this reasoning (that 80 col terms are directly due to the 80 cols on a punched card), but never any proof. Frankly, it sounds like numerology, to me. "Hey! Both these numbers are 80, and they describe closely related dimensions. No way that's a coincidence! The newer one must have been specifically chosen to match the older one." While it could of course be true, until I see reasonable proof, I'm going to assume that both values were the outcome of fitting a data representation (holes or characters) into a size that was effectively fixed for other reasons (standard card size, commonly available paper and CRT widths). Especially since IBM later put out 96 column cards.
deleted 10y ago
[deleted]
ars 10y ago
The banana/monkey story is not actually true, it was not tested as described, and a somewhat similar test did not have clear results. http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-banana-story-is-rubbish/ http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...
- pohl 10y ago
  I like the Ricky Gervais bathtub selfie in that article.
Shivetya 10y ago
Going to go with the fact that original cards were the same size as paper currency at the time and re purposing of equipment to handle paper currency was the expedient thing to do.
lisper 10y ago
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 card, but because 80 characters is a good ergonomic width.
- pricechild 10y ago
  > Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line, Maybe because it was written from a terminal?
- sevensor 10y ago
  I agree, and I was thinking the same thing as I read the article. Even so, I'm glad we're talking about history. 79 or 81 characters would be pretty much the same. You have to know the history to understand why 80 is a magic number. And why does my terminal window have a baud rate? Why is it so slow?
- kazinator 10y ago
  "Ergonomic" in the same sentence as "Hollerith card" can only be tongue-in-cheek humor.
  - slantyyz 10y ago
    A little offtopic and showing my age, but in 1985, personal computers were still a little expensive, and my high school couldn't afford an Apple ][ lab yet, but we did have a Digital PDP-(something) mini computer with a card reader (probably a donated relic). In my grade 10 "Data Processing" class (when was the last time you heard someone use the term Data Processing?), we had to use IBM cards with a Sharpie (the card reader was thankfully an optical reader vs a punch card reader) to write programs in BASIC (when BASIC still used line numbers). When we had tests, we had to basically write our programs at our desks on cards, run to the card reader to run and check our results on a printout. It made for some hilariously tedious debugging cycles. If my memory serves correctly, back in that era, having an 80 column card on your Apple II was something worth bragging about.
dilap 10y ago
emacs, submlime, xcode can soft wrap code well (indenting a little extra on the wrap). wrap for semantics, not any arbitrary boundary, and then you can view the code perfectly across many different resolutions & window configurations (2-up, 3-up, whatever).
theophrastus 10y ago
Someone already knows the answer to this, (but not me): if you examine a statistically representative set of ancient books, (both pre- and post- Gutenberg) what is the average line length? And doesn't that partially depend on "standard" parchment/vellum size? And doesn't that depend on the size of a young sheep's belly? ("The tyranny of the size of sheep!" Where's James Burke when you need him?)
jdblair 10y ago
Interesting fact: the Hollerith punched card is the same size as the dollar bill in 1890. This is because Hollerith was able to take advantage of existing stacking and sorting equipment already designed for banks. http://infolab.stanford.edu/pub/voy/museum/pictures/display/2-2-ElecKeyPunch.htm http://infolab.stanford.edu/pub/voy/museum/pictures/display/...
- kens 10y ago
  Strangely, punched cards are just a bit bigger than the old US currency, not exactly the same size. Also strange: nobody knows exactly how big the old currency was. To be precise, there are three slightly different sizes quoted as the official size. I asked the Bureau of Engraving and Printing about this - they print the money so they should know - and they couldn't explain the discrepancy.
simula67 10y ago
Similar story about the bin, sbin, usr/bin , usr/sbin split in UNIX : http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
derekp7 10y ago
Out of curiosity, where did the 132 column standard (for wide carriage printers) come from (why 132, not 130 or 120)?
- ddebernardy 10y ago
  Likely because of the VT100: http://vt100.net/docs/tp83/chapter5.html 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.)
  - mturmon 10y ago
    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 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.
  - derekp7 10y ago
    So in this case, the 132 column printer came after the 132 column vt100 series?
- kens 10y ago
  That's a good question, and I've been trying for weeks to find the answer. 132 columns for printers is way older than video terminals, dating back to the IBM 1403 printer from 1959. I've studied the 1403 printer closely and asked the IBM history experts, but nobody seems to know exactly where 132 columns came from. One theory is IBM wanted to have more columns than competitors with 120 columns, so went to 132, but that's not a completely satisfying answer. I wonder if 132 is a limit due to the (surprisingly complex) timing of the print chain, but haven't been able to nail it down. I've studied the 1403 printer's circuitry in detail, and haven't seen any reason for 132 columns. If the printer had 12 characters per inch, 11 inch wide paper would have 132 characters, but the printer has 10 characters per inch so that doesn't explain it.
torgoguys 10y ago
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?
- kens 10y ago
  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.computerhistory.org/hours/ http://www.computerhistory.org/hours/
  - khedoros 10y ago
    Ha, I had the same thought, but only saw your comment when I refreshed the thread.
  - benjohnson 10y ago
    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.
- khedoros 10y ago
  I'm not sure whether it will be of any practical use, but the Computer History Museum in Mountain View has an IBM 1401 on display, along with some IBM 026 card punches. They do demos of the hardware, and they'll sometimes punch little bits of data into cards, if you request it (my wife got our names punched in). I don't know about larger requests, like punching realistic program data into multiple cards, but it couldn't hurt to ask, right? They've got contact info on their site: http://www.computerhistory.org/contact/ http://www.computerhistory.org/contact/ It may be worth it to send an e-mail to see what you could work out.
intrasight 10y ago
I've switched all my settings (terminal, console, emacs) to 120 characters.
mxfh 10y ago
They could have gone with backwards-compatibility for Jacquard's 11x4 loom cards; so no "tyranny" here. http://homepage.cs.uiowa.edu/~jones/cards/history.html http://homepage.cs.uiowa.edu/~jones/cards/history.html
raverbashing 10y ago
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 80 columns, I care about having a hard limit My current terminal is 110 chars wide, and that's because I use a bigger font.
- lukeschlather 10y ago
  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.
kiruwa 10y ago
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, invalidating the research the "80 character optimization" was based on. Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".
- hughes 10y ago
  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.
  - kiruwa 10y ago
    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.
    - to3m 10y ago
      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 to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.
Etheryte 10y ago
Looks like the page has been HN-ed, not loading anymore. Google cache has the content if anyone else has the issue.
marcosdumay 10y ago
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.
endymi0n 10y ago
Related: Why the space shuttle size is related to a horse's back end :) http://www.astrodigital.org/space/stshorse.html http://www.astrodigital.org/space/stshorse.html
- jcranmer 10y ago
  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.)
notthemessiah 10y ago
From the title, I thought it would be about IBM's intimate connections to Nazi Germany.
Glyptodon 10y ago
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 languages from class declaration to control flow) and it's well worth it to use 120 char lines. (And if you write Java you probably need even more space to handle stuff since class names are often a ridiculous number of words long...) Outside of programming languages, I also think the 80 char limit is terrible for readable html or html templates.
- mkehrt 10y ago
  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!
ptx 10y ago
> 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 fixed size? Sure, you can design your document for a different paper size, but then you have to reconfigure the printer for that size, make sure you have the right paper size loaded in the printer (and change it back afterwards!), get new envelopes in the new size, get new binders... Similarly, if I read a program wider than 80 characters, I have to resize my terminal window and my Emacs window. When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines, unless I remember to resize things back to normal, which in turn perpetuates the problem. So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) or we could just decide to stick to the standard 80 columns which, as many comments here have pointed out, is a reasonable choice to standardize on even if it's arbitrary.
- mavhc 10y ago
  Sounds like lines should change width more often to make such silly bugs noticeable so they can be fixed.
  - ptx 10y ago
    What's the silly bug? How should it work if it were fixed?
    - mavhc 10y ago
      > I have to resize my terminal window and my Emacs window. Should be an option to auto resize or auto wrap > When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines unless I remember to resize things back to normal, which in turn perpetuates the problem. Why would a program care about what size the window was when you ran it in the past? > So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) Isn't that exactly what a GUI is for?
outworlder 10y ago
"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?
- grkvlt 10y ago
  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?
mdip 10y ago
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 have been improved by leaving parts of those ten lines on a single line. I can understand the benefits, though, to having sane rules around "how much can go in one line", I just think the overall width of a line is of way lower importance than breaking things up into logical parts -- especially in C# in code that avoids LINQ statements[1] where method chaining can result in some extremely wide, difficult to parse, code. I write almost all of my software on a Widescreen 1080P display where vertical real-estate is vastly lacking and horizontal real-estate is greatly underutilized. I use a pragmatic approach over artificial hard barriers and the assumption that I'll be using my display to look at code the way I do 99% of the time - one or two code files on screen at a time (but almost always a single code file). My code still tends to mostly prefer vertical orientation. I use these simple rules: (1) Avoid same-line chaining (Even "ToList" or "ToArray" gets its own line). Line up the dots of the calls with the previous line's dot to make it easy to see it's a part of a chain. This results in "wider" code but makes that code able to be parsed quickly while not wasting vertical space. (2) Avoid more than one statement per line (conditionals excluded where readability requires -- doing if (isThis && isThat && string1==string2 && string3==string4) would put the two string comparisons on two separate lines usually). (3) Omit (yes, omit) braces for single statements that don't have indented single statements below them. This gets me yelled at sometimes, but my IDE enforces code formatting for me, so the drawbacks of "accidentally having a statement appear to apply to a conditional that it doesn't" don't happen and with the lack of newlines-for-newlines'-sake in my code, code that's indented for branched statements is easily discernible from code that has a newline due to chaining or some other reason. (4) Break the rules if readability is improved and avoid religious wars. At the end of the day, I can live with nearly any code formatting ruleset. I read code more than I write it and I end up reading code that follows a large variety of rules so I try not to be a pain in the ass about it. If I haven't been the most substantial contributor to a project, I follow the other person's rules. If I have, I hope that they'll follow mine. The result has been few, if any, arguments over "tabs vs. spaces" theology. [1] I have never liked the LINQ statement format as I find it hard to follow "What's Being Done" so I have, with rare exception, stuck with method chains.
GnarfGnarf 10y ago
Actually, if you subtract the columns used for sequence numbers and statement labels, in FORTRAN and COBOL you only had about 65 to 68 columns of code. In one of my early jobs, we used binary format to store data in Hollerith cards. Twelve rows were divided into three groups of four bits, giving us three digits per column, or 240 digits per 80-column card. The cards looked like lace doilies.
GnarfGnarf 10y ago
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 rollers, and smoke started billowing from the machine. IBM sold the "Multi-function Card Machine", or "MFCM". Customers called it the "Mother Fletcher Card Masher", except they had another word for the "F". The computer's card punch could only do 200 cards/min. In humid weather, cards would swell and jam the reader's picker knife. I was so glad when we switched to mag. tape.
- grkvlt 10y ago
  > 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 themselves have no problem with expletives. It certainly doesn't protect viewers from seeing the taboo word, as a string of punctuation like "#&$!" might, so that isn't the purpose. Wildly off-topic, so apologies...
  - GnarfGnarf 10y ago
    I was just trying to convey the sensitivities of the era. As a Quebecker, I am not averse to expletives :o)
irrational 10y ago
I'm a programmer, but I don't have any sort of CS degree. Is the 80 character line limit something that is typically taught to CS students? I had been programming for 15+ years before I ran into references to this limit. I'm still not really sure what it means. Do most developers set up their IDEs to let them know when they have gone over the limit?
YeGoblynQueenne 10y ago
>> Now, just for laughs, run stty inside your xterm or in Terminal.app and tell me why your window has a baud rate. That gentleman just made me make my powershell terminal choke.

123 points by wtbob 10y ago

50-75 characters is the optimal line width for the human eye to scan: http://baymard.com/blog/line-length-readability http://baymard.com/blog/line-length-readability

falcolas 10y ago
I think the biggest problem with translating this into code widths is that we use indentation liberally. Seeing 6-12 characters taken up by whitespace is nowhere near uncommon. So, given that, perhaps 80 characters isn't so tyrannical...
- vertex-four 10y ago
  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.
  - andrey_utkin 10y ago
    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(); } } }
    - zokier 10y ago
      I think most people have converged to 4 space tabstops, so 24 spaces means 6 levels of indentation.
      - sixothree 10y ago
        Namespace, class, method, loop, conditional brings us to 20.
    - vertex-four 10y ago
      I don't actually know of any project which uses 6 or 8 characters per indentation level.
      - andrey_utkin 10y ago
        8 chars is default tab size. So e.g. "git diff" shows you 8-position tabs. Github (and Bitbucket, etc.) diff visualizer also shows it as 8 positions. Any editor should use 8 by default, too. And, believe me or not my space-loving friends, tab-indented codebases still exist.
        vertex-four 10y ago
        My editor definitely puts tabstops at 4. Weird.
        khedoros 10y ago
        My first change to any editor is to set tabstops at 4 characters. That's the standard policy at my employer, and I like it for my own projects, as well.
OneOneOneOne 10y ago
For code it also seems most of the text reside on the left. Opening an extra wide window to display text for the occasional long line seems a waste of screen space.
- mnw21cam 10y ago
  Indeed. The rule for prose is that a text block width should be somewhere between 2.5 and 3.5 full alphabets. This takes into account the variable spacing of different characters. This is to strike a balance between having inconsistent space or too much hyphenation (if the line is too short) and the eye's ability to find the next line when scanning leftwards from the end of the previous line (which is difficult if the line is too long). Code is different in several ways. Firstly, code is generally shown in monospace typeface. Secondly, breaking lines too early can be even worse for code than for prose. Thirdly, even with a long line limit, code will generally have lots of short lines anyway, and this helps the eye find the next line when reading. The long lines (as long as they aren't all long) stick out from the rest of the code text, making it easier to read.
- tamana 10y ago
  That's why your editor has soft line break capability.
LionessLover 10y ago
First, we are not reading text but code. Second, we code very differently then we used to - several layers of indentation are common now but were not when the limit was seen as reasonable.
jahewson 10y ago
It's nice that some typographers think this but the claim doesn't seem to be backed up by any evidence.

stygiansonic 10y ago

While the first example of car sizes and Roman chariots is likely incorrect (as the article itself points out, and it's also suspiciously familiar to the debunked railroad gauge/Roman chariot story[0]), I'm always fascinated by stories like this. It underlies the organic nature by which many of our systems have grown. The same kind of "cruft" you see in systems and designs that have been around for a long time (Why is it the "Referer" header in HTTP? Why do we still call it Ajax/XHR when XML is rarely used?) is seen in many aspects of life. Etymology is choke full of them. Consider the word, "consider" - its roots may have meant something like "consult the stars" at one point in time. (I think I first read about this in Sagan's Cosmos) 0. http://www.snopes.com/history/american/gauge.asp http://www.snopes.com/history/american/gauge.asp 1. http://www.etymonline.com/index.php?term=consider http://www.etymonline.com/index.php?term=consider

a_bonobo 10y ago
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/ 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)
- jandrese 10y ago
  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 reliably placed on Qwerty keyboards, whereas any other keys may or may not remain in a sensible location, especially back in the old days before keyboard layouts settled down.
  - _acme 10y ago
    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 https://en.wikipedia.org/wiki/Arrow_keys#HJKL_keys.

benbenolson 10y ago

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's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle. Now we only need to think of things that have developed for historical purposes, yet are not reasonable defaults.

DanBC 10y ago
> 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. Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks. What's current best practice? Or is it just down to the project style guide?
- andrey_utkin 10y ago
  I guess these are enough general: put operator sign before line break; don't break inside of the most nested expression; don't break between variable type and name... There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
- zyxley 10y ago
  gofmt comes to mind here. It renders the particulars of what you do while writing a non-issue by taking any valid Go input and producing a "canonical" final formatted version.

audeyisaacs 10y ago

Cars are pretty well sized for fitting two people side by side(and the appropriate controls). 80 columns is a pretty good length for lines of text. I see no tyranny here.

Sindisil 10y ago

I've heard this reasoning (that 80 col terms are directly due to the 80 cols on a punched card), but never any proof. Frankly, it sounds like numerology, to me. "Hey! Both these numbers are 80, and they describe closely related dimensions. No way that's a coincidence! The newer one must have been specifically chosen to match the older one." While it could of course be true, until I see reasonable proof, I'm going to assume that both values were the outcome of fitting a data representation (holes or characters) into a size that was effectively fixed for other reasons (standard card size, commonly available paper and CRT widths). Especially since IBM later put out 96 column cards.

deleted 10y ago

[deleted]

ars 10y ago

The banana/monkey story is not actually true, it was not tested as described, and a somewhat similar test did not have clear results. http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-banana-story-is-rubbish/ http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...

pohl 10y ago
I like the Ricky Gervais bathtub selfie in that article.

Shivetya 10y ago

Going to go with the fact that original cards were the same size as paper currency at the time and re purposing of equipment to handle paper currency was the expedient thing to do.

lisper 10y ago

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 card, but because 80 characters is a good ergonomic width.

pricechild 10y ago
> Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line, Maybe because it was written from a terminal?
sevensor 10y ago
I agree, and I was thinking the same thing as I read the article. Even so, I'm glad we're talking about history. 79 or 81 characters would be pretty much the same. You have to know the history to understand why 80 is a magic number. And why does my terminal window have a baud rate? Why is it so slow?
kazinator 10y ago
"Ergonomic" in the same sentence as "Hollerith card" can only be tongue-in-cheek humor.
- slantyyz 10y ago
  A little offtopic and showing my age, but in 1985, personal computers were still a little expensive, and my high school couldn't afford an Apple ][ lab yet, but we did have a Digital PDP-(something) mini computer with a card reader (probably a donated relic). In my grade 10 "Data Processing" class (when was the last time you heard someone use the term Data Processing?), we had to use IBM cards with a Sharpie (the card reader was thankfully an optical reader vs a punch card reader) to write programs in BASIC (when BASIC still used line numbers). When we had tests, we had to basically write our programs at our desks on cards, run to the card reader to run and check our results on a printout. It made for some hilariously tedious debugging cycles. If my memory serves correctly, back in that era, having an 80 column card on your Apple II was something worth bragging about.

dilap 10y ago

emacs, submlime, xcode can soft wrap code well (indenting a little extra on the wrap). wrap for semantics, not any arbitrary boundary, and then you can view the code perfectly across many different resolutions & window configurations (2-up, 3-up, whatever).

theophrastus 10y ago

Someone already knows the answer to this, (but not me): if you examine a statistically representative set of ancient books, (both pre- and post- Gutenberg) what is the average line length? And doesn't that partially depend on "standard" parchment/vellum size? And doesn't that depend on the size of a young sheep's belly? ("The tyranny of the size of sheep!" Where's James Burke when you need him?)

jdblair 10y ago

Interesting fact: the Hollerith punched card is the same size as the dollar bill in 1890. This is because Hollerith was able to take advantage of existing stacking and sorting equipment already designed for banks. http://infolab.stanford.edu/pub/voy/museum/pictures/display/2-2-ElecKeyPunch.htm http://infolab.stanford.edu/pub/voy/museum/pictures/display/...

kens 10y ago
Strangely, punched cards are just a bit bigger than the old US currency, not exactly the same size. Also strange: nobody knows exactly how big the old currency was. To be precise, there are three slightly different sizes quoted as the official size. I asked the Bureau of Engraving and Printing about this - they print the money so they should know - and they couldn't explain the discrepancy.

simula67 10y ago

Similar story about the bin, sbin, usr/bin , usr/sbin split in UNIX : http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...

derekp7 10y ago

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

ddebernardy 10y ago
Likely because of the VT100: http://vt100.net/docs/tp83/chapter5.html 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.)
- mturmon 10y ago
  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 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.
- derekp7 10y ago
  So in this case, the 132 column printer came after the 132 column vt100 series?
kens 10y ago
That's a good question, and I've been trying for weeks to find the answer. 132 columns for printers is way older than video terminals, dating back to the IBM 1403 printer from 1959. I've studied the 1403 printer closely and asked the IBM history experts, but nobody seems to know exactly where 132 columns came from. One theory is IBM wanted to have more columns than competitors with 120 columns, so went to 132, but that's not a completely satisfying answer. I wonder if 132 is a limit due to the (surprisingly complex) timing of the print chain, but haven't been able to nail it down. I've studied the 1403 printer's circuitry in detail, and haven't seen any reason for 132 columns. If the printer had 12 characters per inch, 11 inch wide paper would have 132 characters, but the printer has 10 characters per inch so that doesn't explain it.

torgoguys 10y ago

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?

kens 10y ago
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.computerhistory.org/hours/ http://www.computerhistory.org/hours/
- khedoros 10y ago
  Ha, I had the same thought, but only saw your comment when I refreshed the thread.
- benjohnson 10y ago
  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.
khedoros 10y ago
I'm not sure whether it will be of any practical use, but the Computer History Museum in Mountain View has an IBM 1401 on display, along with some IBM 026 card punches. They do demos of the hardware, and they'll sometimes punch little bits of data into cards, if you request it (my wife got our names punched in). I don't know about larger requests, like punching realistic program data into multiple cards, but it couldn't hurt to ask, right? They've got contact info on their site: http://www.computerhistory.org/contact/ http://www.computerhistory.org/contact/ It may be worth it to send an e-mail to see what you could work out.

intrasight 10y ago

I've switched all my settings (terminal, console, emacs) to 120 characters.

mxfh 10y ago

They could have gone with backwards-compatibility for Jacquard's 11x4 loom cards; so no "tyranny" here. http://homepage.cs.uiowa.edu/~jones/cards/history.html http://homepage.cs.uiowa.edu/~jones/cards/history.html

raverbashing 10y ago

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 80 columns, I care about having a hard limit My current terminal is 110 chars wide, and that's because I use a bigger font.

lukeschlather 10y ago
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.

kiruwa 10y ago

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, invalidating the research the "80 character optimization" was based on. Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".

hughes 10y ago
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.
- kiruwa 10y ago
  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.
  - to3m 10y ago
    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 to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.

Etheryte 10y ago

Looks like the page has been HN-ed, not loading anymore. Google cache has the content if anyone else has the issue.

marcosdumay 10y ago

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.

endymi0n 10y ago

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

jcranmer 10y ago
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.)

notthemessiah 10y ago

From the title, I thought it would be about IBM's intimate connections to Nazi Germany.

Glyptodon 10y ago

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 languages from class declaration to control flow) and it's well worth it to use 120 char lines. (And if you write Java you probably need even more space to handle stuff since class names are often a ridiculous number of words long...) Outside of programming languages, I also think the 80 char limit is terrible for readable html or html templates.

mkehrt 10y ago
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!

ptx 10y ago

> 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 fixed size? Sure, you can design your document for a different paper size, but then you have to reconfigure the printer for that size, make sure you have the right paper size loaded in the printer (and change it back afterwards!), get new envelopes in the new size, get new binders... Similarly, if I read a program wider than 80 characters, I have to resize my terminal window and my Emacs window. When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines, unless I remember to resize things back to normal, which in turn perpetuates the problem. So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) or we could just decide to stick to the standard 80 columns which, as many comments here have pointed out, is a reasonable choice to standardize on even if it's arbitrary.

mavhc 10y ago
Sounds like lines should change width more often to make such silly bugs noticeable so they can be fixed.
- ptx 10y ago
  What's the silly bug? How should it work if it were fixed?
  - mavhc 10y ago
    > I have to resize my terminal window and my Emacs window. Should be an option to auto resize or auto wrap > When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines unless I remember to resize things back to normal, which in turn perpetuates the problem. Why would a program care about what size the window was when you ran it in the past? > So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) Isn't that exactly what a GUI is for?

outworlder 10y ago

"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?

grkvlt 10y ago
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?

mdip 10y ago

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 have been improved by leaving parts of those ten lines on a single line. I can understand the benefits, though, to having sane rules around "how much can go in one line", I just think the overall width of a line is of way lower importance than breaking things up into logical parts -- especially in C# in code that avoids LINQ statements[1] where method chaining can result in some extremely wide, difficult to parse, code. I write almost all of my software on a Widescreen 1080P display where vertical real-estate is vastly lacking and horizontal real-estate is greatly underutilized. I use a pragmatic approach over artificial hard barriers and the assumption that I'll be using my display to look at code the way I do 99% of the time - one or two code files on screen at a time (but almost always a single code file). My code still tends to mostly prefer vertical orientation. I use these simple rules: (1) Avoid same-line chaining (Even "ToList" or "ToArray" gets its own line). Line up the dots of the calls with the previous line's dot to make it easy to see it's a part of a chain. This results in "wider" code but makes that code able to be parsed quickly while not wasting vertical space. (2) Avoid more than one statement per line (conditionals excluded where readability requires -- doing if (isThis && isThat && string1==string2 && string3==string4) would put the two string comparisons on two separate lines usually). (3) Omit (yes, omit) braces for single statements that don't have indented single statements below them. This gets me yelled at sometimes, but my IDE enforces code formatting for me, so the drawbacks of "accidentally having a statement appear to apply to a conditional that it doesn't" don't happen and with the lack of newlines-for-newlines'-sake in my code, code that's indented for branched statements is easily discernible from code that has a newline due to chaining or some other reason. (4) Break the rules if readability is improved and avoid religious wars. At the end of the day, I can live with nearly any code formatting ruleset. I read code more than I write it and I end up reading code that follows a large variety of rules so I try not to be a pain in the ass about it. If I haven't been the most substantial contributor to a project, I follow the other person's rules. If I have, I hope that they'll follow mine. The result has been few, if any, arguments over "tabs vs. spaces" theology. [1] I have never liked the LINQ statement format as I find it hard to follow "What's Being Done" so I have, with rare exception, stuck with method chains.

GnarfGnarf 10y ago

Actually, if you subtract the columns used for sequence numbers and statement labels, in FORTRAN and COBOL you only had about 65 to 68 columns of code. In one of my early jobs, we used binary format to store data in Hollerith cards. Twelve rows were divided into three groups of four bits, giving us three digits per column, or 240 digits per 80-column card. The cards looked like lace doilies.

GnarfGnarf 10y ago

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 rollers, and smoke started billowing from the machine. IBM sold the "Multi-function Card Machine", or "MFCM". Customers called it the "Mother Fletcher Card Masher", except they had another word for the "F". The computer's card punch could only do 200 cards/min. In humid weather, cards would swell and jam the reader's picker knife. I was so glad when we switched to mag. tape.

grkvlt 10y ago
> 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 themselves have no problem with expletives. It certainly doesn't protect viewers from seeing the taboo word, as a string of punctuation like "#&$!" might, so that isn't the purpose. Wildly off-topic, so apologies...
- GnarfGnarf 10y ago
  I was just trying to convey the sensitivities of the era. As a Quebecker, I am not averse to expletives :o)

irrational 10y ago

I'm a programmer, but I don't have any sort of CS degree. Is the 80 character line limit something that is typically taught to CS students? I had been programming for 15+ years before I ran into references to this limit. I'm still not really sure what it means. Do most developers set up their IDEs to let them know when they have gone over the limit?

YeGoblynQueenne 10y ago

>> Now, just for laughs, run stty inside your xterm or in Terminal.app and tell me why your window has a baud rate. That gentleman just made me make my powershell terminal choke.