"This approach is not portable: it'll only work on Unixy os."
I weep for the lost souls of those poor benighted developers still stuck on Windows. No, no wait. why should we care about Windows developers? If they're still stuck there most likely they are deeply committed to the Microsoft Visual Studio toolset, in which case they don't (or can't) care about what goes on in the rest of the universe, and they really don't matter. (By which of course I mean that as fellow human beings they matter, and of course I have sympathy for their suffering, but by their own choice they are locked in such an impregnable ivory tower that it is neither practical nor economic to try to break in and rescue them)
Other than that, who else uses Windows? Oh yes, you have corporate teams doing 'enterprise' Java. They'll typically be using some colossally retarded Ant build system that takes 7-30 minutes to run (sadly, I'm not even exaggerating for dramatic effect). The problem with Ant is it is so easy to just bolt on 'one more thing' that it rapidly evolves to some horrible beast of a thing that lumbers around sucking everything into it, Katamari Damacy style. Really, there's no help for them either. You can't for example suggest that blowing away the entire database and recreating it from scratch in order to run the entire set of automated unit tests is something best left to the continuous integration server, or that should be done once a day - maybe out of hours or at lunchtime. No no, it has to be done every time you do a build. And that doesn't even touch on the ginormous mess that is the enterprise components, where each application server has its own arcane and unholy rituals to create its beans from the blood of unicorns and tears of virgin developers... try messing with that abomination and you're in for a world of pain. There's just no helping them either, though in their case usually they want to be helped, but they are captive to the primary problem of enterprise development, which is that the people who choose technologies and mandate tools and processes are usually so far removed from the actual use of those tools as to be completely immune to the pain, and unable or unwilling to hear the wailing and gnashing of teeth of the programmers.
Don't even get me started on checkstyle with rules like no line can be longer than 80 characters (despite there being absolutely no good reason for this other than the horrible horrible UI of eclipse - in the absence of that you can easily get way more than 80 characters on the screen).
The first line of my above comment, when viewed in the comments section of my profile came to 216 characters. That is with two sidebars of whitespace each taking up 10% of the horizontal width. I have neither an especially large monitor, nor an especially small font. In fact, I have the font cranked up slightly from the norm in order to avoid eyestrain. (Ironically, when I copy and paste said first line into a word processor, at that font size it fits significantly less than 80 characters per line, which goes to show just how that 216 should be considered an understatement of the horizontal screen real estate available for most people)
In a corporate environment, it is not unreasonable to assume that the developer can have a second monitor. Sometimes you have to gasp be nice to someone in order to get it, but that is not too onerous. Hence I believe your view is outdated; in practice horizontal is much cheaper than vertical.
When printing, one should probably do a few things in order to improve the appearance on paper anyway. Examples - you might want to set the indentation depth a little less than normal, say 2 spaces. You should also twiddle the font until it looks good, or is good for purpose (there are different reasons to print out code) and you might want to concatenate several smaller classes onto a single page, or remove the 20 line header of corporate pseudo-legalese from the top of each class, or even remove the imports, or not print the getters and setters. In other words, unless your purpose is to murder trees, you will likely hand-tune the printing to optimise it, at which time you might choose to set an 80 column width - if you felt that having each page consist mostly of a thin column of text pressed up against the right hand side of the page was the most aesthetically pleasing thing.
----
Run over lines do look a little bit ugly when printed I admit, this is true. However, since code is viewed 10-100x more often on screen than on paper, I believe it is inefficient to prioritise for printing (in a cart before the horse sense). Moreover, since the choice is between a little bit of ugliness when printed (inifinitely many chars per line) compared to a lot of ugliness when viewed on screen (80 char limit causing frequent line breaks, which are themselves heavily indented, which makes the run on itself more likely to spawn a run on), I prefer the lesser of two evils.
I guess I see "fits in 80" as a virtue. If it's pushed up against the right hand margin, I tend to refactor. Code that I can't make look nice in 80 cols, is very often code I don't like maintaining over time.
I weep for the lost souls of those poor benighted developers still stuck on Windows. No, no wait. why should we care about Windows developers? If they're still stuck there most likely they are deeply committed to the Microsoft Visual Studio toolset, in which case they don't (or can't) care about what goes on in the rest of the universe, and they really don't matter. (By which of course I mean that as fellow human beings they matter, and of course I have sympathy for their suffering, but by their own choice they are locked in such an impregnable ivory tower that it is neither practical nor economic to try to break in and rescue them)
Other than that, who else uses Windows? Oh yes, you have corporate teams doing 'enterprise' Java. They'll typically be using some colossally retarded Ant build system that takes 7-30 minutes to run (sadly, I'm not even exaggerating for dramatic effect). The problem with Ant is it is so easy to just bolt on 'one more thing' that it rapidly evolves to some horrible beast of a thing that lumbers around sucking everything into it, Katamari Damacy style. Really, there's no help for them either. You can't for example suggest that blowing away the entire database and recreating it from scratch in order to run the entire set of automated unit tests is something best left to the continuous integration server, or that should be done once a day - maybe out of hours or at lunchtime. No no, it has to be done every time you do a build. And that doesn't even touch on the ginormous mess that is the enterprise components, where each application server has its own arcane and unholy rituals to create its beans from the blood of unicorns and tears of virgin developers... try messing with that abomination and you're in for a world of pain. There's just no helping them either, though in their case usually they want to be helped, but they are captive to the primary problem of enterprise development, which is that the people who choose technologies and mandate tools and processes are usually so far removed from the actual use of those tools as to be completely immune to the pain, and unable or unwilling to hear the wailing and gnashing of teeth of the programmers.
Don't even get me started on checkstyle with rules like no line can be longer than 80 characters (despite there being absolutely no good reason for this other than the horrible horrible UI of eclipse - in the absence of that you can easily get way more than 80 characters on the screen).
twitch