Functionalism, aesthetics Was:(RE: I come to praise .join, not

[Alex Martelli]

"Carlos Ribeiro" <carribeiro at yahoo.com> wrote in message
news:mailman.985145848.16117.python-list at python.org...
> At 08:11 20/03/01 +0100, Alex Martelli wrote:
> >Back when "Concorde" and "Jumbo" first appeared on the scene, for
> >example, non-experts found the former quite beautiful, the latter quite
> >plain.  Sure the sleek, fast-looking lines of Concorde were superior to
> >the goofy-looking fatness of Jumbo?
>
> Are you sure that this is a good example? One thing is to be impressed by
> the look, and the other is to actually use the product. Opinions may (and

Oh yes, it's an EXCELLENT parallel, EXACTLY because of this distinction.

People who are attacking the joiner.join(sequence) syntax [some arguing
for sequence.join(joiner), others for string.join(sequence, joiner)] are
NOT doing so on the basis of having actually used the various possible
syntaxes and having found functional/operational defects in the one our
BDFL has blessed.  Rather, they handwave about this operation 'clearly'
belonging to the sequence-object rather than to the joiner-object, or
'clearly' to neither one, or (more often) the resulting code 'looking
bad'.  The first two lines of reasoning are based on considerations of
functionality; are, thus, rationally debatable; and I think I have
shown why (in a language, such as Python, where general polymorphism
applies to the object to the left of the '.') the various functional
characteristics of the architecture chosen by the BDFL are Just Right.

The line of, well, 'argument' (loosely speaking...) based on "it looks
bad", on the other hand, is basically a waste of good bits.  If the
functionality IS right (let's settle *that*, first!), and the chosen
form follows that (right) functionality, then any perception that
the chosen form is 'bad' must be the consequence of an optical
illusion -- and, since it IS well known that humans (even quite
experienced and well-trained ones) ARE rather subject to optical
illusions and other misperceptions, this hypothesis is anything
but far-fetched.  The only item of interest remaining is how best
to present the rationale for the joiner.join(sequence) syntax, so
as to help as many users as possible overcome this particular
misperception (ideally by understanding enough of its root causes
that correcting this identified misperception may also help with
as-yet-unidentified further ones).  "Arguing" (loosely speaking...)
on "pretty" vs "ugly", on the other hand, is not productive.


> >issues.  Vox populi is NOT necessarily vox Dei -- not when
> >the underlying technology is too new (a few centuries) and/or
> >not reflected in immediately apperceivable traits.
>
> I'm not talking about completely untrained users here. Most doctors would
> appreciate the explanation given by the pharmaceutical industry. And while

Definitely -- they *ARE* well trained in the rudiments of chemistry
and pharmacology, after all!

> I agree that Vox Populi != Vox Dei, this has *nothing* to do with the
> technology maturity as measured by time alone. Our innate reaction against
> change play a big role here too.

There is a dynamic balance between neophily and neophoby -- if our
innate reaction was ONLY against change, then you would hardly see
the "new! improved!" labels on detergents boxes on supermarket
shelves, would you?  Nor would the clothing fashion industry thrive.

Craftily triggering and exploiting the -phily or -phoby part is
an important marketing technique, but not very germane here.  What
IS germane is that there are some fields (where we're biologically
predisposed and/or collectively trained by centuries or millennia
of shared cultural experiences) where "innate" reactions of
not-specially-trained users must carry enormous weight; in other
fields, ones that are newer and/or farther from our biological
specializations (characteristics that often go together), the
issues are very different (training is needed to give us enough
appropriate memes to overcome the lack, or counterproductivity,
of our genes' influence on untrained/instinctive judgments).


> > > To summarize it: a  *technically* optimal solution for a problem is
not
> > > always the *best* solution. If it does not look intuitively good for
most
> > > users, its probably a bad solution.
> >
> >So, you're arguing that the amount of artificial coloring should
> >have been kept high (who cares about giving users cancer, right?),
> >since that bright color was definitely what "looked intuitively
> >good for most users" as proved by the endless carping...?
>
> Ok, ok. ' Users' is misleading. However, for Python, 'users' usually means
> programmers, people with sufficient knowledge to make good questions about
> proposed changes.

I think it's a _minority_ of programmers who fully understand
and "intuitively" grasp issues of polymorphism (and others that
relate to the depths of O-O: inheritance, delegation, multiple
inheritance, singletons, holding vs referring-to, etc, etc) in
languages that are richly multi-paradigm (and Python is very
much so, at least on a par with C++).  Ingrained habits, and
principles not critically examined but subconsciously distilled
from experience that may well not be relevant to the current
situation, stand in the way, far too much so.

If you heard such assertions from somebody whose business is
selling training or advice, you might reasonably be suspicious
that his self-interest may be prompting them.  As for me, while
I do like teaching and advising, I'd still rather be _DOING_
coding and design -- yet, I *must* invest a goodly proportion
of my working days to consulting, design-reviews, code-reviews,
preparing and teaching seminars, etc, because the firm I work
for has determined that this is a very high-leverage use of
my time (and, I will admit, they ARE right about it).  To be
clear about it, it's my _colleagues_ I'm training and advising
(and I have been doing so, for a growing fraction of my work
days, ever since I joined this company over 12 years ago);
_brilliant_ people, one and all, programmers of varying but
generally considerable experience, guys and gals I'm PROUD to
be working with; yet, with all that, the consulting and the
teaching are _still_ absolutely necessary to make them as
productive as can be in their design and coding activities.

I think this gives me considerable perspective and experience
on what conceptual and perceptual errors brilliant (but
typically overworked) practising programmers are prone to.
(I've also taught programming newbies, e.g. back when I was
moonlighting as a university professor, so I also know
something of the rather different set of misperceptions
that _they_ are most at risk of -- but my experience of
that is nowhere close to what I have in dealing with people
who have been programming professionally for years).

And I don't find "discussion" (loosely speaking) based on
'aesthetics' of some system-architecture choice is very
productive at all in this context.  Far too often, the
(brilliant, mind you!) practising programmer who can't
articulate his/her architectural objections beyond the
stage of "it _looks_ bad" is subconsciously 'deducing'
said objections from other, not-applicable-here contexts
he or she is more familiar with.  _Refusing_ to 'debate'
(what debate?!) on the plane of 'aesthetics', and firmly
insisting that very specific and concrete (functional!)
grounds for the objections be discovered, is by far the
most productive stance in such cases, in my experience.


> > > Its unfortunate that in many cases the non-expert user keeps quiet,
> > > assuming that whatever opinion the "master" haves, its going to be
better
> > > than theirs - after all they are the so-called experts.
> >
> >Ask the experts in any field whether untrained users keep too quiet,
> >or not enough, in their field, and you'll get a different opinion (of
> >course, self-serving conscious or unconscious biases are at work
> >as well!).
>
> The fact that many people complain without reason is not a valid excuse
for
> ignoring all complaints.

But refusing to accept complainants who are unable or
unwilling to work to put their complaints in specific
and concrete terms can be by far the best approach.


Alex