Larry Wall's comment on python...

[James J. Besemer]

sismex01 at hebmex.com wrote:

>AND, I distinctly remember that most printers could customize
>their tab stops via escape codes, same as some (not all) terminals;
>I worked a lot on some Xoroc terminals, and lots on a Northstar
>Advantage (ahh, beautiful hardware... *snif*) and they also had
>customizable tabstops.
>
Escape codes?  What's that?  ;o)

Yes, I think in the trans-PC era -- or really it was the microprocessor 
era when it finally was possible to dedicate a computer to a desktop 
printer -- configurable tab stops became the norm.  I remember the first 
printer I bought.  It had a zillion escape codes for the half dozen 
crummy fonts plus Kanji etc., etc.  I recall you could set tab stops out 
of order and make it zig-zag back and forth between them.  Krazy uP 
programmers had ROM to spare and got carried away.  To my knowledge I 
NEVER used ANY of these features (except perhaps sometimes picking an 
alternative font).  

>Hmmm... maybe, what I'm getting at is, why did terminal-designers
>everywhere toss out years of research in typewriter technology
>(at the time) and ignore customizable tab-stops?  It's simply not
>sane, I think.
>
I don't know for sure and only purport to report what happened.

I guess what I'm saying is that the "heritage" extended back before 
printers and terminals were smart enough to have tab stops.  Most early 
equipment simply ignored it or printed a goofy symbol.  

Fact of the matter, a LOT of unit record equipment (and I date myself in 
even using that term) in the decades before the microprocessor did not 
have expandable tabs.  Or if they did it was not generally user 
programmable.   E.g., the "line printer" we had attached to our PDP-11 
had no notion of tabs.  Nor could it print square or curly braces or a 
few other characters critical to C programming.  All had to be done by 
the device driver.  It DID have a "programmable" sense of vertical tab 
and vertical height -- but that was reprogrammed by changing a carefully 
crafted punched tape.

Then there was an issue that communicating tab settings from user space 
to the device was an additional complication most users didn't care 
about and most systems programmers didn't want to bother with.

This is just speculation but I believe the heritage dates back to where 
the effort to compute tab stops was not insignificant.  I believe 8 
chars was chosen because it could be computed with masking functions 
instead of a divide or mod.

Then too, from the beginning Unix acknowledged that SOME terminals were 
smart enough.  So you could tell the driver to send tabs instead of 
expanding them.  We actually had some "smart" terminals with user 
settable tabs.  Everybody wasted some time mucking with tabs and then 
gave up.  It simply was too much of a nuisance for no gain.  There 
wasn't any software that knew about your hardware stops so there was 
absolutely no point.

>Indeed.  I *do* recognize that using actual tabs is a much better
>solution, but having hard-stops each 8 chars is a show-stopper,
>so if my editor can't customize it's tab width, or customize it's
>stops (say, when in asm, on columns 12, 18 and 32) then I'm never
>going to use it willingly (you *could* whip me into submission,
>but I'll curse your name for the rest of my natural life ;-)
>

I'm not telling anybody what to do.  Be free.  Be happy.  "Go wherever 
you want to go and do whatever you want to do -- just so long as you 
don't hurt anybody."

>That's what I mean.  An editor should be smart enough to handle tab
>stops at arbitrary columns, and when using tabbed text, jump between
>those columns.  Best of both worlds.
>

I think now days most do.  But IMHO it's more effort than it's worth.

"Arbitrary" columns seems overkill to me, something for word processing, 
not computer programming.  I can live with evenly spaced tabs at 4 or 8.  

For me, 8 seems less troublesome because that's how it comes out anyway 
whenever I am NOT using my special editing environment.  And I do like 
sometimes to use "more", "grep", "pr", "lpr", "notepad", etc., etc. to 
process my files and most of them still live in an 8 char stop world.

>I find them hmmm... philosophically [sp] "wrong", because computers,
>being programmable and customizable ("terminals" being specialized
>computers) and so, should _at_least_ do what their mechanical
>counterparts are able to do, and then some.
>
The proportional-spaced glyphs I'm looking at on the flat panel monitor 
are so far removed from the original typewriters that I'm not sure 
there's even a connection.  Yeah, "typing" is a tiny subset of what we 
use computers for but the analogy sort of breaks down after that.  I 
recall this ancient Remington typewriter that was my fathers -- I used 
it for papers in high school.  Tab stops were changed by removing and 
reinserting these little clips in the back of the unit.  I guess MS Word 
is SORT of like that only it's easier to insert, remove and move the 
stops plus you have more flavors.

Too, if we're talking about programming, "arbitrary" tab stops seems way 
overkill.  I use all sorts of fancy features when I'm formatting 
documents.  But with code -- I don't even like proportional fonts.

>Would an electronic calculator survive, if it couldn't do the same
>operations as a mechanical adding machine?
>
Well, possibly.  The myriad extra operations and speed and quiet and 
portability of modern electronic calculators makes them preferred though 
many lack hard copy output, a standard feature of most mechanical 
calculators.

Anyway, you're confusing the ability to do something (arbitrary tab 
stops which I believe is readily achievable) with the need to do it 
(which is what I was questioning).

>Yup, I did the same also, but maybe it was because there was no
>alternative?
>

Spaces were an alternative that some people used.   Some fools didn't 
indent at all.

One C project, the lead came up with a standard that indented each level 
3 spaces.  His reasoning was (a) tabs were bad so they were out, (b) two 
spaces was too small, (c) 4 was too many to type and thus (d) 3 spaces 
was Just Right.  Needless to say, I used tabs and was prepared to 
convert if need be when I finished.

Alternatively, maybe the standard prevailed for so long because it 
worked so well for everybody.

>Same here, I find that kind of argument a falacy: "my program is
>badly modularized and I can't read it clearly, it's the editor's
>fault".  Nope, sorry.
>

Then why the emotional contrast between 4 and 8?

>If it was corporate standard, it sux.  But, as for personal taste,
>I never could decide which looks better, either:
>
>I'm still somewhat ambiguous over which is more readable,
>maybe it depends on the context, the surrounding code,
>the tab width, the amount of spaces one uses for the
>begin/end indent and the actual code indent, I don't
>know and I don't really care to do reasearch about it.
>

Personally I think they all suck.  Big problem was the begin/end in the 
first place.  It was such a relief to switch to {}, and further to get 
rid even of them.

>It's been nice tossing ideas around :-)
>
Ditto.

REgards

--jb

-- 
James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at cascade-sys.com
				http://cascade-sys.com