Backend nearly entirely converted to D

[H. S. Teoh]

On Thu, Nov 08, 2018 at 05:50:20PM +0000, welkam via Digitalmars-d-announce wrote:
> On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:
> > I don't speak for the compiler devs, but IMO, one-letter variables
> > are OK if they are local, and cover a relatively small scope.
> 
> By saying more descriptive I should have clarified that I meant to
> change them to 3-7 letter names. Small variable names are ok for small
> functions like the one in attrib.d called void importAll(Scope* sc).
> It has variable named sc and its clear where it is used.
> 
> Now for all of you who think that one letter variables are ok here is
> exercise. Go and open src/dmd/func.d with your favorite code editor.
> Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC
> long. Now find all uses of variable Dsymbol s. Did you found them all?
> Are you sure?

Yes. My editor knows to search for 's' delimited by word boundaries, so
it would not match 's' in the middle of the word, but only 's'
surrounded by non-alphabetic characters.


> Ok now do the same for variable loc. See the difference?

I see no difference.

Moral: use a better editor. :-P


> > Java-style verbosity IMO makes code *harder* to read because the
> > verbosity gets > in your face, crowding out the more interesting
> > (and important) larger picture of code structure.
> 
> What editor do you use?

Vim.

And I don't even use syntax highlighting (because I find it visually
distracting).


> Here is the worst example to prove my point but its still sufficient. All
> editors worth your time highlights the same text when selected and here is
> example of one letter variable.
> https://imgur.com/a/jjxCdmh
> and tree letter variable
> https://imgur.com/a/xOqbkmn

Your syntax highlighter is broken.  It should not match substrings, but
only the entire word.  Vim's search function does this (including the
highlights, if I turned it on, but by default I leave it off).


> where is all that crowding and loss of large picture you speak of? Its
> the opposite. Code structure is more clear with longer variable names
> than one letter.

Your opinion is biased by using a flawed syntax highlighter / symbol
search function.


> > As Walter said in his recent talk, the length of variable names (or
> > identifiers in general, really) should roughly correspond to their
> > scope
> 
> At best this is argument form authority. You said how thing should be
> not why. For argument sake imagine situation where you need to expand
> function.  By your proposed rules you should rename local variables to
> longer names.  Thats ridiculous. Yes I watched that presentation and
> fully disagree with Walter and know for sure he doesnt have sound
> argument to support his position.
[...]

It's very simple.  The human brain is very good at context-sensitive
pattern matching, something which computers are rather poor at (well, at
least, traditional algorithms that aren't neural-network based).
Natural language, for example, is full of ambiguities, but in everyday
speech we have no problems figuring out what is meant, because the
context supplies the necessary information to disambiguate.  Therefore,
frequently-used words tend to be short (and tend to shorten over time),
because it's not necessary to enunciate the full word or phrase to
convey the meaning.  Rarely-used words tend to be longer (and resist
simplification over time) because context provides less information, and
so the full word becomes necessary in order to minimize information
loss.

Function parameters and local variables are, by definition, restricted
in scope, and therefore the context of the function provides enough
information to disambiguate short names.  And since local variables and
parameters would tend to be used frequently, the brain prefers to
simplify and shorten their identifiers.  As a result, after
acclimatizing, one begins to expect that short names correspond with
local variables, and long names correspond with non-local variables.
Going against this natural expectation (e.g., long names for locals,
short names for globals) causes extra mental load to resolve the
referents.

Your counterargument of expanding a function and needing to rename local
variables is a strawman.  A function is a function, and local variables
don't need to be renamed just because you added more code into it.

(However, there *is* a point that when the function starts getting too
long, it ought to be split into separate functions, otherwise it becomes
harder to understand. On that point, I do agree with you that dmd's code
could stand improvement, since 900-line functions are definitely far too
long to keep the entire context in short-term memory, and so using short
local identifiers begins to lose its benefits and increase its
disadvantages.)


T

-- 
Many open minds should be closed for repairs. -- K5 user