* [TUHS] 80 columns ... @ 2017-11-08 20:52 ron minnich 2017-11-08 21:02 ` Larry McVoy ` (3 more replies) 0 siblings, 4 replies; 61+ messages in thread From: ron minnich @ 2017-11-08 20:52 UTC (permalink / raw) So, 80 column folks, would you find this a(b, c, d) more readable than a(b,c,d) (this is a real example, with slightly shortened names) would you have code review software that automatically bounces out lines that are 82 columns wide? How far does this go? I do recall 80 column monitors, but I started on 132 column decwriter IIs and hence have never had sympathy for 80 columns. It's weird that so many punched-card standards are required in our code bases now (see: Linux). moving away from serious ... (look for Presottos' I feel so liberated ...) http://comp.os.plan9.narkive.com/4W8iThHW/9fans-acme-fonts -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/ffcf954a/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 20:52 [TUHS] 80 columns ron minnich @ 2017-11-08 21:02 ` Larry McVoy 2017-11-08 21:19 ` Dan Cross 2017-11-08 21:06 ` Bakul Shah ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-08 21:02 UTC (permalink / raw) 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) 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. So the question isn't what you said above, it's do you want to have to reach for the horizontal scrollbar constantly? Maybe you do, I don't. And you could say "get a higher res screen" which I'm doing, my 1920x1600 carbon x1 is on the way. But (a) I still have lots of x220, x230 screens that are useful (b) I can't see a font smaller than what I'm using, the x1 will be 2 80 column windows next to each other. All of this boils down to "do you optimize for the reader or optimize for the writer". Ron wants writer, I want reader. Write once, read many. --lm ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:02 ` Larry McVoy @ 2017-11-08 21:19 ` Dan Cross 2017-11-08 21:24 ` Larry McVoy 2017-11-08 23:46 ` Steffen Nurpmeso 0 siblings, 2 replies; 61+ messages in thread From: Dan Cross @ 2017-11-08 21:19 UTC (permalink / raw) On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> 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) > > 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. 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? Being tethered to a 1960s hardware standard has always struck me as odd and the justifications have an "after-the-fact" quality to them. Sure, 80-columns seems to be approaching some cognitive optimum, but when I see things like deliberate misspellings or grammar errors to keep a comment under the 80-column maximum, I feel like something's wrong. My own feeling is that programmers should be given some latitude to make the correct decision in this domain, and that individual excesses should be addressed in the code review process. That said, I once worked in a code base (in Common Lisp, no less!) where the standard was 100 columns, but this was frequently exceeded (I think I measured that, out of a half-million or so lines of CL, something like 10% were longer than 100 characters). > So the question isn't what you said above, it's do you want to have to > reach for the horizontal scrollbar constantly? Maybe you do, I don't. I think this is the wrong question: why would it be constantly? Even in code-bases with longer code limits, I claim that the vast majority of lines should be far less than the limit. What's the median line length? 90% percentile? Etc. > And you could say "get a higher res screen" which I'm doing, my 1920x1600 > carbon x1 is on the way. But > > (a) I still have lots of x220, x230 screens that are useful > (b) I can't see a font smaller than what I'm using, the x1 > will be 2 80 column windows next to each other. I'll bet that you could get two 82-column windows side-by-side. :-) Larry, I'll buy you a beer the next time I'm on the west coast if you can't. > All of this boils down to "do you optimize for the reader or optimize for > the writer". Ron wants writer, I want reader. Write once, read many. I'm not sure I would characterize it that way. I think we all want reader, but we just differ in how we want to get there. - Dan C. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:19 ` Dan Cross @ 2017-11-08 21:24 ` Larry McVoy 2017-11-08 21:28 ` Steve Nickolas 2017-11-08 21:34 ` Dan Cross 2017-11-08 23:46 ` Steffen Nurpmeso 1 sibling, 2 replies; 61+ messages in thread From: Larry McVoy @ 2017-11-08 21:24 UTC (permalink / raw) On Wed, Nov 08, 2017 at 04:19:49PM -0500, Dan Cross wrote: > On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> 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) > > > > 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. > > The thing that sort of vexes me about these arguments is that the > number 80 is so arbitrary. 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:24 ` Larry McVoy @ 2017-11-08 21:28 ` Steve Nickolas 2017-11-08 21:48 ` [TUHS] (cassette) tape coming back [was " Charles H Sauer 2017-11-08 23:28 ` [TUHS] " Dave Horsfall 2017-11-08 21:34 ` Dan Cross 1 sibling, 2 replies; 61+ messages in thread From: Steve Nickolas @ 2017-11-08 21:28 UTC (permalink / raw) On Wed, 8 Nov 2017, Larry McVoy wrote: > It's like video on phones. We still call it taping. Probably still will > in a 100 years. Where's the tape? In history. I thought I was the only one who still called it "taping" when recording to digital media. -uso. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] (cassette) tape coming back [was Re: 80 columns ... 2017-11-08 21:28 ` Steve Nickolas @ 2017-11-08 21:48 ` Charles H Sauer 2017-11-08 22:46 ` Don Hopkins 2017-11-08 23:28 ` [TUHS] " Dave Horsfall 1 sibling, 1 reply; 61+ messages in thread From: Charles H Sauer @ 2017-11-08 21:48 UTC (permalink / raw) On Wed, 8 Nov 2017, Larry McVoy wrote: > It's like video on phones. We still call it taping. Probably still will > in a 100 years. Where's the tape? In history. 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-kink-nobody-makes-tape-1509723435 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] (cassette) tape coming back [was Re: 80 columns ... 2017-11-08 21:48 ` [TUHS] (cassette) tape coming back [was " Charles H Sauer @ 2017-11-08 22:46 ` Don Hopkins 0 siblings, 0 replies; 61+ messages in thread From: Don Hopkins @ 2017-11-08 22:46 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1337 bytes --] Once I took a screen snapshot of my Apple ][ hires graphics with glow-in-the-dark silly putty! It didn’t last long, but it was cool while it lasted! Kinda like Kai Power Goo. -Don > On 8 Nov 2017, at 22:48, Charles H Sauer <sauer at technologists.com> wrote: > > On Wed, 8 Nov 2017, Larry McVoy wrote: > >> It's like video on phones. We still call it taping. Probably still will >> in a 100 years. Where's the tape? In history. > > 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-kink-nobody-makes-tape-1509723435 > > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:28 ` Steve Nickolas 2017-11-08 21:48 ` [TUHS] (cassette) tape coming back [was " Charles H Sauer @ 2017-11-08 23:28 ` Dave Horsfall 2017-11-08 23:35 ` Ron Natalie 1 sibling, 1 reply; 61+ messages in thread From: Dave Horsfall @ 2017-11-08 23:28 UTC (permalink / raw) On Wed, 8 Nov 2017, Steve Nickolas wrote: > I thought I was the only one who still called it "taping" when recording > to digital media. 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." ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:28 ` [TUHS] " Dave Horsfall @ 2017-11-08 23:35 ` Ron Natalie 2017-11-08 23:39 ` Dave Horsfall 0 siblings, 1 reply; 61+ messages in thread From: Ron Natalie @ 2017-11-08 23:35 UTC (permalink / raw) > I still do... I even had a Betamax VCR at one time; damned hard trying to find tapes for it, but. Ah yes, the slightly less popular beta format. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:35 ` Ron Natalie @ 2017-11-08 23:39 ` Dave Horsfall 0 siblings, 0 replies; 61+ messages in thread From: Dave Horsfall @ 2017-11-08 23:39 UTC (permalink / raw) On Wed, 8 Nov 2017, Ron Natalie wrote: >> I still do... I even had a Betamax VCR at one time; damned hard trying >> to find tapes for it, but. > > Ah yes, the slightly less popular beta format. 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." ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:24 ` Larry McVoy 2017-11-08 21:28 ` Steve Nickolas @ 2017-11-08 21:34 ` Dan Cross 2017-11-08 21:40 ` Dan Cross 2017-11-08 21:40 ` Larry McVoy 1 sibling, 2 replies; 61+ messages in thread From: Dan Cross @ 2017-11-08 21:34 UTC (permalink / raw) On Wed, Nov 8, 2017 at 4:24 PM, Larry McVoy <lm at mcvoy.com> wrote: > On Wed, Nov 08, 2017 at 04:19:49PM -0500, Dan Cross wrote: >> On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> 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) >> > >> > 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. >> >> The thing that sort of vexes me about these arguments is that the >> number 80 is so arbitrary. > > 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. Lots of them can also handle two 100 column windows, or perhaps more realistically 82- or 85-column windows, but here's the thing that I don't buy about that argument: if given a large enough screen, proponents would claim that they needed 3 side-by-side windows instead of two. As a simple test, I can put two 100x75 windows side-by-side on my desktop here at work, using a font size big enough for my deteriorating eyesight. I can fit three 80x75 windows next to one another, but I can fit *4* 60-column windows next to each other. > And I made the point about side by side diff tools. But what about 3-way merge 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. Language is a funny thing. Well, I better get back in the saddle and write some code. - Dan C. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:34 ` Dan Cross @ 2017-11-08 21:40 ` Dan Cross 2017-11-08 21:40 ` Larry McVoy 1 sibling, 0 replies; 61+ messages in thread From: Dan Cross @ 2017-11-08 21:40 UTC (permalink / raw) On Wed, Nov 8, 2017 at 4:34 PM, Dan Cross <crossd at gmail.com> wrote: > On Wed, Nov 8, 2017 at 4:24 PM, Larry McVoy <lm at mcvoy.com> wrote: >>[..] >> And I made the point about side by side diff tools. > > But what about 3-way merge tools? 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:34 ` Dan Cross 2017-11-08 21:40 ` Dan Cross @ 2017-11-08 21:40 ` Larry McVoy 2017-11-08 21:43 ` Dan Cross 1 sibling, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-08 21:40 UTC (permalink / raw) On Wed, Nov 08, 2017 at 04:34:13PM -0500, Dan Cross wrote: > >> The thing that sort of vexes me about these arguments is that the > >> number 80 is so arbitrary. > > > > 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. > > Lots of them can also handle two 100 column windows, or perhaps more Sure, my laptop can. But what about the ones that can't? > > And I made the point about side by side diff tools. > > But what about 3-way merge tools? Dude, you're talking to the guy that invented distributed source management and has written what is likely the best 3 way merge tool on the planet (jk, it's good though). My 3 way merge [ left version ] [ right version ] [ left version ] [ right version ] [ left version ] [ right version ] [ left version ] [ right version ] [ left version ] [ right version ] [ left version ] [ right version ] [ merge ] [ help ] [ merge ] [ help ] [ merge ] [ help ] Works great! ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:40 ` Larry McVoy @ 2017-11-08 21:43 ` Dan Cross 2017-11-09 1:00 ` Theodore Ts'o 0 siblings, 1 reply; 61+ messages in thread From: Dan Cross @ 2017-11-08 21:43 UTC (permalink / raw) On Wed, Nov 8, 2017 at 4:40 PM, Larry McVoy <lm at mcvoy.com> wrote: > On Wed, Nov 08, 2017 at 04:34:13PM -0500, Dan Cross wrote: >> >> The thing that sort of vexes me about these arguments is that the >> >> number 80 is so arbitrary. >> > >> > 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. >> >> Lots of them can also handle two 100 column windows, or perhaps more > > Sure, my laptop can. But what about the ones that can't? 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? >> > And I made the point about side by side diff tools. >> >> But what about 3-way merge tools? > > Dude, you're talking to the guy that invented distributed source management > and has written what is likely the best 3 way merge tool on the planet (jk, > it's good though). My 3 way merge > > [ left version ] [ right version ] > [ left version ] [ right version ] > [ left version ] [ right version ] > [ left version ] [ right version ] > [ left version ] [ right version ] > [ left version ] [ right version ] > [ merge ] [ help ] > [ merge ] [ help ] > [ merge ] [ help ] > > Works great! Touche. :-) - Dan C. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:43 ` Dan Cross @ 2017-11-09 1:00 ` Theodore Ts'o 0 siblings, 0 replies; 61+ messages in thread From: Theodore Ts'o @ 2017-11-09 1:00 UTC (permalink / raw) On Wed, Nov 08, 2017 at 04:43:05PM -0500, Dan Cross wrote: > > Sure, my laptop can. But what about the ones that can't? > > 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? At the end of the day we have to pick *something*. Since those of us older farts with the older eyes tend to have more say, thankfully its stayed at 80 columns as opposed to people who can say "I have *no* trouble with terminals at 6 point font, what's your problem?" Sure it's arbitrary, but it's arbitrary the same way that if you want to make sure a car or an RV is legal in all states in the US, it had better not be more than 96 inches (8 feet). Most states will allow 102 inches (8.5 feet); but funny thing --- car manufacturers hate having multiple SKU's for different states. Heck, for that matter, chosing 8 bits for a byte and making words be mulitples of 8 bits was arbitrary. I'm sure the designer of 18-bit and 36-bit machines thought so, anyway.... - Ted ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:19 ` Dan Cross 2017-11-08 21:24 ` Larry McVoy @ 2017-11-08 23:46 ` Steffen Nurpmeso 2017-11-09 6:52 ` Otto Moerbeek 1 sibling, 1 reply; 61+ messages in thread From: Steffen Nurpmeso @ 2017-11-08 23:46 UTC (permalink / raw) Dan Cross <crossd at gmail.com> wrote: |On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:46 ` Steffen Nurpmeso @ 2017-11-09 6:52 ` Otto Moerbeek 0 siblings, 0 replies; 61+ messages in thread From: Otto Moerbeek @ 2017-11-09 6:52 UTC (permalink / raw) On Thu, Nov 09, 2017 at 12:46:52AM +0100, Steffen Nurpmeso wrote: > Dan Cross <crossd at gmail.com> wrote: > |On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> 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 > Can related to that very much, I take it as a hint that my nesting gets too deep when I'm hitting the right margin. -Otto ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 20:52 [TUHS] 80 columns ron minnich 2017-11-08 21:02 ` Larry McVoy @ 2017-11-08 21:06 ` Bakul Shah 2017-11-08 21:18 ` Steve Nickolas 2017-11-08 22:17 ` Grant Taylor 2017-11-09 7:24 ` Lars Brinkhoff 3 siblings, 1 reply; 61+ messages in thread From: Bakul Shah @ 2017-11-08 21:06 UTC (permalink / raw) On Wed, 08 Nov 2017 20:52:03 +0000 ron minnich <rminnich at gmail.com> wrote: ron minnich writes: > > So, 80 column folks, would you find this > a(b, > c, > d) > > more readable than > a(b,c,d) That's still only 7 chars! > (this is a real example, with slightly shortened names) It is this spellingThingsOutInExcruciatingDetail that I find hard to read. Whether you use 80 columns or 800. Why not think a bit harder and come up with shorter name? Fix that and you don't need wide columns. Not to mention longer words are easier to misspell (which then brings in an all singling all dancing IDE...) > would you have code review software that automatically bounces out lines > that are 82 columns wide? How far does this go? > > I do recall 80 column monitors, but I started on 132 column decwriter IIs > and hence have never had sympathy for 80 columns. It's weird that so many > punched-card standards are required in our code bases now (see: Linux). Shorter lines are just faster to read. Which is why (printed) newspapers have multiple columns. > moving away from serious ... (look for Presottos' I feel so liberated ...) > > http://comp.os.plan9.narkive.com/4W8iThHW/9fans-acme-fonts Funny. To adjust column width in acme I use monospace font and a file called "ruler" (reproduced below): 1 2 3 4 5 6 7 01234567890123456789012345678901234567890123456789012345678901234567890123456789 | | | | | | | | | ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 21:06 ` Bakul Shah @ 2017-11-08 21:18 ` Steve Nickolas 0 siblings, 0 replies; 61+ messages in thread From: Steve Nickolas @ 2017-11-08 21:18 UTC (permalink / raw) On Wed, 8 Nov 2017, Bakul Shah wrote: > It is this spellingThingsOutInExcruciatingDetail that I find > hard to read. Whether you use 80 columns or 800. Why not > think a bit harder and come up with shorter name? Fix that > and you don't need wide columns. This is how I operate too - I use a lot of abbreviations (one particularly hairy program I have has "havesnddrv", "iielc", "dblgrx" (have sound driver, IIe language card, double resolution graphics respectively)). Of course anyone familiar with the domain of what the program is doing (it's an Apple ][ emulator) will probably understand the terminology. -uso. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 20:52 [TUHS] 80 columns ron minnich 2017-11-08 21:02 ` Larry McVoy 2017-11-08 21:06 ` Bakul Shah @ 2017-11-08 22:17 ` Grant Taylor 2017-11-08 22:30 ` Arthur Krewat 2017-11-09 7:24 ` Lars Brinkhoff 3 siblings, 1 reply; 61+ messages in thread From: Grant Taylor @ 2017-11-08 22:17 UTC (permalink / raw) On 11/08/2017 01:52 PM, ron minnich wrote: > So, 80 column folks, I don't consider myself to be an 80 column person. - I default my XTerm windows to 132 x 50. (Rows matter less.) > would you find this > a(b, > c, > d) > > more readable than > a(b,c,d) I don't know if it plays into preferences or not, but I do find that having things on one line makes it significantly easier to programmability modify the line with a Regular Expression. Maybe I need to learn some more about RE's to make working across lines easier. > would you have code review software that automatically bounces out lines > that are 82 columns wide? How far does this go? My $EMPLOYER does have CR processes that complain about lines longer than 80 characters. > I do recall 80 column monitors, but I started on 132 column decwriter > IIs and hence have never had sympathy for 80 columns. It's weird that so Interesting. I wonder if that's where the 132 column (alternative) standard came from. I.e. XTerm's "Allow 80/132 Column Switching" option in the VT Options menu. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/d3475e89/attachment-0001.bin> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 22:17 ` Grant Taylor @ 2017-11-08 22:30 ` Arthur Krewat 2017-11-08 23:07 ` Andy Kosela 0 siblings, 1 reply; 61+ messages in thread From: Arthur Krewat @ 2017-11-08 22:30 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 920 bytes --] I too grew up on DecWriters writing MACRO-10 on TOPS-10 in high school. My favorite was the LA120 that I could change the character pitch and get 132 columns on 8.5" paper when we ran out of the wide stuff. To this day, 80 columns just doesn't do it for me. I generally comment - a LOT - and in C the comments will stretch out past 80 columns easily. On 11/8/2017 5:17 PM, Grant Taylor via TUHS wrote: > >> I do recall 80 column monitors, but I started on 132 column decwriter >> IIs and hence have never had sympathy for 80 columns. It's weird that so > > Interesting. I wonder if that's where the 132 column (alternative) > standard came from. I.e. XTerm's "Allow 80/132 Column Switching" > option in the VT Options menu. VT100's had a 132 column mode. I wrote a terminal emulator for the IBM-XT circa 1985 to do 132 columns in it's highest-resolution. I couldn't take 80 columns, even back then ;) ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 22:30 ` Arthur Krewat @ 2017-11-08 23:07 ` Andy Kosela 2017-11-08 23:15 ` Arthur Krewat 0 siblings, 1 reply; 61+ messages in thread From: Andy Kosela @ 2017-11-08 23:07 UTC (permalink / raw) On Wednesday, November 8, 2017, Arthur Krewat <krewat at kilonet.net> wrote: > I too grew up on DecWriters writing MACRO-10 on TOPS-10 in high school. My > favorite was the LA120 that I could change the character pitch and get 132 > columns on 8.5" paper when we ran out of the wide stuff. > > To this day, 80 columns just doesn't do it for me. I generally comment - a > LOT - and in C the comments will stretch out past 80 columns easily. > > On 11/8/2017 5:17 PM, Grant Taylor via TUHS wrote: > >> >> I do recall 80 column monitors, but I started on 132 column decwriter IIs >>> and hence have never had sympathy for 80 columns. It's weird that so >>> >> >> Interesting. I wonder if that's where the 132 column (alternative) >> standard came from. I.e. XTerm's "Allow 80/132 Column Switching" option in >> the VT Options menu. >> > > VT100's had a 132 column mode. I wrote a terminal emulator for the IBM-XT > circa 1985 to do 132 columns in it's highest-resolution. I couldn't take 80 > columns, even back then ;) > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/a764771c/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:07 ` Andy Kosela @ 2017-11-08 23:15 ` Arthur Krewat 2017-11-08 23:15 ` Warner Losh 2017-11-08 23:24 ` Andy Kosela 0 siblings, 2 replies; 61+ messages in thread From: Arthur Krewat @ 2017-11-08 23:15 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 423 bytes --] On 11/8/2017 6:07 PM, Andy Kosela 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. > xterms killed that requirement for me a long time ago. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:15 ` Arthur Krewat @ 2017-11-08 23:15 ` Warner Losh 2017-11-08 23:49 ` Arthur Krewat 2017-11-08 23:24 ` Andy Kosela 1 sibling, 1 reply; 61+ messages in thread From: Warner Losh @ 2017-11-08 23:15 UTC (permalink / raw) On Wed, Nov 8, 2017 at 4:15 PM, Arthur Krewat <krewat at kilonet.net> wrote: > > > On 11/8/2017 6:07 PM, Andy Kosela 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. >> >> > xterms killed that requirement for me a long time ago. > It killed 80 columns, but not 8 character hard tabs! Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/dfa3be8c/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:15 ` Warner Losh @ 2017-11-08 23:49 ` Arthur Krewat 2017-11-09 0:04 ` Dave Horsfall 0 siblings, 1 reply; 61+ messages in thread From: Arthur Krewat @ 2017-11-08 23:49 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1410 bytes --] On 11/8/2017 6:15 PM, Warner Losh wrote: > > xterms killed that requirement for me a long time ago. > > > It killed 80 columns, but not 8 character hard tabs! > Whoever came up with 4 column tabs should be shot. ;) On 11/8/2017 6:24 PM, Andy Kosela wrote: > > > On Thursday, November 9, 2017, Arthur Krewat <krewat at kilonet.net > <mailto:krewat at kilonet.net>> wrote: > > > xterms killed that requirement for me a long time ago. > > > I still use 80 columns on my xterms. Like Larry said, most things in > Unix still looks perfect on 80 columns display, plus it's easier to > read -- less eye movements from left to right. If you think about it, > regular books have a similar format. It has been > scientifically proven that very long lines are just harder and > slower to read. > Besides programming, system administration and other tasks these days sometimes requires a few more columns than 80: http://pdp10.kilonet.org/images/xterm.jpg And that's just one example. I forgot to mention my using xterms past 80 columns wasn't so much about writing code (although, I do regularly go past 80 columns) but general UNIX stuff too. -- BTW, no disrespect to anyone here, whatever floats your boat ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/f2f96d4b/attachment-0001.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:49 ` Arthur Krewat @ 2017-11-09 0:04 ` Dave Horsfall 0 siblings, 0 replies; 61+ messages in thread From: Dave Horsfall @ 2017-11-09 0:04 UTC (permalink / raw) On Wed, 8 Nov 2017, Arthur Krewat wrote: > It killed 80 columns, but not 8 character hard tabs! > > Whoever came up with 4 column tabs should be shot. ;) 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." ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 23:15 ` Arthur Krewat 2017-11-08 23:15 ` Warner Losh @ 2017-11-08 23:24 ` Andy Kosela 1 sibling, 0 replies; 61+ messages in thread From: Andy Kosela @ 2017-11-08 23:24 UTC (permalink / raw) On Thursday, November 9, 2017, Arthur Krewat <krewat at kilonet.net> wrote: > > > On 11/8/2017 6:07 PM, Andy Kosela 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. >> >> > xterms killed that requirement for me a long time ago. > I still use 80 columns on my xterms. Like Larry said, most things in Unix still looks perfect on 80 columns display, plus it's easier to read -- less eye movements from left to right. If you think about it, regular books have a similar format. It has been scientifically proven that very long lines are just harder and slower to read. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/51dd3abd/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-08 20:52 [TUHS] 80 columns ron minnich ` (2 preceding siblings ...) 2017-11-08 22:17 ` Grant Taylor @ 2017-11-09 7:24 ` Lars Brinkhoff 2017-11-09 15:02 ` Don Hopkins 3 siblings, 1 reply; 61+ messages in thread From: Lars Brinkhoff @ 2017-11-09 7:24 UTC (permalink / raw) ron minnich wrote: > So, 80 column folks And then there's old-school Forth style, where lines are limited to 64 characters. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-09 7:24 ` Lars Brinkhoff @ 2017-11-09 15:02 ` Don Hopkins 2017-11-09 19:14 ` Ron Natalie 2017-11-09 20:46 ` Lars Brinkhoff 0 siblings, 2 replies; 61+ messages in thread From: Don Hopkins @ 2017-11-09 15:02 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2185 bytes --] 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 <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-cam-forth-scr.txt> http://www.donhopkins.com/home/code/tomt-users-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 <lars at nocrew.org> wrote: > > ron minnich wrote: >> So, 80 column folks > > And then there's old-school Forth style, where lines are limited to 64 > characters. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/d380c384/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-09 15:02 ` Don Hopkins @ 2017-11-09 19:14 ` Ron Natalie 2017-11-10 16:18 ` Nemo 2017-11-09 20:46 ` Lars Brinkhoff 1 sibling, 1 reply; 61+ messages in thread From: Ron Natalie @ 2017-11-09 19:14 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] 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 <lars at nocrew.org> wrote: ron minnich wrote: So, 80 column folks And then there's old-school Forth style, where lines are limited to 64 characters. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/8cdec2a8/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-09 19:14 ` Ron Natalie @ 2017-11-10 16:18 ` Nemo 2017-11-10 19:05 ` Jon Steinhart 2017-11-10 22:10 ` Dave Horsfall 0 siblings, 2 replies; 61+ messages in thread From: Nemo @ 2017-11-10 16:18 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 620 bytes --] On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote: > At least it’s not python where the indenting makes a semantic difference. And for that reason, I have never used Python. (I have a mental block about that.) As an 80-column aside, my alma mater allowed free runs in PL/C (remember that?) on card decks. I always numbered my cards in columns 73+ (and that save me from my clumsiness more than once). One day, they decided to read in all 80 columns. Easily fixed by programming a card-punch to add /* and */ but highly annoying. But using cards probably baked 80 columns into my head. N. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 16:18 ` Nemo @ 2017-11-10 19:05 ` Jon Steinhart 2017-11-10 20:36 ` Toby Thain 2017-11-10 23:59 ` Don Hopkins 2017-11-10 22:10 ` Dave Horsfall 1 sibling, 2 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 19:05 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1894 bytes --] Nemo writes: > On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote: > > At least it’s not python where the indenting makes a semantic difference. > > And for that reason, I have never used Python. (I have a mental block > about that.) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 19:05 ` Jon Steinhart @ 2017-11-10 20:36 ` Toby Thain 2017-11-10 20:39 ` Larry McVoy 2017-11-10 20:43 ` Jon Steinhart 2017-11-10 23:59 ` Don Hopkins 1 sibling, 2 replies; 61+ messages in thread From: Toby Thain @ 2017-11-10 20:36 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1688 bytes --] On 2017-11-10 2:05 PM, Jon Steinhart wrote: > Nemo writes: >> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote: >>> At least it’s not python where the indenting makes a semantic difference. >> >> And for that reason, I have never used Python. (I have a mental block >> about that.) > > ... > 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. Just don't move on without some limit. There are real cognitive/typographic reasons why excessively long lines hurt comprehension. This is why both 500 year old books and 5 month old books have narrow measures. 80 might be too narrow for most, but at some point beyond 132 is "too far". :) --Toby > > Jon > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:36 ` Toby Thain @ 2017-11-10 20:39 ` Larry McVoy 2017-11-10 20:46 ` Warner Losh 2017-11-10 20:43 ` Jon Steinhart 1 sibling, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-10 20:39 UTC (permalink / raw) > > 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. > > Just don't move on without some limit. There are real > cognitive/typographic reasons why excessively long lines hurt > comprehension. This is why both 500 year old books and 5 month old books > have narrow measures. I've made that point and people blithely ignore it. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:39 ` Larry McVoy @ 2017-11-10 20:46 ` Warner Losh 2017-11-10 20:59 ` Larry McVoy 2017-11-11 9:24 ` David Arnold 0 siblings, 2 replies; 61+ messages in thread From: Warner Losh @ 2017-11-10 20:46 UTC (permalink / raw) On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com> wrote: > > > 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. > > > > Just don't move on without some limit. There are real > > cognitive/typographic reasons why excessively long lines hurt > > comprehension. This is why both 500 year old books and 5 month old books > > have narrow measures. > > I've made that point and people blithely ignore it. > When I was debating style wars in the 90's, we adopted a 'wide is OK' approach, but with a soft limit of ~130 and a hard limit of 160 in exceptional cases. There was some research that showed that there's a limited field of view you want to be able to look at the code without moving your eyes side to side, just up and down. With the technology of the time, above about 130 would be hard to read 'at a glance'. Years later, I went looking for those studies, and couldn't find them and the original advocate of the view couldn't provide them. I'm the first to admit that 80 is too few. But 200 is definitely too wide and 100-120 seems to still be the sweet spot for my eyes and the range of hardware that I use. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/4b9c6cbf/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:46 ` Warner Losh @ 2017-11-10 20:59 ` Larry McVoy 2017-11-11 9:24 ` David Arnold 1 sibling, 0 replies; 61+ messages in thread From: Larry McVoy @ 2017-11-10 20:59 UTC (permalink / raw) On Fri, Nov 10, 2017 at 01:46:30PM -0700, Warner Losh wrote: > On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com> wrote: > > > > > 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. > > > > > > Just don't move on without some limit. There are real > > > cognitive/typographic reasons why excessively long lines hurt > > > comprehension. This is why both 500 year old books and 5 month old books > > > have narrow measures. > > > > I've made that point and people blithely ignore it. > > > > When I was debating style wars in the 90's, we adopted a 'wide is OK' > approach, but with a soft limit of ~130 and a hard limit of 160 in > exceptional cases. There was some research that showed that there's a > limited field of view you want to be able to look at the code without > moving your eyes side to side, just up and down. With the technology of the > time, above about 130 would be hard to read 'at a glance'. Years later, I > went looking for those studies, and couldn't find them and the original > advocate of the view couldn't provide them. > > I'm the first to admit that 80 is too few. But 200 is definitely too wide > and 100-120 seems to still be the sweet spot for my eyes and the range of > hardware that I use. I could live with 100. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:46 ` Warner Losh 2017-11-10 20:59 ` Larry McVoy @ 2017-11-11 9:24 ` David Arnold 1 sibling, 0 replies; 61+ messages in thread From: David Arnold @ 2017-11-11 9:24 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2771 bytes --] (apologies for prolonging this thread) For me, context is everything while programming. Header, code, the other code, man page, spec doc, etc. I usually manage that by getting as many “terminals” as I can on screen: 4 side-by-side xterms, 80 rows of 80 columns using 6x13 font on my 1920x1200 screen. The choice of 80 columns, as has been pointed out, is arbitrary (and historical), but I find it’s a reasonable compromise between clarity of the code (minimal line breaking) and maximising context (4 columns, rather than fewer). If you’re using 132 columns, you almost completely eliminate line-wrapping, but you’re also wasting a lot of visual real estate as the great majority of lines are less then half that long. That said, 80 columns doesn’t work for Java: C is fine, C++ mostly ok, Python is ok, but with Java, the naming culture is for incrediblyLongDescriptiveNamesForEveryThing, and even 132 columns can be too tight. To be honest though, it’s vertical space that I find more important: being able to see the entire function, or all the related header definitions, etc, without scrolling means far less cognitive overhead. Four lots of 80 rows is *so* much better than one lot of 24 as to be almost indescribably more productive. d > On 11 Nov 2017, at 07:46, Warner Losh <imp at bsdimp.com> wrote: > > > > On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote: > > > 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. > > > > Just don't move on without some limit. There are real > > cognitive/typographic reasons why excessively long lines hurt > > comprehension. This is why both 500 year old books and 5 month old books > > have narrow measures. > > I've made that point and people blithely ignore it. > > When I was debating style wars in the 90's, we adopted a 'wide is OK' approach, but with a soft limit of ~130 and a hard limit of 160 in exceptional cases. There was some research that showed that there's a limited field of view you want to be able to look at the code without moving your eyes side to side, just up and down. With the technology of the time, above about 130 would be hard to read 'at a glance'. Years later, I went looking for those studies, and couldn't find them and the original advocate of the view couldn't provide them. > > I'm the first to admit that 80 is too few. But 200 is definitely too wide and 100-120 seems to still be the sweet spot for my eyes and the range of hardware that I use. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/4c091ecf/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:36 ` Toby Thain 2017-11-10 20:39 ` Larry McVoy @ 2017-11-10 20:43 ` Jon Steinhart 2017-11-10 20:58 ` Larry McVoy 2017-11-10 22:46 ` Toby Thain 1 sibling, 2 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 20:43 UTC (permalink / raw) Toby Thain writes: > Just don't move on without some limit. There are real > cognitive/typographic reasons why excessively long lines hurt > comprehension. This is why both 500 year old books and 5 month old books > have narrow measures. > > 80 might be too narrow for most, but at some point beyond 132 is "too > far". :) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:43 ` Jon Steinhart @ 2017-11-10 20:58 ` Larry McVoy 2017-11-10 21:02 ` Jon Steinhart 2017-11-10 22:46 ` Toby Thain 1 sibling, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-10 20:58 UTC (permalink / raw) On Fri, Nov 10, 2017 at 12:43:36PM -0800, Jon Steinhart wrote: > Toby Thain writes: > > Just don't move on without some limit. There are real > > cognitive/typographic reasons why excessively long lines hurt > > comprehension. This is why both 500 year old books and 5 month old books > > have narrow measures. > > > > 80 might be too narrow for most, but at some point beyond 132 is "too > > far". :) > > 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. So for the Nth time, there are people who read, I'm one of them, by looking down the middle of the text and getting the rest through peripheral vision. I read easily 3-4x faster than a decently fast reader and I get enough info that I can find the place where I need to go read more closely later. I can't imagine I'm the only person who does this, I'm special but not that special :) So for me, wider is optimizing me out, not optimizing for me. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:58 ` Larry McVoy @ 2017-11-10 21:02 ` Jon Steinhart 2017-11-10 21:09 ` Larry McVoy 2017-11-11 16:40 ` Ian Zimmerman 0 siblings, 2 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 21:02 UTC (permalink / raw) Larry McVoy writes: > On Fri, Nov 10, 2017 at 12:43:36PM -0800, Jon Steinhart wrote: > > Toby Thain writes: > > > Just don't move on without some limit. There are real > > > cognitive/typographic reasons why excessively long lines hurt > > > comprehension. This is why both 500 year old books and 5 month old books > > > have narrow measures. > > > > > > 80 might be too narrow for most, but at some point beyond 132 is "too > > > far". :) > > > > 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. > > So for the Nth time, there are people who read, I'm one of them, > by looking down the middle of the text and getting the rest through > peripheral vision. I read easily 3-4x faster than a decently fast reader > and I get enough info that I can find the place where I need to go read > more closely later. > > I can't imagine I'm the only person who does this, I'm special but not > that special :) So for me, wider is optimizing me out, not optimizing > for me. 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:02 ` Jon Steinhart @ 2017-11-10 21:09 ` Larry McVoy 2017-11-10 21:12 ` Jon Steinhart 2017-11-11 16:40 ` Ian Zimmerman 1 sibling, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-10 21:09 UTC (permalink / raw) On Fri, Nov 10, 2017 at 01:02:55PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > So for the Nth time, there are people who read, I'm one of them, > > by looking down the middle of the text and getting the rest through > > peripheral vision. I read easily 3-4x faster than a decently fast reader > > and I get enough info that I can find the place where I need to go read > > more closely later. > > > > I can't imagine I'm the only person who does this, I'm special but not > > that special :) So for me, wider is optimizing me out, not optimizing > > for me. > > Well, as someone who also reads I don't really understand how your point > relates to 80 columns. I read books and code by look at the middle of the page or the middle of the terminal and scrolling my eyes downward. I don't look side to side. I literally read the middle of the text and I get the rest through peripheral vision. This is what Warner (I think) was saying about books. If you make them too wide you have to move your eyes back and forth and that is both slower and more tiring. 80-100 columns is fine, 132 is too wide, that forces people to move their head/eyes back and forth. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:09 ` Larry McVoy @ 2017-11-10 21:12 ` Jon Steinhart 2017-11-10 21:34 ` William Corcoran 0 siblings, 1 reply; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 21:12 UTC (permalink / raw) Larry McVoy writes: > I read books and code by look at the middle of the page or the middle of > the terminal and scrolling my eyes downward. I don't look side to side. > I literally read the middle of the text and I get the rest through > peripheral vision. > > This is what Warner (I think) was saying about books. If you make them > too wide you have to move your eyes back and forth and that is both > slower and more tiring. > > 80-100 columns is fine, 132 is too wide, that forces people to move > their head/eyes back and forth. 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:12 ` Jon Steinhart @ 2017-11-10 21:34 ` William Corcoran 2017-11-10 21:50 ` Jon Steinhart 2017-11-10 22:58 ` Dave Horsfall 0 siblings, 2 replies; 61+ messages in thread From: William Corcoran @ 2017-11-10 21:34 UTC (permalink / raw) It could also be that the 80 column display with 24 rows using 8 bit characters fit nicely within a 16k memory chip (or four (4) 4K chips). I wonder if that fact eventually helped OEM's settle in on the ubiquitous 80x24 terminal size? Truly, Bill Corcoran On Nov 10, 2017, at 4:12 PM, Jon Steinhart <jon at fourwinds.com<mailto:jon at fourwinds.com>> wrote: Larry McVoy writes: I read books and code by look at the middle of the page or the middle of the terminal and scrolling my eyes downward. I don't look side to side. I literally read the middle of the text and I get the rest through peripheral vision. This is what Warner (I think) was saying about books. If you make them too wide you have to move your eyes back and forth and that is both slower and more tiring. 80-100 columns is fine, 132 is too wide, that forces people to move their head/eyes back and forth. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/2a6ebb6c/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:34 ` William Corcoran @ 2017-11-10 21:50 ` Jon Steinhart 2017-11-10 22:58 ` Dave Horsfall 1 sibling, 0 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 21:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 557 bytes --] William Corcoran writes: > It could also be that the 80 column display with 24 rows using 8 bit characters > fit nicely within a 16k memory chip (or four (4) 4K chips). I wonder if that > fact eventually helped OEM’s settle in on the ubiquitous 80x24 terminal size? 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:34 ` William Corcoran 2017-11-10 21:50 ` Jon Steinhart @ 2017-11-10 22:58 ` Dave Horsfall 2017-11-10 23:05 ` Jon Steinhart 1 sibling, 1 reply; 61+ messages in thread From: Dave Horsfall @ 2017-11-10 22:58 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 931 bytes --] On Fri, 10 Nov 2017, William Corcoran wrote: > It could also be that the 80 column display with 24 rows using 8 bit > characters fit nicely within a 16k memory chip (or four (4) 4K chips). I > wonder if that fact eventually helped OEM’s settle in on the ubiquitous > 80x24 terminal size? Perhaps. I still have horrible memories of the VT-05, flogged as the console for the PDP-11. It was 72x20 (yes, really!), upper-case only (but flipping a switch caused it to transmit lower-case as well), lacked a few characters, etc... It probably used even smaller chips. And yes, I'm a crusty dinosaur who won't adapt to the modern times; my windows are 80x24, with the occasional 80x40, but occasionally using wide screens for side-by-side diffs ("sdiff" is a wonderful tool), etc. I also have poor eyesight, so I can't use small fonts. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 22:58 ` Dave Horsfall @ 2017-11-10 23:05 ` Jon Steinhart 2017-11-10 23:52 ` Toby Thain 2017-11-11 0:24 ` Larry McVoy 0 siblings, 2 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 23:05 UTC (permalink / raw) Dave Horsfall writes: > > And yes, I'm a crusty dinosaur who won't adapt to the modern times; my > windows are 80x24, with the occasional 80x40, but occasionally using wide > screens for side-by-side diffs ("sdiff" is a wonderful tool), etc. I also > have poor eyesight, so I can't use small fonts. 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 23:05 ` Jon Steinhart @ 2017-11-10 23:52 ` Toby Thain 2017-11-11 0:24 ` Larry McVoy 1 sibling, 0 replies; 61+ messages in thread From: Toby Thain @ 2017-11-10 23:52 UTC (permalink / raw) On 2017-11-10 6:05 PM, Jon Steinhart wrote: > Dave Horsfall writes: >> >> And yes, I'm a crusty dinosaur who won't adapt to the modern times; my >> windows are 80x24, with the occasional 80x40, but occasionally using wide >> screens for side-by-side diffs ("sdiff" is a wonderful tool), etc. I also >> have poor eyesight, so I can't use small fonts. > > At last, some honesty :-) Beats hand-wavy rationalizations for doing it the > way that one likes. I actually think people _should_ do what they are most comfortable doing; individuals certainly vary and their preferences even moreso. Adjusted of course for _team_ work. The more people who have to deal with the product, the more reason to respect the well studied functional typographic and cognitive norms. --T > > 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 > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 23:05 ` Jon Steinhart 2017-11-10 23:52 ` Toby Thain @ 2017-11-11 0:24 ` Larry McVoy 1 sibling, 0 replies; 61+ messages in thread From: Larry McVoy @ 2017-11-11 0:24 UTC (permalink / raw) Dave Horsfall writes: > > And yes, I'm a crusty dinosaur who won't adapt to the modern times; my > windows are 80x24, with the occasional 80x40, but occasionally using wide > screens for side-by-side diffs ("sdiff" is a wonderful tool), etc. I also > have poor eyesight, so I can't use small fonts. 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 21:02 ` Jon Steinhart 2017-11-10 21:09 ` Larry McVoy @ 2017-11-11 16:40 ` Ian Zimmerman 2017-11-11 16:47 ` Larry McVoy 1 sibling, 1 reply; 61+ messages in thread From: Ian Zimmerman @ 2017-11-11 16:40 UTC (permalink / raw) On 2017-11-10 13:02, Jon Steinhart wrote: > 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. Wait, so _how_ do you like continuations to be indented? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 16:40 ` Ian Zimmerman @ 2017-11-11 16:47 ` Larry McVoy 2017-11-11 17:23 ` Jon Steinhart 0 siblings, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-11 16:47 UTC (permalink / raw) On Sat, Nov 11, 2017 at 08:40:21AM -0800, Ian Zimmerman wrote: > On 2017-11-10 13:02, Jon Steinhart wrote: > > > 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. > > Wait, so _how_ do you like continuations to be indented? 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 :) ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 16:47 ` Larry McVoy @ 2017-11-11 17:23 ` Jon Steinhart 2017-11-11 17:38 ` Ralph Corderoy 0 siblings, 1 reply; 61+ messages in thread From: Jon Steinhart @ 2017-11-11 17:23 UTC (permalink / raw) Larry McVoy writes: > > Wait, so _how_ do you like continuations to be indented? > > 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; > } To me, and to be clear that this is a personal preference as opposed to something factual, I would do the above as: if ((super_long_name_that_some_idiot_thought_was_smart > 1) && (super_long_name_that_some_idiot_thought_was_smarter > 2)) { something really smart here; } The one space indent shows that it's a continuation, but doesn't fool my eye into thinking that it's a block like Larry's example. There are many times that I am scrolling through code very quickly looking for block structure, and I'm optimizing for that in my eyes. There's also another personal preference above, which is that I prefer if this AND that to if this AND that Jon ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 17:23 ` Jon Steinhart @ 2017-11-11 17:38 ` Ralph Corderoy 0 siblings, 0 replies; 61+ messages in thread From: Ralph Corderoy @ 2017-11-11 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 20:43 ` Jon Steinhart 2017-11-10 20:58 ` Larry McVoy @ 2017-11-10 22:46 ` Toby Thain 2017-11-10 22:59 ` Jon Steinhart 1 sibling, 1 reply; 61+ messages in thread From: Toby Thain @ 2017-11-10 22:46 UTC (permalink / raw) On 2017-11-10 3:43 PM, Jon Steinhart wrote: > Toby Thain writes: >> Just don't move on without some limit. There are real >> cognitive/typographic reasons why excessively long lines hurt >> comprehension. This is why both 500 year old books and 5 month old books >> have narrow measures. >> >> 80 might be too narrow for most, but at some point beyond 132 is "too >> far". :) > > 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. It's _reading_. Code doesn't magically escape typographic factors. The human visual/processing system is the constraint, it does not care whether you're reading paper or the more hostile LCD - and it has not changed materially in the millennia we've been doing writing (and certainly not the 500 years we've been doing books). There is also a body of modern research on this. Even research specifically focused on code, I believe. > > 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 > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 22:46 ` Toby Thain @ 2017-11-10 22:59 ` Jon Steinhart 2017-11-11 14:33 ` Andy Kosela 0 siblings, 1 reply; 61+ messages in thread From: Jon Steinhart @ 2017-11-10 22:59 UTC (permalink / raw) Toby Thain writes: > On 2017-11-10 3:43 PM, Jon Steinhart wrote: > > Toby Thain writes: > >> Just don't move on without some limit. There are real > >> cognitive/typographic reasons why excessively long lines hurt > >> comprehension. This is why both 500 year old books and 5 month old books > >> have narrow measures. > >> > >> 80 might be too narrow for most, but at some point beyond 132 is "too > >> far". :) > > > > 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. > > It's _reading_. Code doesn't magically escape typographic factors. The > human visual/processing system is the constraint, it does not care > whether you're reading paper or the more hostile LCD - and it has not > changed materially in the millennia we've been doing writing (and > certainly not the 500 years we've been doing books). There is also a > body of modern research on this. Even research specifically focused on > code, I believe. 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 22:59 ` Jon Steinhart @ 2017-11-11 14:33 ` Andy Kosela 2017-11-11 17:19 ` Jon Steinhart 0 siblings, 1 reply; 61+ messages in thread From: Andy Kosela @ 2017-11-11 14:33 UTC (permalink / raw) On Friday, November 10, 2017, Jon Steinhart <jon at fourwinds.com> wrote: > Toby Thain writes: > > On 2017-11-10 3:43 PM, Jon Steinhart wrote: > > > Toby Thain writes: > > >> Just don't move on without some limit. There are real > > >> cognitive/typographic reasons why excessively long lines hurt > > >> comprehension. This is why both 500 year old books and 5 month old > books > > >> have narrow measures. > > >> > > >> 80 might be too narrow for most, but at some point beyond 132 is "too > > >> far". :) > > > > > > 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. > > > > It's _reading_. Code doesn't magically escape typographic factors. The > > human visual/processing system is the constraint, it does not care > > whether you're reading paper or the more hostile LCD - and it has not > > changed materially in the millennia we've been doing writing (and > > certainly not the 500 years we've been doing books). There is also a > > body of modern research on this. Even research specifically focused on > > code, I believe. > > 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. > > I don't think it is about being dogmatic. Please believe there are still some people who just _prefer_ 80 columns. It could be because they were introduced to computing when this was a standard and they still treat it as a standard for text based computing, or they just find the aesthetics of this format much more pleasant to their eyes. For me there is something truly magical in the way 80 columns text look on a dark CRT display -- I also love the glow of green or amber phosphor and scanlines as visible clearly on vt220 for example. So even though I am also using xterms these days, my perfect UNIX computing platform is still definitely a full screen text console 80x24 using CRT terminal. HD widescreen LCD displays are nice...but for modern graphics and video at high resolutions. Try to display perfectly old Amiga or C64 graphics/games on a modern widescreen and you will know what I am talking about. You need an old CRT for that, in 4:3 format. The same is for displaying text -- I don't believe you need the next gen monitor to display UNIX text based console (technology essentially from the 70s). It actually looks worse on modern displays, which are optimized for HD _graphics_ and high native resolutions. If you think about it -- computing platforms and the Internet were text only in the 70s, 80s and a good part of the 90s, but since the rise of Windows 95 and the World Wide Web, the world has abandoned text and moved fully into the graphical world. But we also lost something -- full screen text mode will always remain beautiful from an aesthetics perspective and it is still the best stimulant of the imagination, just like books. Todays generations do not even know how to stay focused on reading text -- all they do is swipe their fingers on next colorful images on Instagram or Facebook... --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/e112fe55/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 14:33 ` Andy Kosela @ 2017-11-11 17:19 ` Jon Steinhart 2017-11-11 17:24 ` Larry McVoy 0 siblings, 1 reply; 61+ messages in thread From: Jon Steinhart @ 2017-11-11 17:19 UTC (permalink / raw) Andy Kosela writes: > > I don't think it is about being dogmatic. Please believe there are still > some people who just _prefer_ 80 columns. It could be because they were > introduced to computing when this was a standard and they still treat it as > a standard for text based computing, or they just find the aesthetics of > this format much more pleasant to their eyes. > > For me there is something truly magical in the way 80 columns text look on > a dark CRT display -- I also love the glow of green or amber phosphor and > scanlines as visible clearly on vt220 for example. So even though I am > also using xterms these days, my perfect UNIX computing platform is > still definitely a full screen text console 80x24 using CRT terminal. > > HD widescreen LCD displays are nice...but for modern graphics and video at > high resolutions. Try to display perfectly old Amiga or > C64 graphics/games on a modern widescreen and you will know what I am > talking about. You need an old CRT for that, in 4:3 format. > > The same is for displaying text -- I don't believe you need the next gen > monitor to display UNIX text based console (technology essentially from the > 70s). It actually looks worse on modern displays, which are optimized for > HD _graphics_ and high native resolutions. > > If you think about it -- computing platforms and the Internet were text > only in the 70s, 80s and a good part of the 90s, but since the rise of > Windows 95 and the World Wide Web, the world has abandoned text and moved > fully into the graphical world. But we also lost something -- full screen > text mode will always remain beautiful from an aesthetics perspective and > it is still the best stimulant of the imagination, just like books. > > Todays generations do not even know how to stay focused on reading text -- > all they do is swipe their fingers on next colorful images on Instagram or > Facebook... > > --Andy 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 17:19 ` Jon Steinhart @ 2017-11-11 17:24 ` Larry McVoy 2017-11-11 17:25 ` Jon Steinhart 0 siblings, 1 reply; 61+ messages in thread From: Larry McVoy @ 2017-11-11 17:24 UTC (permalink / raw) > 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. Feel free to keep ignoring the valid technical reason I have stated over and over. And other people have stated the same thing as well. With that, I'm out, this thread is going to /dev/null. Thank you procmail. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-11 17:24 ` Larry McVoy @ 2017-11-11 17:25 ` Jon Steinhart 0 siblings, 0 replies; 61+ messages in thread From: Jon Steinhart @ 2017-11-11 17:25 UTC (permalink / raw) Larry McVoy writes: > > 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. > > Feel free to keep ignoring the valid technical reason I have stated over > and over. And other people have stated the same thing as well. > > With that, I'm out, this thread is going to /dev/null. Thank you procmail. They're not valid to me. As I read the studies, you're choosing speed over comprehension, I'm choosing the opposite. Jon ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 19:05 ` Jon Steinhart 2017-11-10 20:36 ` Toby Thain @ 2017-11-10 23:59 ` Don Hopkins 1 sibling, 0 replies; 61+ messages in thread From: Don Hopkins @ 2017-11-10 23:59 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2771 bytes --] Who’s heard David Beazley tell his epic Python hacking saga? He’s a true hacker’s hacker, who wrote SWIG, and eats, breaths and shits Python in his sleep. David Beazley: Discovering Python - PyCon 2014 Speaker: David Beazley So, what happens when you lock a Python programmer in a secret vault containing 1.5 TBytes of C++ source code and no internet connection? Find out as I describe how I used Python as a secret weapon of "discovery" in an epic legal battle. https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 <https://www.youtube.com/watch?v=RZ4Sn-Y7AP8> -Don > On 10 Nov 2017, at 20:05, Jon Steinhart <jon at fourwinds.com> wrote: > > Nemo writes: >> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote: >>> At least it’s not python where the indenting makes a semantic difference. >> >> And for that reason, I have never used Python. (I have a mental block >> about that.) > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/456d680d/attachment.html> ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-10 16:18 ` Nemo 2017-11-10 19:05 ` Jon Steinhart @ 2017-11-10 22:10 ` Dave Horsfall 1 sibling, 0 replies; 61+ messages in thread From: Dave Horsfall @ 2017-11-10 22:10 UTC (permalink / raw) On Fri, 10 Nov 2017, Nemo wrote: > And for that reason, I have never used Python. (I have a mental block > about that.) 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." ^ permalink raw reply [flat|nested] 61+ messages in thread
* [TUHS] 80 columns ... 2017-11-09 15:02 ` Don Hopkins 2017-11-09 19:14 ` Ron Natalie @ 2017-11-09 20:46 ` Lars Brinkhoff 1 sibling, 0 replies; 61+ messages in thread From: Lars Brinkhoff @ 2017-11-09 20:46 UTC (permalink / raw) Don Hopkins wrote: > Forth code needs stack comments on every line to be readable, and 40 > columns makes that damn hard to do. I have never used shadow screens, but it sounds like they would help with this. > http://www.donhopkins.com/home/archive/forth/supdup.f I'm dazed, this packs so much obsolete technology it's totally awesome! ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2017-11-11 17:38 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-08 20:52 [TUHS] 80 columns ron minnich 2017-11-08 21:02 ` Larry McVoy 2017-11-08 21:19 ` Dan Cross 2017-11-08 21:24 ` Larry McVoy 2017-11-08 21:28 ` Steve Nickolas 2017-11-08 21:48 ` [TUHS] (cassette) tape coming back [was " Charles H Sauer 2017-11-08 22:46 ` Don Hopkins 2017-11-08 23:28 ` [TUHS] " Dave Horsfall 2017-11-08 23:35 ` Ron Natalie 2017-11-08 23:39 ` Dave Horsfall 2017-11-08 21:34 ` Dan Cross 2017-11-08 21:40 ` Dan Cross 2017-11-08 21:40 ` Larry McVoy 2017-11-08 21:43 ` Dan Cross 2017-11-09 1:00 ` Theodore Ts'o 2017-11-08 23:46 ` Steffen Nurpmeso 2017-11-09 6:52 ` Otto Moerbeek 2017-11-08 21:06 ` Bakul Shah 2017-11-08 21:18 ` Steve Nickolas 2017-11-08 22:17 ` Grant Taylor 2017-11-08 22:30 ` Arthur Krewat 2017-11-08 23:07 ` Andy Kosela 2017-11-08 23:15 ` Arthur Krewat 2017-11-08 23:15 ` Warner Losh 2017-11-08 23:49 ` Arthur Krewat 2017-11-09 0:04 ` Dave Horsfall 2017-11-08 23:24 ` Andy Kosela 2017-11-09 7:24 ` Lars Brinkhoff 2017-11-09 15:02 ` Don Hopkins 2017-11-09 19:14 ` Ron Natalie 2017-11-10 16:18 ` Nemo 2017-11-10 19:05 ` Jon Steinhart 2017-11-10 20:36 ` Toby Thain 2017-11-10 20:39 ` Larry McVoy 2017-11-10 20:46 ` Warner Losh 2017-11-10 20:59 ` Larry McVoy 2017-11-11 9:24 ` David Arnold 2017-11-10 20:43 ` Jon Steinhart 2017-11-10 20:58 ` Larry McVoy 2017-11-10 21:02 ` Jon Steinhart 2017-11-10 21:09 ` Larry McVoy 2017-11-10 21:12 ` Jon Steinhart 2017-11-10 21:34 ` William Corcoran 2017-11-10 21:50 ` Jon Steinhart 2017-11-10 22:58 ` Dave Horsfall 2017-11-10 23:05 ` Jon Steinhart 2017-11-10 23:52 ` Toby Thain 2017-11-11 0:24 ` Larry McVoy 2017-11-11 16:40 ` Ian Zimmerman 2017-11-11 16:47 ` Larry McVoy 2017-11-11 17:23 ` Jon Steinhart 2017-11-11 17:38 ` Ralph Corderoy 2017-11-10 22:46 ` Toby Thain 2017-11-10 22:59 ` Jon Steinhart 2017-11-11 14:33 ` Andy Kosela 2017-11-11 17:19 ` Jon Steinhart 2017-11-11 17:24 ` Larry McVoy 2017-11-11 17:25 ` Jon Steinhart 2017-11-10 23:59 ` Don Hopkins 2017-11-10 22:10 ` Dave Horsfall 2017-11-09 20:46 ` Lars Brinkhoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).