[TUHS] 80 columns ...

[TUHS] 80 columns ...

[Norman Wilson]

Nemo:

  And for that reason, I have never used Python.  (I have a mental block
  about that.)

====

I used to feel the same way.  A few years ago I held my nose
and jumped in.  I'm glad I did; Python is a nifty little
language that, now I know it, hits a sweet spot twixt low-level
C and high-level shell and awk scripts.

Denoting blocks solely by indentation isn't at all bad once
you do it; no worse than adapting from do ... end to C's {}.

What still bugs me about Python:
-- It is unreasonably messy to give someone else a copy of
a program composed of many internal modules.  Apparently
you are expected to give her a handful of files, to be
installed in some directory whose name must be added to
the search path in every Python source file that imports
them.  I have come up with my own hacky workaround but it
would be nice if the language provided a graceful way to,
e.g., catenate multiple modules into a single source file
for distribution.
-- I miss C's style of for loop, though not often.  (Not
quite everything can be turned into a list or an iterator.)
-- I miss one particular case of assigment having a value:
that of
	while ((val = function()) != STOP)
		do something with val
Again, there are clunky ways to work around this.

As for 80 columns, I'm firmly in the camp that says that
if you need a lot of indentation you're doing it wrong.
Usually it means you should be pulling the details out
into separate functions.  Functions that run on for many,
many lines (once upon a time it was meaningful to say
for many pages, but no longer) are just as bad, for the
same reason: it's hard to read and understand the code,
because you have to keep so many details in your head at
once.

Likewise for excessive use of global variables, for that
matter, a flaw that is still quite common in C code.

Having to break an expression or a function call over
multiple lines is more problematic.  It's clearer not
to have to do that.  It helps not to make function or
variable names longer than necessary, but one can carry
that too far too.

Style and clarity are hard, but they are what distinguishes
a crap hack programmer from a good one.

Norman Wilson
Toronto ON
(Sitting on the lower level of a train in Texas,
not on a pedestal)

[TUHS] 80 columns ...

[Larry McVoy]

On Fri, Nov 10, 2017 at 01:21:09PM -0400, Norman Wilson wrote:
> Style and clarity are hard, but they are what distinguishes
> a crap hack programmer from a good one.

Yep.  My version of this is "optimize for the readers, there are many
of them and one of you".

[TUHS] 80 columns ...

[Ian Zimmerman]

On 2017-11-10 13:21, Norman Wilson wrote:

> -- It is unreasonably messy to give someone else a copy of a program
> composed of many internal modules.  Apparently you are expected to
> give her a handful of files, to be installed in some directory whose
> name must be added to the search path in every Python source file that
> imports them.  I have come up with my own hacky workaround but it
> would be nice if the language provided a graceful way to, e.g.,
> catenate multiple modules into a single source file for distribution.

Aren't to supposed to make an "egg", or something?

Even before those, you could make a package, "sdist" it, and have the
recipients run "python setup.py install".  Still simpler process than
installing many C libraries from source ...

> -- I miss one particular case of assigment having a value:
> that of
> 	while ((val = function()) != STOP)
> 		do something with val

I was once in a remote job interview with a Ruby shop.  I don't know
Ruby, but they said I could use Python.  Of course this situation came
up (it's pretty common when you think about it) and on this occasion a
whim made me write it thus:

while True:
    val = function()
    if val == STOP:
        break
    do_something()

Their reply was overflowing with shock and horror that I would use
"while True", and that was the end of that opportunity for me.
Apparently Ruby has a construct to handle this cleanly, without having
to call function() from two sites.

> Toronto ON
> (Sitting on the lower level of a train in Texas, not on a pedestal)

What's a Torontonian doing in Texas?  Are you researching the sequel to
"Tideland" ? :-)

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

[TUHS] 80 columns ...

[Random832]

