On Wed, Nov 08, 2017 at 04:19:49PM -0500, Dan Cross wrote: Not really. Programmers need windows side by side. Lots and lots of bit mapped displays can handle 2 80 column windows at a reasonable font size. And I made the point about side by side diff tools. And I made the point about being able to read down the center and get the rest through peripheral vision. Would I like wider? Not really, at this point the vast majority of the code I look at, the man pages and other docs I look, they all fit in 80 columns. Sure, you could pick something else but you are just fighting reality. It's like video on phones. We still call it taping. Probably still will in a 100 years. Where's the tape? In history.

On Wed, 8 Nov 2017, Larry McVoy wrote: As with the resurgence of 33 1/3 records ("vinyl"), cassette tape may also become more prominent again: https://www.wsj.com/articles/cassettes-are-making-a-comeback-but-there-s-a-… I still use VCRs to record TV shows roughly once/week. I have an interesting collection of audio recordings on 1/4" tape that I made 20-40+ years ago as an active sound technician/musician. I'd given up on my old reel to reel machines, but a year ago my birthday present to myself was a reel to reel machine and Dolby units. I'm very slowly fetching stuff out of my archives and digitizing. I typically call it "recording" whether analog or digital... Charlie P.S. Having started out with 80 column cards, 72 columns of content, 8 of sequencing, continuing through most of graduate school, I typically restrict myself to 72 columns when programming.

On Wed, 8 Nov 2017, Steve Nickolas wrote: I still do... I even had a Betamax VCR at one time; damned hard trying to find tapes for it, but. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Wed, 8 Nov 2017, Ron Natalie wrote: Yeah; although technically inferior, VHS had about twice the recording time and hence won (mediocrity rules the market). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Wed, Nov 8, 2017 at 4:34 PM, Dan Cross <crossd(a)gmail.com> wrote: Another small point about this: consider that `diff` et al prepend special characters to the beginning of a line in their output. So if one wants to run e.g., `diff -u a.c b.c`, and the line-length limit in a source file is 80 characters, then won't one see a non-trivial amount of either wrap-around or truncation in diff output? This, again, begs the question of why not use a shorter line-length limit than the presumed maximum screen width? - Dan C.

On Wed, Nov 8, 2017 at 4:40 PM, Larry McVoy <lm(a)mcvoy.com> wrote: That's why I think this argument doesn't hold up well. If we're to consider those, then what about the ones that can't handle two 80-column windows at the font size required by the user? Touche. :-) - Dan C.

Dan Cross &lt;crossd(a)gmail.com&gt; wrote: |On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: |> On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote: |>> So, 80 column folks, would you find this |>> a(b, |>> c, |>> d) |>> |>> more readable than |>> a(b,c,d) Someone who is no longer on this list said to the same topic to me, in October: Wer zu schnell nach Rechts kommt, strukturiert zu wenig ;-) Who approaches the right too fast, does not structure enough More or less. In the context that i turned to space indentation when i started using C not C++. |> yeah, I do. I work on thinkpad x220 sized machines which are just \ |> big enough |> for two 80 column windows with a little left over. When I'm checking \ |> in code, |> reviewing code, debugging code, I frequently want to see two versions \ |> of the |> same file side by side. If you code wider than 80 columns it greatly \ |> reduces |> the speed at which you can figure out what happened. I missed the possibility in screen(1), now in tmux(1) i can use bind-key -T prefix < set-window-option force-width 80 bind-key -T prefix > set-window-option force-width 0 again. |The thing that sort of vexes me about these arguments is that the |number 80 is so arbitrary. If you can fit two 80 column windows |side-by-side, then surely you could do the same with two 78-, 72- or |even 64-column windows. So why not 64, 72 or 78 columns? Whatever you say, i only wanted to add that "Human attention" is only so far stretchable, and that readers likely cannot grasp line lengths of that size, especially if densely packed or the surrounding lines are of significantly different length. Some neurologist could surely correct me. With tab indentation, a function with one level of conditionals eats up 16 rows, so the more or less ideal line length of 64 (if i recall correctly Knuth advocated 66) is the result. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Wednesday, November 8, 2017, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: For me changing 80 columns and/or 8 character Tab is like trying to change the value of Pi. I consider those the holy rules you just don't change. But I am probably in minority group these days as I still use a lot of old school 80 columns VT terminals -- vt220 and vt320 are my personal favorites. --Andy

On Wed, Nov 8, 2017 at 4:15 PM, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: It killed 80 columns, but not 8 character hard tabs! Warner

