From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
Newsgroups: 
 comp.programming,comp.lang.clipper,comp.lang.c,comp.lang.ada,comp.databases.xbase.fox,alt.conspiracy
Subject: Re: [BBC] Programmers who use spaces 'paid more'
Date: Wed, 21 Jun 2017 18:48:22 +0200
Organization: Informatimago
Message-ID: <m2k2458ey1.fsf@informatimago.com>
References: <oi5vui$cva$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Trace: individual.net TlpzCDb+L/X1hasXiLpOSAonFt0/PESrMSOTZsLqMncrzOSTTX
Cancel-Lock: sha1:Njg2MzA2NzNiYTRiYjhiY2Q3NDJhNjZkMDZkMThhNDU1ZmE1NDM3Yg==
 sha1:cEBXItg5Dep2jZd7wzBIoKa41nw=
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA
      oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9
      033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac
      l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR
      mV+hO/VvFAAAAABJRU5ErkJggg==
X-Accept-Language: fr, es, en
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin)
Xref: news.eternal-september.org comp.programming:20037 comp.lang.clipper:3030
 comp.lang.c:191663 comp.lang.ada:47048 comp.databases.xbase.fox:176
 alt.conspiracy:352491
Date: 2017-06-21T18:48:22+02:00
List-Id: <comp.lang.ada>

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> Computer programmers who use spaces as part of their coding earn
> $15,370 (=C2=A312,000) more per year than those who use tabs, a survey of
> developers has revealed.
>
> Full story: <http://www.bbc.com/news/technology-40302410>

It is said that line prefixes in the form of: TAB* SPC{0,tw-1}
are the best of both world.

This is false.

First, you would need an editor to enforce it.

But it doesn't even solve the first problem of TAB, that their width
varies depending on tools and devices.

The problem is that the sequence of spaces must be of a length less than
the TAB width.  So if you start with tw=E2=82=80 and have sequences of SPC =
of
length tw=E2=82=80-1, and you read/process the file on another system using
tw=E2=82=81<tw=E2=82=80, then you will get wrong indentations.

Furthermore, when you allow TAB in source files, you may also use them
to align columns of code, eg. to align variable names in one column, and
types in another column.  And for those TAB in the middle of the lines,
the above rule is helpless, and again, you will get wrong indentations
in other environments, but also IN THE SAME ENVIRONMENT, where the TAB
width is kept constant, as soon as you use a different FONT, notably
when you use non-proportional fonts.

I know that it may seem heritic to use non-proportional fonts for code,
but the reality is that it can work very well, as long as you solve in
the IDE those problems of indentation, both prefix and inside a line.

And, it means the editor will have to compute the layout all the time,
from the parse tree.

Which leads me to the conclusion that the origin of a lot of problems is
the fact that we save "source" files that are used as-is both for
human presentation/edition and for machine processing (compiling).  I
would propose the alternative to save the programs eg. in the form of an
abstract syntactic tree (let's say lisp S-expressions), and each time it
is loaded in an IDE/editor, it would be unparsed into the specific
syntactic and layout/indenting preferences of the programmer; and when
saved, the programmer specific syntax would be parsed, and the
S-expression syntactic tree would be saved to the file.  Machine
processing can use directly these S-expression forms.

--=20
__Pascal J. Bourguignon
http://www.informatimago.com