On Sat, Nov 11, 2017, at 12:04, Ian Zimmerman wrote:
> On 2017-11-10 13:21, Norman Wilson wrote:
> > -- I miss one particular case of assigment having a value:
> > that of
> > 	while ((val = function()) != STOP)
> > 		do something with val
> 
> I was once in a remote job interview with a Ruby shop.  I don't know
> Ruby, but they said I could use Python.  Of course this situation came
> up (it's pretty common when you think about it) and on this occasion a
> whim made me write it thus:
> 
> while True:
>     val = function()
>     if val == STOP:
>         break
>     do_something()
> 
> Their reply was overflowing with shock and horror that I would use
> "while True", and that was the end of that opportunity for me.
> Apparently Ruby has a construct to handle this cleanly, without having
> to call function() from two sites.

Python has one as well, though it's a bit obscure - ISTR around half of
the people who commented on a thread on the python mailing lists where
this came up weren't familiar with it.

for val in iter(function, STOP):
    do_something()

If the function needs arguments, you have to use a lambda. If the
condition is something other than equality to some value... well, you
can hack something together, but it's debatably cleaner than the while
True loop.

(If the function is readline, though, you can just iterate over the file
object)

[TUHS] 80 columns ...

[Ian Zimmerman]

On 2017-11-11 12:30, Random832 wrote:

> for val in iter(function, STOP):
>     do_something()

A neat trick, thanks.

> (If the function is readline, though, you can just iterate over the
> file object)

This doesn't work if the file object can be a tty (such as stdin), IIRC
due to stdio buffering effects.

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

[TUHS] 80 columns ...

[Ralph Corderoy]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Larry McVoy]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Larry McVoy]

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

[TUHS] 80 columns ...

[Ian Zimmerman]

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.

[TUHS] 80 columns ...

[Andy Kosela]

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>

[TUHS] 80 columns ...

[David Arnold]

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

[TUHS] 80 columns ...

[Larry McVoy]

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

[TUHS] 80 columns ...

[Don Hopkins]

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

[TUHS] 80 columns ...

[Toby Thain]

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
> 

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Dave Horsfall]

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

[TUHS] 80 columns ...

[Toby Thain]

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
> 

[TUHS] 80 columns ...

[Dave Horsfall]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[William Corcoran]

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>

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Larry McVoy]

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.

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Larry McVoy]

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.

[TUHS] 80 columns ...

[Larry McVoy]

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.

[TUHS] 80 columns ...

[Warner Losh]

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>

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Larry McVoy]

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

[TUHS] 80 columns ...

[Toby Thain]

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

[TUHS] 80 columns ...

[Jon Steinhart]

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

[TUHS] 80 columns ...

[Nemo]

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

[TUHS] 80 columns ...

[Lars Brinkhoff]

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!

[TUHS] 80 columns ...

[Ron Natalie]

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

[TUHS] 80 columns ...

[Don Hopkins]

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

[TUHS] 80 columns ...

[Lars Brinkhoff]

ron minnich wrote:
> So, 80 column folks

And then there's old-school Forth style, where lines are limited to 64
characters.

[TUHS] 80 columns ...

[Otto Moerbeek]

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

[TUHS] 80 columns ...

[Theodore Ts'o]

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

[TUHS] 80 columns ...

[Dave Horsfall]

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

[TUHS] 80 columns ...

[Arthur Krewat]

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

[TUHS] 80 columns ...

[Steffen Nurpmeso]

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)

[TUHS] 80 columns ...

[Dave Horsfall]

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

[TUHS] 80 columns ...

[Ron Natalie]

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

[TUHS] 80 columns ...

[Dave Horsfall]

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

[TUHS] 80 columns ...

[Andy Kosela]

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>

[TUHS] 80 columns ...

[Warner Losh]

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>

[TUHS] 80 columns ...

[Arthur Krewat]

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

[TUHS] 80 columns ...

[Andy Kosela]

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>

[TUHS] 80 columns ...

[Arthur Krewat]

[-- 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 ;)

[TUHS] 80 columns ...

[Grant Taylor]

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>

[TUHS] 80 columns ...

[Dan Cross]

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.

[TUHS] 80 columns ...

[Larry McVoy]

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!

[TUHS] 80 columns ...

[Dan Cross]

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.

[TUHS] 80 columns ...

[Dan Cross]

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.

[TUHS] 80 columns ...

[Steve Nickolas]

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.

[TUHS] 80 columns ...

[Larry McVoy]

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.

[TUHS] 80 columns ...

[Dan Cross]

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.

[TUHS] 80 columns ...

[Steve Nickolas]

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.

[TUHS] 80 columns ...

[Bakul Shah]

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

[TUHS] 80 columns ...

[Larry McVoy]

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

[TUHS] 80 columns ...

[ron minnich]

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>