On Wed, 8 Nov 2017, Arthur Krewat wrote: One employer used sw=4, so I got used to using ^T (and still do). The next employer insisted upon tab=4 and hard tabs, but I still insisted upon ta=8. Then, one day, I misread the indentation in a legacy C program with 8-tabs and some 4-tab mods, with disastrous results... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

At least it’s not python where the indenting makes a semantic difference. From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Don Hopkins Sent: Thursday, November 9, 2017 10:02 AM To: Lars Brinkhoff Cc: TUHS main list Subject: Re: [TUHS] 80 columns ... The theory was that fixed size FORTH blocks with 64 (or 40) columns forced you to factor your code into aesthetically pleasing little functions, but that was bullshit. Forth code needs stack comments on every line to be readable, and 40 columns makes that damn hard to do. (Here’s some dense under-commented RPN 6502 and Forth code I wrote for my 40-column Apple ][ Forth — this does RAM card bank switching and copying for saving and restoring lines of text for the SUPDUP line saving protocol %TDSAV %TDRES commands.) HEX CREATE SETUP-LINE ASSEMBLER BOT LDA, N STA, BOT 1+ LDA, N 1+ STA, BOT 2+ LDY, SCR-LBASES ,Y LDA, N 2+ STA, SCR-HBASES ,Y LDA, N 3 + STA, SCR-WIDTH 1- # LDY, RTS, CREATE RAMOFF ASSEMBLER 0C0D2 LDA, CLI, POPTWO JMP, CODE LINE! ( LINE ADDR --- ) SETUP-LINE JSR, BEGIN, N 2+ )Y LDA, N )Y STA, DEY, 0< UNTIL, RAMOFF JMP, C; CODE LINE@ ( LINE ADDR --- ) SETUP-LINE JSR, BEGIN, N )Y LDA, N 2+ )Y STA, DEY, 0< UNTIL, RAMOFF JMP, C; http://www.donhopkins.com/home/archive/forth/supdup.f Check out Toffoli and Margolus’s eccentric right-justified indentation style! (This is a cellular automata rule definition for their CAM6 hardware.) http://www.donhopkins.com/home/code/tomt-cam-forth-scr.txt http://www.donhopkins.com/home/code/tomt-users-forth-scr.txt ( GASHV: horizontal/vertical gas with collisions) 24 LOAD ( rotate right/left depending on time phase; do collisions) : RULE0 KC0 IF C0 ELSE T0 0= IF Y0 ELSE X0 THEN THEN ; ( echo) -Don On 9 Nov 2017, at 08:24, Lars Brinkhoff &lt;lars(a)nocrew.org&gt; wrote: ron minnich wrote: So, 80 column folks And then there's old-school Forth style, where lines are limited to 64 characters.

Nemo writes: I agree on Python but for a slightly different reason. In 1981 I wrote a user interface for the Tektronix microprocessor development systems. The executable plus all of the script data had to fit in memory on the PDP-11. This was an exercise in byte-counting to make everything fit because of the cost of overflowing a segment by a byte. Because of this I used indent level as part of the scripting language. Got beaten to a pulp by other folks in the group about it and had to waste a few precious bytes processing curly braces instead. So I'm too scarred to be able to use Python without cringing. Separate from this, I think that the whole 80 column thing is a bit silly. I have used 132 as by default for a long time now. Would go wider but just because I have always found it worthwhile spending money on the best monitors doesn't mean that everyone else can. Everything including my laptop is now a UHD monitor which rocks! I feel that longer lines work better than one-character variable names. And, longer lines are way more readable than wrapped lines. I have never been fond of the notion that code should be broken up into functions for the purpose of keeping lines short; I feel that code should be broken up into functions if it makes sense to do so, for example if the functions are used more than once. Writing for the limitations of the I/O device doesn't seem to be a good paradigm. In any case, I don't think that being an old UNIX person means that one has to live in the past. There was nothing magic about 80 columns; it was just the technology of the time. Technology has changed, so move on. Jon

I've made that point and people blithely ignore it.

On Fri, Nov 10, 2017 at 01:46:30PM -0700, Warner Losh wrote: I could live with 100.

Toby Thain writes: Well, I would claim that books have technological limitations that are different than computer monitors. It's a matter of doing what's appropriate instead of taking a dogmatic approach. I will point out that while it's sometimes a pain, the reader/writer ratio is a major driving force. I save on typing and use very terse code when writing stuff for myself. But, when writing stuff where there are many readers I feel that it's my job to put in the extra work to make it more accessible to the reader, partly because I don't want the readers bugging me. Jon

