The narcissism of small code differences

Rick Johnson rantingrickjohnson at gmail.com
Mon Nov 11 07:50:41 CET 2013


On Saturday, November 9, 2013 6:42:04 AM UTC-6, Steven
D'Aprano wrote: 
> Uses an example written in Ruby, but don't
> let that put you off:

Why would it? I write Ruby code all the time. Ruby code in
and of itself does not bother me, what bothers me about Ruby
is the ease at which a programmer can write inconsistent and
convoluted code -- evidenced by the poor examples in your
linked article. Case in point.

To save anyone else from reading this long-winded "blab
fest" chalk full the driest humor and "cyclic illogical
meandering" that could make a ferris-wheel blush with
jealousy...

  In a nutshell the author attempts to plead for the
  "longevity" of "old code bases" simply on the basis of his
  assertion that "old code bases" are "less buggy" and
  contain more "wisdom" than their new brethren -- both of
  which are absurd conclusions!
  
Now, whilst he is correct regarding the narcissism of
programmers (i must admit we are all guilty of this deadly
sin), his attempts to draw parallels between "Freudian
pathologies" and "software development idiosyncrasies" is,
in fact, the very HEIGHT of sophistry!

Has the author considered that new functionality often
renders old code bases useless, or at the very least,
antiquated? Even code bases that are in fact "bug free" (for
*some* definition of "bug free"!)

Has the author consider that changes in external
dependencies can render a code base useless? Py3000 ring
a bell folks?

Is the author also unaware of evolution? 

Doth he falsely believe that even the BEST programmer can
look back on code he wrote a few years ago and not think of
some way it could be improved? GvR had such a realization
not so long ago -- and then there was Py3000!!!

>From something as simple as code restructuring for
readabilities sake; to choosing better naming conventions;
to improving consistency; reformulating algorithms to
eliminate bottlenecks; taking advantage of new functionality
in external libraries; or implementing new design patterns,
and on and on -- the list is limitless man!

The fact is, no code base will ever be perfect. Code will
constantly need updating and upgrading. The challenge is to
remove the old crusty bits and inject consistency everywhere
we can. That's not narcissism, that's altruism.











More information about the Python-list mailing list