🚀 go-pugleaf

In article <1992Aug27.201810.20982@usenet.ins.cwru.edu> ah739@cleveland.Freenet.Edu (Leslie J. Somos) writes:
>
>In a previous article, rh@smds.com (Richard Harter) says:
>[...stuff...]
>>Too general.  [This sentence no verb.]  One can distinguish between
>>forcing a choice between essentially equivalent alternatives and the
>>eliminating the alternatives altogether. 

>Let's have some more choices than just 2.
>"Anybody who says there are two sides to any question
>suffers from a lack of imagination." -- ?

Bah, humbug.  You are making ontological commitments on my behalf that
I do not acknowledge.  The mere fact that I say that I can distinguish
between red and blue does not mean that I am denying the existence of
yellow and green, to say nothing of heliotrope.

>>Consider the language FL (short for fascist layout). 
>[...]

>OK, I believe most people would agree that choices in program layout are
>just fluff, unimportant (in languages that don't care).

>>Now consider the language FVN (short for fascist variable names).

>STOP RIGHT THERE.  I, for one, will not agree that choice of variable
>names is not important.  Of course, the compiler doesn't care, about
>names or layout, that's why obfuscating programs work.
>But variable names are _very_ important to humans who must read
>programs.

Er, one of us missing the point [assuming that there is one :-)].  In
the deleted original it was assumed that names were drawn from predefined
dictionaries.  Consider the following argument.

	The term, computer language, is a misnomer.  When I refer to
	a natural language such as English or French, I am referring
	to the both the grammar and the dictionary.  Except for neologisms
	everyone writing English uses the same words from the same
	dictionary.  When people speak of a computer language they
	specify only the grammar and a handful of words that are
	grammatical terms.

	Each program constitutes a language in its own right; the
	declarations in the program are its dictionary.  Programs in
	a "computer language" are actually a family of languages, each
	sharing a common grammar.

	Suppose, when we read a book we had to first read the dictionary
	for the book that told us what each word meant.  Suppose that
	we had to write a new dictionary afresh for each book we wrote.
	Not only would literacy plummet, with the vocabulary of each book
	being a major study in its own right, but the quality of the
	vocabularies would suffer, since each author must reinvent the
	English dictionary de novo.

	Surely we would consider such a state of affairs to be absurd.
	Yet we accept this state of affairs in computer software
	without question.  Programmer A in program X uses the variable
	fooby; it is an integer signifying the number of chickens in a
	chicken coop.  Programmer B in program Y uses the variable fooby;
	it is a character string in a class instance signifying the
	name of the city dogcatcher.  The term, fooby, means nothing,
	or at best its meaning is a shadow written on the sand.

	How much better it would be if I could go from program to
	program and find that the meaning of variable names did not
	change capriciously.  How much better would it be if I, as
	the author of a program, did not have to invent my own mini
	language anew with each new program.

>You can have all kinds of constraints on what a compiler will/won't
>accept, or relax them all you want.  From a programmer's point of
>view, the most important audience for a program is a programmer.
>We don't care how hard it is for the compiler to handle it, we
>would like to make it easy to understand a program that we have to
>look at.

I think you are assuming that the point of a FVN language is to simplify
life for the compiler writer.  Not at all.  The point is to remove choices
for the programmer that should not have to be made.

You might very well argue that a FVN language is not practical, or that
the notion is ill-judged, or that there are compensating advantages in
creating separate notation for each program.  However to simply claim
that names are important to a programmer is to miss the point.

I am far from claiming that FVN is the way to go.  However there is much
to be said for it, and obeisance is made to the concept in practice.
Programmers do use standard include files and standard notation.  The
use of idiosyncratic substitutes for standard notation is generally
recognized as creating maintenance problems, regardless of the merits
of the idiosyncratic substitute.

When I wrote English prose I do not feel handicapped by having to use
words from the dictionary.  I still have the freedom to choose which
words to use and how to arrange them.  Indeed, the quality of my prose,
such as it is, would suffer immensely if I had to invent my own words
and carefully explain them before I could say anything.  One can at
least entertain the suspicion that the same might be true of computer
programming.
-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.