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

[Clark C. Evans]

Alex Martelli [mailto:aleaxit at yahoo.com] wrote:
> it DOES mean each of these professionals need not fall back
> on vague generalities and empty hand-waving if and when their
> design choices get challenged.

I've been confronted on too many occasions where my 
"aesthetics" differed from another party's.  Perhaps
our functions were different.  But in any case, I was
able to clearly articulate what my functions were and
why the form I choose supported those functions.
The other party typically rests soley on dogma, 
giving in to "god", "universal patterns", or "beauty" 
that I obviously don't comprehend.  Oh well.  

> Somebody who's unable to do anything but talk of aesthetics
> when discussing a choice in the architecture of a software
> component is simply not contributing to the discussion.  It
> looks good to you, it looks bad to him, it looks indifferent
> to her, yawn, great debate, now let's get beyond this to the
> REAL meat of the issue, please -- the technical implications
> of this, that, or the other choice in a specific matter.

Most often those bringing up aesthetics need to go
and do their homework, detailing those functions that
they would expect or like to have from the software.
And then an analysis as to how each form satisfies those
particular functions. 

Another approach, is a user community survey, explaining 
both sides, the options and implications, and asking 
each user to think deeply before casting a vote.  Usually
if there is any core "aesthetic" it will pop out of
a stastical survey.  

> If you _can't_ get down to concrete specifics, then either
> you're not investing enough time & energy to contribute
> (in which case, staying out of a debate WOULD be a nice
> matter of courtesy), or you lack some specific (experience,
> culture, professional background, whatever) to be able to
> analyze and express your surface impressions in the issue --
> in which case, it's quite possible that they're misfounded,
> and, IF the huge investment of time and energy doesn't
> faze you, in-depth analysis to see if they ARE might well
> be warranted (and that is basically what I've been doing
> throughout this thread -- striving to help others articulate
> their objections, in great detail, by first laying out in
> just as much details my reason for NOT objecting at all to
> the architecture Guido has chosen for .join; it won't of
> course have any direct repercussion on how Python behaves
> in the matter, but it MAY have positive implications on
> technical growth of the people involved, and thus, very
> indirectly, on future efforts on their part).

Nice summary.

Clark