Choosing good names for things is difficult (was: Strange Behavior)

[Rustom Mody]

On Tuesday, June 3, 2014 6:27:25 AM UTC+5:30, Ben Finney wrote:
> Steven D'Aprano  writes:

> > On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
> > > I invoked the wrong bug.py :/ , works fine now (this happens to me
> > > when im a bit tired sometimes...).
> > Clarity in naming is an excellent thing […] Programs should be named
> > by what they do […] or when that isn't practical, at least give them a
> > unique and memorable name […].

> It's worth noting, along with this useful admonition, that naming things
> well is one of the most difficult things to do.

> It is especially difficult in computer software, while also being rather
> more important than the typical problem of naming, because of the
> simultaneous constraints that the names within computer software should
> be:

> * Memorable and evocative of the meaning to humans, who have a limited
>   capacity for remembering large sets of different names exactly, but a
>   high tolerance (even fondness) for multiple-meaning and ambiguous
>   words.

>   So, choosing unique names is difficult, and the set of memorable names
>   is severely limited.

> * Starkly unique and exact every time for the computer's use, without
>   regard to meaning, and any name is just as memorable to a computer as
>   any other.

>   So, choosing unique meaningful names is crucially important in working
>   with computer software.

> That combination – difficult but important to do well – is a perennial
> bugbear for programmers.

Add to that the restriction to limited character sets such as ASCII
– a restriction that has only historical relevance 

Somewhat more seriously there is the complement to Ben/Steven's remarks:
Good software systems reduce the naming-demand.

Egs.
1. Computationally/algorithmically, these 2 are equivalent:
   a.
     desc = sqrt(b*b - 4*a*c)
   b. 
     left = b*b
     t1 = 4*a
     right = t1*c
     desc = left - right
     sqrt_desc = sqrt(desc) 

   However the naming load of the b is 5 times a – one of the main
   benefits of a high level language vs assembly
   In the same vein…
2. λ-expressions reduce the need to name functions.
3. Point-free style – or more on-topic "Tacit Programming" –
   reduces the need for function arguments
   http://en.wikipedia.org/wiki/Tacit_programming
4. Structured programming removes the need to name control points with labels
5. And problems like this one can be reduced by using the interpreter
   more and named program files less.  Of course even if you can check
   in the interpreter, to communicate with others/file a bug you may need to
   name a file.