Larry Wall's comment on python...

[sismex01 at hebmex.com]

> 
> sismex01 at hebmex.com wrote:
> 
> >>Ironically, Guido originally ruled (in the style guide, IIRC) 
> >>that thou shalt use tabs and tabs are 8 spaces, "as god
> >>intentended them to be."
> >
> >Yeesh! Why in God's name would he say such a dumb thing?
> >I mean, even ancient mechanical typewriters have movable
> >tab settings. Rigid, 8-char tabs is just so... neolithical.
> >
> 
> Once upon a time, a large class of computers, and their attendant 
> peripherals, OSs and utility programs universally implemented tabs 
> hard-wired at 8 stops.  In some circles this heritage extended
> back 30 or 40 years.  Unix originally followed this convention,
> as did IIRC all Dec computers and that of most other "minicomputer"
> vendors.
> Ed and the original VI editors only had fixed tab stops consistent
> with terminal drivers and all the unit record equipment at the time.
> IIRC, even Emacs originally only had tab stops at every 8 columns.
> The original PC also followed this convention, though not all
> applications did.  I don't know for sure but I bet $1 that Linux
> tty drivers today also are hard wired at 8 char tab stops.
> 

Thanks for a beautiful reply.

Well, I might not be an old fart :-), but I *was* kinda present
at that time, I started work in highschool hacking on CP/M machines,
writing drivers for diverse printers and terminals for some apps
(ahh, customizable terminal control... we lost that during the
PC era, everybody wanted CGA, MDA or Hercules).

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.

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.

> Now, if you've ever worked in an environment where EVERYBODY uses the 
> same tab stops then you'd probably agree that tabs are vastly 
> superior to spaces.  I don't think there's any question.  I presume
> it's from this perspective that the right honorable BDFL issued his
> original proclamation, which is actually quite reasonable, especially 
> from my old fart's perspective.

Sounds quite likely.

> 
> In fact, problems only arise when alternative, competing tab stop 
> conventions try to coexist, which I agree is not  generally solvable. 
> Closest solution I've seen is some sites where everybody uses Emacs
> and employ coding conventions so that on startup Emacs can read a 
> specially coded comment and automatically switch to the proper indent
> for that file.  This can sort of work but your printer and other
> rendering utilities also all have to recognize the codes.  Spaces
> are a more practical solution.

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 myself still prefer tabs as I find "indenting" and "out denting" 
> sections of code to be a common operation (in Python and in other 
> languages).  Inserting or removing an "if" or changing inline code
> to a function makes indenting and out denting a common operation.
> In the environments I use, this works well with tabs and not so well 
> or at all with spaces.  By default, I still prefer 8 char stops but
> I also find I can live just fine with 4.  But I can't stand it without
> tabs.  I'll convert to spaces if I need to when delivering code but I 
> can't work on it that way.

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.

Problems arise when mixing tabs and spaces, because you can't ask
a program to read your mind; so, is move-left a "jump to previous indent
level" or a "move to left character position"?  That's the users's
responsability to define, but with flexible tab stops, or tab positions,
it becomes much easier.

> 
> Anyway, what's wrong with the "neolithical" 8 char stops?  
>

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.

Would an electronic calculator survive, if it couldn't do the same
operations as a mechanical adding machine?

> For several decades, all the C code ever written was tab indented
> at 8 columns, along with most of the text and other programming
> languages on Unix.

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

> Some people complained that in practice 8 char tabs forced them
> to indent too much and their programs got squashed off the right
> edge of the page.  I have little sympathy for that argument, as
> I feel if your program is properly modularized then this should
> not be much of a problem as individual modules should not have
> to be indented all that much.

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.

> Also, I suspect part of the pressure came from Pascal users, 
> where some coding conventions require indenting two levels, 
> once for the begin/end pairs and again a second time for the
> code contained between them.  What a crock.

If it was corporate standard, it sux.  But, as for personal taste,
I never could decide which looks better, either:

if something > another
begin
  blah blah
end;

--- or ---

if something > another
  begin
  blah blah
  end;

--- or ---

if something > another
 begin
  blah blah
 end;


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.

> 
> For what it's worth, Python's C implementation today appears 
> to be tab indented to 8 columns, at least all the parts I've
> looked at.  The main interpreter loop is a good example of a
> "complex" piece of code.  The innermost loop includes a single
> switch statement that's over 1400 lines long!  Surrounding logic
> require that the switch statement and case labels start 2 tab
> stops in and thus the body of each case starts 3 stops in or in
> column 24.  Yikes, that's like 1/3 of the total.  And yet 
> none of the case bodies extend past column 73 or so.  Turns 
> out that in practice most code lines are pretty short.  The ones
> that aren't typically are function calls with multiple arguments,
> and these may easily be split onto multiple lines (often thereby
> increasing readability).  Since Guido personally wrote the bulk
> of this system as a labor of love, I surmise that he's still pretty
> sentimental about the old ways.

I suppose you're right.

It's not the same to write something for love of the work,
as when it's for just work.

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

It's been nice tossing ideas around :-)

-gustavo

Advertencia: 
La informacion contenida en este mensaje es confidencial y restringida y
esta destinada unicamente para el uso de la persona arriba indicada, Esta
comunicacion representa la opinion personal del remitente y no refleja
necesariamente la opinion de la Compañia. Se le notifica que esta
estrictamente prohibida cualquier difusion, distribucion o copia de este
mensaje. Si ha recibido esta comunicacion o copia de este mensaje por error,
o si hay problemas en la transmision, favor de comunicarse con el remitente.


Todo el correo electrónico enviado para o desde esta dirección será
procesado por el sistema de correo corporativo de HEB. Tal correo
electrónico esta sujeto a ser almacenado y puede ser revisado por alguien
ajeno al recipiente autorizado con el propósito de monitorear que se cumplan
las normas de seguridad de la empresa.