Larry McVoy writes: Well, as someone who also reads I don't really understand how your point relates to 80 columns. It sounds to me that you're making an argument for something else in which I strongly believe, which is that the block structure of the code should be clearly visible so that a reader doesn't have to read every line in order to understand what's going on. As an example, I abhor styles that say that continuations of long lines should be indented either an extra tab or right-aligned with the first line. Both of those styles break the visible block structure. Jon

Larry McVoy writes: Well, our physiology may be different. I've got a 132 column window open in front of me and I don't have to move my eyes side-to-side to read. I'm not seeing any of it via peripheral vision. Jon

William Corcoran writes: Well yes, having worked for a company that made terminals at the time, that is one of the reasons. The other is the availability of monitors that were cheap because they were compatible with televisions. Similar to the reason that we were stuck with crappy HD monitors for years. Jon

Dave Horsfall writes: At last, some honesty :-) Beats hand-wavy rationalizations for doing it the way that one likes. Having only a 32" monitor on my desk I can actually make the fonts smaller than I can read with my old eyes even though they're still crisp. Been considering getting a cheap 65" UHD TV as a monitor that I can hang on my wall. Would eliminate the problems with farsightedess. Would also free up a bunch of desk space. Jon

Dave Horsfall writes: If you like sdiff check out this: http://www.mcvoy.com/lm/difftool.png You have to install BitKeeper to get it but that's easy, go to bitkeeper.org and hit the download button. You don't have to use BK for source management, you can do bk difftool A B bk difftool file dir # dir means dir/file and you get the highlighting that makes sdiff jealous. --lm

On Sat, Nov 11, 2017 at 08:40:21AM -0800, Ian Zimmerman wrote: I do it like so if ((super_long_name_that_some_idiot_thought_was_smart > 1) && (super_long_name_that_some_idiot_thought_was_smarter > 2)) { something stupid here; } In my vi tab is a tab but shiftwidth is 4, and I map ^A to ^T (I think that came from the editor on CPM), and I set autoindent. So after the first line I hit return ^A (super.... return tab something... return ^D ^D } just to add to the arcaneness of this endless thread :)

These posts are nothing to do with Unix heritage and haven't been for a while. I've resisted the urge over and over to point out why most of you are wrong in various ways. :-) If I can resist, so can you. Lets have more signal, less noise. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Toby Thain writes: I'm not unfamiliar with the studies. Most are focus on speed of reading which is not necessarily the most important thing in code. Some studies have found that things that are easier to read are read less accurately which might be OK when reading a novel but is not necessarily optimal for code. Me, I try not to be dogmatic or to read what I want into studies. Well written long lines trump cryptic short lines for me. Your mileage may vary. Jon

Andy Kosela writes: Well, I think that you slightly misinterpreted my point. I learned a great thing from a manager in the mid-1980s. He told our group that it was perfectly OK to say "I want to do it this way because I like it." And, if there was no countervailing technical reason and if nobody else had a competing way that they liked it then you'd get your way. But, we'd never get our way or a raise for that matter if he had to wade through a pile of pseudo-technical hand-waving arguments that really were just about how you liked it. My objection was people saying that there were technical reasons for 80 columns when they were really saying that that was what they liked. So me, yes, I pine for the Glance G displays that I worked on at BTL. I have a certain Pavlovian response to green flashes from my days working on Tektronix storage tubes. But really, my 32" UHD monitor is the best looking thing that I've ever had. Obviously something that puts out 640x480 pixels is going to look bad without scaling, but that's OK. I don't play old video games on my modern computer. I have a pair of side-by-side 132x87 windows in an easy to see font that I use for most work with room for a bunch of small windows on the side. The majority use of my display is for typing code. I don't use graphical tools unless forced to by a client, especially in the springtime. I got a good classics education and the admonition "Beware the IDEs of March" has stuck with me :-) When I need to mess with graphics the display is awesome. Was editing some audio yesterday and being able to use audacity at full screen width made up for some of it's UI problems. So if you _prefer_ 80 columns, go for it. Just don't tell me that there are technical reasons why I should abide by your preference. Jon

Larry McVoy writes: They're not valid to me. As I read the studies, you're choosing speed over comprehension, I'm choosing the opposite. Jon

On Fri, 10 Nov 2017, Nemo wrote: The last language I used where indentation was part of the syntax was FORTRAN; although I have Python installed (some tools use it where I would use Perl), I will never use it. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."