
The tyranny of the Hollerith punched card - wtbob
http://pub.gajendra.net/2012/09/hollerith_tyranny
======
lisper
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.

~~~
kens
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 allowed narrower holes so 80
columns would fit. They chose the latter because it was more compatible with
existing card sorting equipment, and the rest is history. Competitors used 90
column cards, but didn't achieve the same success as IBM. IBM later introduced
96-column cards, but they weren't as popular. Thus, it's just a historical
accident that everyone uses 80 columns rather than 90 or 96. And 80 columns is
used because that's how many could fit on a punched card the size of obsolete
US currency. Note that ergonomics has nothing to do with the success of 80
columns: for the most part these cards held accounting data, not program code
or text. (I wrote an article covering this in great detail but haven't posted
it to my blog yet; hopefully I'll get it out soon.)

[1] [http://www.righto.com/2016/05/inside-card-
sorters-1920s-data...](http://www.righto.com/2016/05/inside-card-
sorters-1920s-data.html)

~~~
lisper
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 technology we went to 80 rather than
(say) 132 because 132 is too long. We can quibble over 80 vs 90 or 96 (or 72),
but it's pretty clear that the sweet spot is right in there somewhere. It is
not at all like (say) electrical outlets where we really do have to do deal
with all kinds of crazy incompatibilities when traveling for no reason other
than historical accident.

~~~
kens
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.)

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

~~~
strictnein
80 characters seems really narrow. IDEs like IntelliJ put a guideline at 120
characters, which basically allows two full width editing windows side by side
(depending on your font size) at the pretty standard resolution of 1920x1080.

We've all got widescreen monitors now, right? So it makes sense that people
are going well past 80 characters.

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

~~~
strictnein
I don't think we read code the same way we read normal text. If you have this
in your code:

    
    
        qry.setParameter("a", a);
        qry.setParameter("b", b);
        qry.setParameter("foo", foo);
        qry.setParameter("bar", bar);
    

After the first "qry.setParameter" you're no longer reading anything but the
parameters and your eyes are moving vertically.

Or if you have something like this:

    
    
        Query qry = getEntityManager().createNamedQuery("User.findUserBySomething", Long.class);
    

You're only reading the "User.findUserBySomething". The rest of it is mainly
fluff.

~~~
lukeschlather
Just for the record, that bit of code gets cut off at ", Long." for me, and
then there's a scrollbar. (I always read HN zoomed-in.)

~~~
jdbernard
There's a CSS rule constraining the width of <pre> blocks to 600px.

------
jdblair
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/...](http://infolab.stanford.edu/pub/voy/museum/pictures/display/2-2-ElecKeyPunch.htm)

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

------
patrickmay
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)

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

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

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

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

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

------
GnarfGnarf
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
> 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
I was just trying to convey the sensitivities of the era. As a Quebecker, I am
not averse to expletives :o)

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

~~~
sklogic
> 80 is an _awful_ width for code in a programming paradigm encouraging long
> variable names

Which is exactly why all such paradigms are _awful_.

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

~~~
yongjik
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 should be tempered with a matching
desire for conciseness. Otherwise you end up with names like
MaybeUpdateDisplayParameterListForValidation. Throw twenty of these names onto
a screen, and I have no idea what the hell is going on: I can't even figure
out which names are the same at a glance.

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

------
Glyptodon
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
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!

------
theophrastus
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?)

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

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

------
torgoguys
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
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/)

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

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

~~~
grkvlt
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?

------
ptx

      > 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
Sounds like lines should change width more often to make such silly bugs
noticeable so they can be fixed.

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

~~~
mavhc
> 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?

------
ars
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-...](http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-banana-
story-is-rubbish/)

~~~
pohl
I like the Ricky Gervais bathtub selfie in that article.

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

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

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

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

------
mxfh
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)

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

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

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

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

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

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

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

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

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

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

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

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

