End the Hollerith Tyranny? (linelength.t)
Chip Salzenberg
t/distro/linelength.t. (And making them very well, I might add.) Given the
nature of Parrot code, I think a bit wider would be OK. Would anyone
currently hacking Parrot be significantly inconvenienced by having wider
lines?
BTW, this is NOT a style preference question. The only reason I'm bugging
the list with this question is to solicit stories of "80 columns are the max
supported by <tool/hardware you're using>". adTHANKSvance
--
Chip Salzenberg <ch...@pobox.com>
al...@alfarrabio.di.uminho.pt
Just to let you all know that:
1) normally I have more than 80 columns (phew)
2) linelength.t is configurable to, say, 100 columns :)
3) all C code is cutted right now. Missing some Perl source files, which
are hard because they have big strings and cutting them make the code
harder to read.
Cheers ;)
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
"Beware of bugs in the above code;
I have only proved it correct, not tried it."
--- Donald Knuth
Will Coleda
answers. Who is programming parrot on their *physical* VT100? =-).
The primary reason for an 80 column limit is developer convenience, I
think.
On the other hand, I think taking the preferences of the core
developers into account is a *good* thing, but I don't think any of
us will quit if you come back with a higher number. Except maybe
Jerry. =-)
I just ask that if the PDD is in error ("Do not exceed 79 columns"),
we get it updated after a decision is made.
Regards!
P.S.: Seems only fair that if we're sticking with C89, we stick with
1989 terminal sizes. =-)
--
Will "Coke" Coleda
wi...@coleda.com
Chip Salzenberg
> The way you phrase the question, you're not going to get any of these
> answers. Who is programming parrot on their *physical* VT100? =-).
> The primary reason for an 80 column limit is developer convenience, I
> think.
Well, that's fair. Many of us are old enough to have used such limited
hardware, but it's all surely been relegated to the trashheap by now. So:
Would anyone be inconvenienced by exceeding 80 columns regularly; and, how?
> I don't think any of us will quit if you come back with a higher
> number. Except maybe Jerry. =-)
He'll threaten to quit until I change the pdd and .t files and then he'll
start bugging people who write short lines.
> P.S.: Seems only fair that if we're sticking with C89, we stick with
> 1989 terminal sizes. =-)
Some selectivity is in order, or we'll have to target 1989 memory sizes,
disk capacities, and network bandwidth....
PS: Allison gets to specify the doc formatting, if she likes. Exceptions
are technically trivial. See the bottom of the pdds for how a given file
can override the default word wrap column.
--
Chip Salzenberg <ch...@pobox.com>
Aaron Sherman
> On Mon, Aug 21, 2006 at 10:48:59AM -0400, Will Coleda wrote:
> > The way you phrase the question, you're not going to get any of these
> > answers. Who is programming parrot on their *physical* VT100? =-).
> > The primary reason for an 80 column limit is developer convenience, I
> > think.
>
> Well, that's fair. Many of us are old enough to have used such limited
> hardware, but it's all surely been relegated to the trashheap by now. So:
> Would anyone be inconvenienced by exceeding 80 columns regularly; and, how?
I typically measure my screen real estate in discrete 80-col units. My
layout of terminals, editors (emacs, xemacs, vim and gvim mixed fairly
liberally for different purposes) and other applications is suited to
editing in 80-column units. When I have to re-size a window to larger
than that, it's a pain, but not a terribly hurtful one.
I like the Gnome Style document for reference here. They talk about
8-space tabs, but it's the same issue as 80-column text:
Using 8-space tabs for indentation provides a number of
benefits. It makes the code easier to read, since the
indentation is clearly marked. It also helps you keep your code
honest by forcing you to split functions into more modular and
well-defined chunks - if your indentation goes too far to the
right, then it means your function is designed badly and you
should split it to make it more modular or re-think it.
Just my $0.02.
> > P.S.: Seems only fair that if we're sticking with C89, we stick with
> > 1989 terminal sizes. =-)
>
> Some selectivity is in order, or we'll have to target 1989 memory sizes,
> disk capacities, and network bandwidth....
There are times that I use emacs, not because it's the right tool for
the job that *it* is doing, but because I have to use it over a lossy
line, and NOTHING that I've found squeezes quite so much out of
curses-like rendering over a slow line. Why? Because it was designed to
do multi-window editing over 1200-9600 bps modem lines without making
its users want to kill themselves.
There is something to be said for working well in low-resource
environments, especially when talking about a VM that might need to be
placed into the control circuitry of, say, an elevator control system.
Leopold Toetsch
> Well, that's fair. Many of us are old enough to have used such limited
> hardware, but it's all surely been relegated to the trashheap by now. So:
> Would anyone be inconvenienced by exceeding 80 columns regularly; and, how?
80, or 100, or 132 are all some arbitrary limits. But the latter is already
inconvenient on a 12" powermac with reasonable font size [1]. Due to the
rather verbose VTABLE macros, 80 looks a bit too limited (given the
impressive amount of needed code changes we got recently (ambs++ BTW)).
My preference: soft limit 80 - keep lines shorter, if it's easy
hard limit ~100 - you SHALL not exceed it
leo
[1] "reasonable" for the old eyes of folks that actually have punched
hollerith cards, when they were younger, like e.g. yours sincerly
Jerry Gay
> My preference: soft limit 80 - keep lines shorter, if it's easy
> hard limit ~100 - you SHALL not exceed it
>
there are good reasons why a line of code might exceed some arbitrary
number of characters, like those mentioned above. therefore i'd like
to avoid a *hard* limit, where for example patches will be rejected if
the line length exceeds this amount.
for example, the current incantation for writing perl 5 tests for
parrot goes something like this:
pir_output_is(<<'CODE', <<'OUTPUT', "some lengthy and verbose test
description", todo => 'write a good test someday');
due to perl 5's limitations wrt heredocs, this cannot be split onto
more than one line. therefore, until the tests are rewritten in PIR,
there will exist many .t files with a line length exceeding even
perhaps 135 characters. rather than modifying a test header to use
multiple statements which can be better formatted (which is ugly and
prone to copy/paste errors,) i recommend that chars-per-line
formatting not apply to test headers in .t files.
further, i believe this should be generalized and extended: coding
standards should be used wherever possible without requiring undue
burden on the developer. therefore, i recommend that absolute words
like qw<must always never shall> should not be used. also, any
tools/tests/etc which enforce the standard must (and here i mean
'must') be flexible enough to deal with exceptions to the standard.
~jerry
Mr. Shawn H. Corey
> On 8/21/06, Leopold Toetsch <l...@toetsch.at> wrote:
>> My preference: soft limit 80 - keep lines shorter, if it's easy
>> hard limit ~100 - you SHALL not exceed it
>>
> coding standards are quite helpful, but cannot be applied absolutely.
> there are good reasons why a line of code might exceed some arbitrary
> number of characters, like those mentioned above. therefore i'd like
> to avoid a *hard* limit, where for example patches will be rejected if
> the line length exceeds this amount.
Don't forget that some programs, like mailers, wrap at 80 characters.
Although there is not much mailing of code, other programs may
unexpectedly wrap it. It is best to keep it under 80 if at all possible.
--
__END__
Just my 0.00000002 million dollars worth,
--- Shawn
"For the things we have to learn before we can do them, we learn by
doing them."
Aristotle
Chip Salzenberg
> 80, or 100, or 132 are all some arbitrary limits. But the latter is already
> inconvenient on a 12" powermac with reasonable font size [1].
That's an interesting and modern metric: minimum common screen size divided
by minimum readable font size. (For me that comes out to 150 columns; a 12"
display triggers my claustrophobia.)
> [1] "reasonable" for the old eyes of folks that actually have punched
> hollerith cards, when they were younger, like e.g. yours sincerly
Right there with you. My school's punch card machines were in the same room
as the TRS-80 Model I ("THE COMPUTER ROOM"). These kids today with their
hula hoops and fax machines and intarwebs...
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> Don't forget that some programs, like mailers, wrap at 80 characters.
I don't know of any mailer that is hard-coded at any given column width.
Do you?
--
Chip Salzenberg <ch...@pobox.com>
Mr. Shawn H. Corey
> On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote:
>> Don't forget that some programs, like mailers, wrap at 80 characters.
>
> I don't know of any mailer that is hard-coded at any given column width.
> Do you?
Thunderbird, Evolution, just to name two. OK, they're not hard-coded;
you can change the option (if you can find it).
What I'm saying is that we still have the legacy of 80 columns and
unless necessary, all ASCII files should fit within it.
And yes, I realize that code seldom gets mailed but there may be other
programs that have this artificial limit in them and if you're lazy
(like me), you couldn't be bother changing their factory settings. In
other words, don't exceed 80 columns unless you have a reason for it.
The thing about mail programs is that even if you set you're limit to
something large like 2048, the person who received your message may
still have a limit of 80, which would make any message you send hard to
read.
Just keep in mind that we're stuck with the 80 column limit the same way
we are stuck with the QWERTY keyboard. It's not the best there is, it's
only what most expect.
Joshua Hoblitt
> > hardware, but it's all surely been relegated to the trashheap by now. ?So:
> > Would anyone be inconvenienced by exceeding 80 columns regularly; and, how?
>
> 80, or 100, or 132 are all some arbitrary limits. But the latter is already
> inconvenient on a 12" powermac with reasonable font size [1]. Due to the
> rather verbose VTABLE macros, 80 looks a bit too limited (given the
> impressive amount of needed code changes we got recently (ambs++ BTW)).
>
> My preference: soft limit 80 - keep lines shorter, if it's easy
> hard limit ~100 - you SHALL not exceed it
fine for most desktop users but is rather annoying for those of us that
bought 16:9 format laptops just so we can squeeze 2 x 80 column
terminals side by side (at an almost legible font size).
-J
--
Bob Rogers
Date: Mon, 21 Aug 2006 15:07:16 -0700
On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote:
> 80, or 100, or 132 are all some arbitrary limits. But the latter is already
> inconvenient on a 12" powermac with reasonable font size [1].
That's an interesting and modern metric: minimum common screen size divided
by minimum readable font size. (For me that comes out to 150 columns; a 12"
display triggers my claustrophobia.)
That equation gives you a line length, but does it give you readability?
Can you comfortably read English (or whatever) text at that size if the
lines are strung out along 150 columns? I would prefer two-column
layout in that case . . . or a font large enough to reduce the text
width to, say, 80 columns again. (In fact, my preferred editing config
is a pair of side-by-side 80-column Emacs instances on a 19" screen.)
And then there is the effect of long lines on code. I am often
forced to break or refactor long code lines, which means I have to
figure out where to break them, which means I'm adding information by
doing so.
So maybe it would be more palatable to think of 80 columns as the
"Hollerith Discipline" . . . ;-}
> [1] "reasonable" for the old eyes of folks that actually have punched
> hollerith cards, when they were younger, like e.g. yours sincerly
Right there with you. My school's punch card machines were in the same room
as the TRS-80 Model I ("THE COMPUTER ROOM") . . .
We had a Mainframe, complete with attendant priesthood . . . and *lots*
of keypunches scattered over campus for the laity, who were not allowed
into the inner sanctum.
-- Bob Rogers
http://rgrjr.dyndns.org/
Jonathan Scott Duff
> Chip Salzenberg wrote:
> > On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote:
> >> Don't forget that some programs, like mailers, wrap at 80 characters.
> >
> > I don't know of any mailer that is hard-coded at any given column width.
> > Do you?
>
> Thunderbird, Evolution, just to name two. OK, they're not hard-coded;
> you can change the option (if you can find it).
>
> What I'm saying is that we still have the legacy of 80 columns and
> unless necessary, all ASCII files should fit within it.
>
> And yes, I realize that code seldom gets mailed but there may be other
> programs that have this artificial limit in them and if you're lazy
> (like me), you couldn't be bother changing their factory settings. In
> other words, don't exceed 80 columns unless you have a reason for it.
>
> The thing about mail programs is that even if you set you're limit to
> something large like 2048, the person who received your message may
> still have a limit of 80, which would make any message you send hard to
> read.
>
> Just keep in mind that we're stuck with the 80 column limit the same way
> we are stuck with the QWERTY keyboard. It's not the best there is, it's
> only what most expect.
That's an interesting vantage point. Restated, "there are still old
systems out there, let's conform to them". I could be suffering a
failure of imagination, but I don't see why we would do that. We'd
just be perpetuating the tyranny rather than ending it.
It seems to me that *if* the line length is ever a problem, we have or
can create tools to deal with it (uuencode anyone?). Also by not keeping
to 80 columns, we can weed out the modern tools that still have such
limitations and encourage the authors to fix them. And if *that* turns
out to be too big of an endeavour, we can always go back to 80 columns,
but I'm guessing whatever problems there are will be small and
localized.
just my humble opinion,
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Uri Guttman
CS> On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote:
>> 80, or 100, or 132 are all some arbitrary limits. But the latter is already
>> inconvenient on a 12" powermac with reasonable font size [1].
CS> That's an interesting and modern metric: minimum common screen
CS> size divided by minimum readable font size. (For me that comes
CS> out to 150 columns; a 12" display triggers my claustrophobia.)
>> [1] "reasonable" for the old eyes of folks that actually have punched
>> hollerith cards, when they were younger, like e.g. yours sincerly
CS> Right there with you. My school's punch card machines were in the
CS> same room as the TRS-80 Model I ("THE COMPUTER ROOM"). These kids
CS> today with their hula hoops and fax machines and intarwebs...
there is another non-technical consideration for 80 columns and that is
how eyeballs can scan lines. notice that books are printed in a similar
width (though with variable width fonts usually). eyes can scan across a
line and then back the next line best at around this size. too short
lines (like magazine columns) get tiring going back and forth too
often. too long lines make it harder to easily get to the start of the
next line. this has been tested and you can easily play with it
yourself. so 80 columns of fixed size fonts has a long history and not
just from hollerith. 132 column paper was used a bunch too but that was
so that 80 column code could be printed with all sorts of extra shit
like line numbers and stuff. also some reports wanted that but all the
input was 80 columns (good ol' real punch cards). crt's kept that width
for compatibility but they also offered 132 column modes (very hard to
read with narrow chars on vt100 type terms). i keep all my xterms at 80
columns since it does seem to be a good size for my eyes to scan. and i
also keep all my code that way too.
i find it very annoying when i have to read long lines of code. i can
make my windows wider but why ruin them just for that file?
somewhere earlier in this thread a test script with a long string and
two here docs was shown and it was very long. why couldn't the long
string also be a here doc? the only issue would be the trailing newline
but i didn't look carefully at it to see if that mattered. i use here
docs all the time in many places where others don't just to keep under
80 columns. anyhow, that is my $.80 worth here. ignore it at your
pleasure or peril.
back to lurking,
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Nicholas Clark
> Chip Salzenberg wrote:
> > On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote:
> >> Don't forget that some programs, like mailers, wrap at 80 characters.
> >
> > I don't know of any mailer that is hard-coded at any given column width.
> > Do you?
>
> Thunderbird, Evolution, just to name two. OK, they're not hard-coded;
> you can change the option (if you can find it).
I don't think that this is actually a problem as IIRC those mailers don't
have the option to mail in plain text. See
http://nick.hates-software.com/2004/06/30/33b6b8a1.html
for a description of the problem (contains profanity, as does quite a bit of
that site). Sadly for some mailers attachments are the only way to go.
Nicholas Clark