Re: constant `e'

[Stuart D. Herring]

>>> Incidentally, I also think `(not (null n))' looks better than `n' ---
>>> as do, I believe, most Emacs Lisp programmers.
>>
>> I disagree with you on both counts.  When I see `(not (null n))', it
>> takes extra effort mentally to filter out what, to me, is just
>> noise.
>
> Agreed.

More than agreement from me: if I see `(not (null n))' I immediately want
to know what weird magic is going on that caused the author to need to add
the extra function calls.  I feel there must be something I don't
understand about the code if the obvious approach was avoided.

After all, would I be wrong in supposing that it is of some extraneous
difficulty for you to understand (after reading) a sentence of words
chosen in what is really a manner with excessive verbosity constructed
without regard or consideration for either of brevity or the avoidance of
redundant descriptions and clarifications?

(Of course 'you' are understanding; of course "after reading", of course
it's "of words"; why "regard" and "consideration", why "brevity" and
"redundancy", why "descriptions" and "clarifications"?  Why not "Isn't it
harder to understand wordy, redundant sentences?")  It's not just because
there are many words to parse, but because they by their number and
specificity suggest a complexity of meaning that simply isn't there.

>>> Take a look at this code:
>>
>>>   (cond (n
>>>          (bongo-mark-line-forward (prefix-numeric-value n)))
>>>         ((bongo-region-active-p)
>>>          (bongo-mark-region (region-beginning) (region-end)))
>>>         (t
>>>          (bongo-mark-line-forward)))
>>
>>> It's ugly, isn't it?  It's not just that `(not (null n))' is
>>> semantically clearer than a lone `n'; it's also more beautiful.

All sorts of operations discard some of the information given them, such
that the importance of that information is some subset of its normal
meaning.  Here, n is simplified to "nil or not nil", and you (Daniel) are
suggesting that we should explicitly strip it down to that information
before using it.

If I were to write (< i 256), which discards i's lowest byte entirely,
would you suggest that I write (zerop (lsh i -8)) just to make absolutely
certain that I understood that I was discarding those bits?  (And in so
doing risk the sort of bug that has arisen here for negative i?)

>> It's more alliterative, perhaps.  But it feels like I'm being talked
>> down to - the programmer is saying, in effect "you probably don't
>> understand Lisp very well, so I'll make it very very clear".
>
> Disagree.  That is not at all clearer.  It is merely occupying a
> different amount of space.
>
> Rather than "I'll make it very very clear", it is "I'll try to give
> you a nice wallpaper that won't startle you out of your sleep".

That may be true, but it also has an effect on the wakeful: it destroys
the distinction that one of the conditions is a variable test, another is
a function call, and the third is a special case.  The visual information
about the differences in complexity between the different branches is
actually quite valuable; if I want contextual hints as to how to interpret
them, I need only look at the `cond' word, which in my Emacs is nicely
highlighted in (a low-key, non-bold) red to put beyond trivial determining
the importance of the clauses.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.