OT: Crazy Programming

[James J. Besemer]

Donn Cave wrote:

> Quoth "James J. Besemer" <jb at cascade-sys.com>:
> ...
> | Of course, there are some matters that are purely subjective.  I think the
> | difference is when humans begin to pass judgement on things, rather than
> | merely measure them.
>
> What does "subjective" mean?  Applicable only to the individual self
> and without relevance to anyone else?

1. existing in a person's mind and not produced by things outside it, not
objective.
2. depending on personal taste or views, etc.

> If so, then I think I'm hearing
> that a lot of what we call subjective, isn't.  Presumably because we
> aren't all so different after all, and though we don't fully understand
> the basis for our reactions to things, that basis is still shared by
> any being like us.

I agree that many things often regarded subjective are not subjective at all.

E.g., beauty.  People say beauty is in the mind of the beholder but I would
counter argue that humans are programmed to regard certain features as beautiful
and others as not.  Clearly, defects tend to be not beautiful.  To some degree,
the complexity of the 3D surfaces that make up a face or a body is inversely
related to beauty.  Wrinkles are not particularly beautiful while smooth skin
with gentle features is.  Humans are programmed to be attracted to their
children, and this translates to some extent to adult 'beauty' in that
attractive people tend to be "cute".  I.e., they have facial features that are
understated and somewhat child like and less adult and certainly show no signs
of aging.  And of course, human males anyway are genetically programmed to
respond to certain female body features.  One could argue it's not subjective at
all.  I read somewhere that there's been a fair amount of study on this and with
computer models of faces there is surprising human consensus about what is
beautiful and regarding relative degrees of attractiveness.  (Frankly, I suspect
that beauty is 'subjective' is as polite lie we tell ourselves because the
majority of people are not fortunate enough to mate with beautiful partners.
And anyway, it's certainly not PC to talk in objective terms about people who
are not beautiful.)

Similarly some things that are considered objective often are not objective at
all.   E.g., with politics, I think most people pick a side, and then reinforce
that choice by selectively interpreting most of the information they get from
the world of politics.  Humans are intrinsically tribal in nature and quickly
form we vs. they groups.  Democratic Politics feed that instinct by exaggerating
the differences, the importance of the outcomes and by demonizing the other
side.

> In this analysis, we don't just happen to think Python code looks
> better because of some inexplicable individual quirk.  That seems
> reasonable to me.

This is harder because judging the 'beauty' of code is much harder to extract
from your training and background, and what you're used to.  Unlike human beauty
you don't have any genetic predisposition one way or the other.

IIRC, this thread started out with the notion that Python was somehow
objectively more beautiful than Perl.  Frankly I very much share that BELIEF
(subjective judgment) but I think it's an uphill battle to argue the case from a
purely objective basis.  E.g., to me personally it seems you can make a case on
the dollar signs alone.  I jokingly tell people they'll be 20% more productive
in Python simply on the basis of dollar-signs-not-typed.  ;0)  However, I know
people who are immersed in Perl and love it and they think the dollar signs are
great.  I was amazed to hear this but they pointed out that, among other things,
they work even WITHIN quoted strings (just like in the shell):

E.g.,

    print "a = $a, b = $b, c = $c\n";

is arguably more elegant and less tedious than

    print "a = ", a, ", b = ", b, ", c = ", c

So, if you're used to "scripting" languages, the dollar sign prefix looks
natural rather than ugly.

To my Perl enthusiasts and many others coming from a C background, the necessity
to type

    foo += 1

instead of

    foo++

is patently absurd.  Similarly the omission of the several other extremely
common and useful C idioms that are glorified in Perl is viewed as a glaring
defect in Python.  All the rationale why they're not needed and how there are
work arounds sound (to these listeners) like so much crap.  I agree it's a minor
issue but it's hard to build an objective case that Perl didn't make the better
choice in this regard (being one of the few places where Perl did NOT try to be
'inventive').  Note how often these topics come up and the answer is that "you
have no choice, eventually you'll get used to it, once you're properly
Pythonized it won't seem so bad..."  Sounds like the epitome of  SUBJECTIVE to
me.

In the area of good vs. ugly code, I think there actually are only a few things
that most humans agree about and thus could be considered objective criteria.
Probably the least controversial item is indenting code to reflect control
structure.  This is so ingrained in most languages and in most programmers for
so long that virtually nobody would argue against it.  In fact, I submit that
this purely stylistic expression being nearly universal in the first place is
what made Python's innovation of relying upon it possible.  (Incidentally, this
feature did NOT originate with Python or with ABC.  The concept was discussed in
ACM's SIGPLAN Notices ca. 1985 and was used in several experimental languages
before Guido thought of it or decided to use it).

Beyond that, the general notion of clarity ranks very high, thought that is hard
to pin down in objective terms.  In general, discussing 'clarity' means that (a)
you're reading code not necessarily writing it, (b) you're trying to understand
it, and (c) you're making a JUDGMENT about how easy it was to understand.
Sometimes clarity means good comments.  Sometimes clarity relies on "proper"
choice of variable and function names.  Sometimes it relies on the fact that the
algorithm itself is simple and elegant (somewhat independent of the
implementation in a language).  I think clarity is vitally important but I also
think it's highly subjective.  Thus for many people you get the "I don't know
what it is but I know it when I see it"  (and then, usually when THEY write it.
;o)

Overall, I think code beauty is almost entirely subjective, i.e., strictly in
the mind of the beholder.  Beyond proper indenting, most of the choices people
have in writing code are actually points of contention.  It doesn't apply to
Python but in C a lot of people have devoted a lot of energy arguing (and
changing) the locations of curly braces.  In Python, there is no clear group
consensus about tabs vs. spaces (Ms. Creighton's amusing PEP notwithstanding).
Of course, people can band together and agree to follow an arbitrary style.  And
with time that particular style will look 'beautiful' and all others will be
perceived as 'ugly' or at least less beautiful.  But most of it is subjective
judgment, not objective measurement.  You can argue that it's 'good' in the
sense that it's settled and an arbitrary settlement is better than continued
debate.  But you can't argue that it's 'good' in some intrinsic sense.  Rather,
you can but you've left the domain of objective debate.

> But then, what about list comprehensions?

Dunno.  They're quite new to me personally so I find them harder to understand
than map() and filter() or for loops.  However, they happen to resemble a fairly
common mathematical notation, so to some people they might seem very natural and
the epitome of clarity.  And I acknowledge that my preference for map() and
filter() is special in that if you don't already have that idiom in your
background then they're alien as all hell.  Since comprehensions are non-obvious
to me, since they're about the slowest possible way to form a list, and since
they're not backwards compatible with more commonly available Pythons, I'm not
sure I'll use them all that much in the foreseeable future.  Bottom line: the
choice to use them is entirely subjective.  ;o)

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com