help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: if vs. when vs. and: style question


From: Óscar Fuentes
Subject: Re: if vs. when vs. and: style question
Date: Mon, 30 Mar 2015 03:33:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> What is α?  What is β?
>
>> Wouldn't have it been better to name those variables number-of-rows
>> or tree-height or some other words denoting their actual meaning?
>
> Usually, within the context where the mathematical formula is used,
> these variables *are* names denoting their meaning.  These depend on
> notational conventions used within specific communities (and usually not
> formalized), but they are convenient.  So instead of
>
>     has_type env exp type
>
> you say
>
>     Γ ⊢ e : τ
>
> and it is just as explicit, because τ does mean "a type", and Γ means "a
> type environment", and ":" means "has type", and "⊢" means "based on
> hypotheses such and such".  Some of those letters/signs have meaning
> shared within a fairly large mathematical community while others are
> much more specific to a specialized subfield.

Math textbooks teaching the same matter usually start with a table of
symbols, with subtle and capricious differences from one book to
another. :-)

> Of course, if you're not familiar with the local conventions, it looks
> like line noise, but otherwise it offers people much higher concision,
> so they can focus on the important aspects.

Those conventions make sense when you work on the same field for long
enough periods (students, specialized programmers...) but I guess that
most of us deal with heterogeneous code on a regular basis. Heck, we do
use different programming languages on the same session. After the end
of the day (or week) when you worked on code dealing with finance,
graphics, databases, concurrency, the Emacs redisplay, generic
algorithms (sorting, etc) and what-not, then you do realize how
counterproductive is to rely on non-obvious local conventions.

As for the higher concision, it is acceptable for cases where the
"read-time"/"think-time" ratio is low (say 15 minutes thinking for each
minute reading) but for the common "what this code does" case, where
such ratios are unnaceptable and a sign of bad coding, those funny
symbols just add cognitive strain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]