At the risk of releasing more heat than light (so if you feel
compelled to flame by this message, please reply just to me
or to COFF, not to TUHS):

The fussing here over Python reminds me very much of Unix in
the 1980s.  Specifically wars over editors, and over BSD vs
System V vs Research systems, and over classic vs ISO C, and
over embracing vendor-specific features (CSRG and USG counting
as vendors as well as Digital, SGI, Sun, et al) vs sticking
to the common core.  And more generally whether any of the
fussing is worth it, and whether adding stuff to Unix is
progress or just pointless complication.

Speaking as an old fart who no longer gets excited about this
stuff except where it directly intersects something I want to
do, I have concluded that nobody is entirely right and nobody
is entirely wrong.  Fancy new features that are there just to
be fancy are usually a bad idea, especially when they just copy
something from one system to a completely different one, but
sometimes they actually add something.  Sometimes something
brand new is a useful addition, especially when its supplier
takes the time and thought to fit cleanly into the existing
ecosystem, but sometimes it turns out to be a dead end.

Personal taste counts, but never as much as those of us
brandishing it like to think.

To take Python as an example: I started using it about fifteen
years ago, mostly out of curiousity.  It grew on me, and these
days I use it a lot.  It's the nearest thing to an object-
oriented language that I have ever found to be usable (but I
never used the original Smalltalk and suspect I'd have liked
that too).  It's not what I'd use to write an OS, nor to do
any sort of performance-limited program, but computers and
storage are so fast these days that that rarely matters to me.

Using white space to denote blocks took a little getting used
to, but only a little; no more than getting used to typing
if ...: instead of if (...).  The lack of a C-style for loop
occasionally bothers me, but iterating over lists and sets
handles most of the cases that matter, and is far less cumbersome.
It's a higher-level language than C, which means it gets in the
way of some things but makes a lot of other things easier.  It
turns out the latter is more significant than the former for
the things I do with it.

The claim that Python doesn't have printf (at least since ca. 2.5,
when I started using it) is just wrong:
        print 'pick %d pecks of %s' % (n, fruit)
is just a different spelling of
        printf("pick %d pecks of %s\n", n, fruit)
except that sprintf is no longer a special case (and snprintf
becomes completely needless).  I like the modern
        print(f'pick {n} pecks of {fruit}')
even better; f strings are what pushed me from Python 2 to
Python 3.

I really like the way modules work in Python, except the dumbass
ways you're expected to distribute a program that is broken into
modules of its own.  As a low-level hacker I came up with my own
way to do that (assembling them all into a single Python source
file in which each module is placed as a string, evaled and
inserted into the module table, and then the starting point
called at the end; all using documented, stable interfaces,
though they changed from 2 to 3; program actually written as
a collection of individual source files, with a tool of my
own--written in Python, of course--to create the single file
which I can then install where I need it).

I have for some years had my own hand-crafted idiosyncratic
program for reading mail.  (As someone I know once said,
everybody writes a mailer; it's simple and easy and makes
them feel important.  But in this case I was doing it just
for myself and for the fun of it.)  The first edition was
written 20 years ago in C.  I rewrote it about a decade ago
in Python.  It works fine; can now easily deal with on-disk
or IMAP4 or POP3 mailboxes, thanks both to modules as a
concept and to convenient library modules to do the hard work;
and updating in the several different work and home environments
where I use it no longer requires recompiling (and the source
code need no longer worry about the quirks of different
compilers and libraries); I just copy the single executable
source-code file to the different places it needs to run.

For me, Python fits into the space between shell scripts and
awk on one hand, and C on the other, overlapping some of the
space of each.

But personal taste is relevant too.  I didn't know whether I'd
like Python until I'd tried it for a few real programs (and
even then it took a couple of years before I felt like I'd
really figured out out to use it).  Just as I recall, about
45 years ago, moving from TECO (in which I had been quite
expert) to ed and later the U of T qed and quickly feeling
that ed was better in nearly every way; a year or so later,
trying vi for a week and giving up in disgust because it just
didn't fit my idea of how screen editors should work; falling
in love with jim and later sam (though not exclusively, I still
use ed/qed daily) because they got the screen part just right
even if their command languages weren't quite such a good match
for me.

And I have never cottoned on to Perl for, I suspect, the same
reason I'd be really unhappy to go back to TECO.  Tastes
evolve.  I bet there's a lot of stuff I did in the 1980s that
I'd do differently could I have another go at it.

The important thing is to try new stuff.  I haven't tried Go
or Rust yet, and I should.  If you haven't given Python or
Perl a good look, you should.  Sometimes new tools are
useless or cumbersome, sometimes they are no better than
what you've got now, but sometimes they make things easier.
You won't know until you try.

Here endeth today's sermon from the messy office, which I ought
to be cleaning up, but preaching is more fun.

Norman Wilson
Toronto ON