<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Very nice serman, Norman. I moved from (cb unix) BTL C (1976) to C++ to Java to PHP and JavaScript to Python. I never went for the object oriented view but loved C++'s strict type checking.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I got very frustrated with the active support for Python2 and Python3 versions and vacationed</div><div class="gmail_default" style="font-family:monospace,monospace">for several years. Then Python went out of the Python 2 support business and I started using</div><div class="gmail_default" style="font-family:monospace,monospace">Python again. Over the span of all those languages Python 3 has supported almost anything</div><div class="gmail_default" style="font-family:monospace,monospace">I could think of with free downloadable modules. That has happened nowhere I have ever seen.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I also struggled with writing and supporting print functions where the variables were</div><div class="gmail_default" style="font-family:monospace,monospace">in one place and the formats for them were in another place. Python3's f-strings reduced</div><div class="gmail_default" style="font-family:monospace,monospace">my strings substantially. Now the format and variable can be defined in one place and used in lots of places.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">That is a huge help to me for documentation and support.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">That's my two cents.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks for your thoughts</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Ed Bradford</div><div class="gmail_default" style="font-family:monospace,monospace">Pflugerville, TX</div><div class="gmail_default" style="font-family:monospace,monospace"><a href="mailto:egbegb2@gmail.com">egbegb2@gmail.com</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">PS: Has anyone else but me on this list tried chatGPT generated python programs? We should</div><div class="gmail_default" style="font-family:monospace,monospace">move such a conversation elsewhere, but I simply don't know where. Email me if you</div><div class="gmail_default" style="font-family:monospace,monospace">want to start a discussion on this topic in a more appropriate place.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 6, 2023 at 2:46 PM Norman Wilson <<a href="mailto:norman@oclsc.org">norman@oclsc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At the risk of releasing more heat than light (so if you feel<br>
compelled to flame by this message, please reply just to me<br>
or to COFF, not to TUHS):<br>
<br>
The fussing here over Python reminds me very much of Unix in<br>
the 1980s.  Specifically wars over editors, and over BSD vs<br>
System V vs Research systems, and over classic vs ISO C, and<br>
over embracing vendor-specific features (CSRG and USG counting<br>
as vendors as well as Digital, SGI, Sun, et al) vs sticking<br>
to the common core.  And more generally whether any of the<br>
fussing is worth it, and whether adding stuff to Unix is<br>
progress or just pointless complication.<br>
<br>
Speaking as an old fart who no longer gets excited about this<br>
stuff except where it directly intersects something I want to<br>
do, I have concluded that nobody is entirely right and nobody<br>
is entirely wrong.  Fancy new features that are there just to<br>
be fancy are usually a bad idea, especially when they just copy<br>
something from one system to a completely different one, but<br>
sometimes they actually add something.  Sometimes something<br>
brand new is a useful addition, especially when its supplier<br>
takes the time and thought to fit cleanly into the existing<br>
ecosystem, but sometimes it turns out to be a dead end.<br>
<br>
Personal taste counts, but never as much as those of us<br>
brandishing it like to think.<br>
<br>
To take Python as an example: I started using it about fifteen<br>
years ago, mostly out of curiousity.  It grew on me, and these<br>
days I use it a lot.  It's the nearest thing to an object-<br>
oriented language that I have ever found to be usable (but I<br>
never used the original Smalltalk and suspect I'd have liked<br>
that too).  It's not what I'd use to write an OS, nor to do<br>
any sort of performance-limited program, but computers and<br>
storage are so fast these days that that rarely matters to me.<br>
<br>
Using white space to denote blocks took a little getting used<br>
to, but only a little; no more than getting used to typing<br>
if ...: instead of if (...).  The lack of a C-style for loop<br>
occasionally bothers me, but iterating over lists and sets<br>
handles most of the cases that matter, and is far less cumbersome.<br>
It's a higher-level language than C, which means it gets in the<br>
way of some things but makes a lot of other things easier.  It<br>
turns out the latter is more significant than the former for<br>
the things I do with it.<br>
<br>
The claim that Python doesn't have printf (at least since ca. 2.5,<br>
when I started using it) is just wrong:<br>
        print 'pick %d pecks of %s' % (n, fruit)<br>
is just a different spelling of<br>
        printf("pick %d pecks of %s\n", n, fruit)<br>
except that sprintf is no longer a special case (and snprintf<br>
becomes completely needless).  I like the modern<br>
        print(f'pick {n} pecks of {fruit}')<br>
even better; f strings are what pushed me from Python 2 to<br>
Python 3.<br>
<br>
I really like the way modules work in Python, except the dumbass<br>
ways you're expected to distribute a program that is broken into<br>
modules of its own.  As a low-level hacker I came up with my own<br>
way to do that (assembling them all into a single Python source<br>
file in which each module is placed as a string, evaled and<br>
inserted into the module table, and then the starting point<br>
called at the end; all using documented, stable interfaces,<br>
though they changed from 2 to 3; program actually written as<br>
a collection of individual source files, with a tool of my<br>
own--written in Python, of course--to create the single file<br>
which I can then install where I need it).<br>
<br>
I have for some years had my own hand-crafted idiosyncratic<br>
program for reading mail.  (As someone I know once said,<br>
everybody writes a mailer; it's simple and easy and makes<br>
them feel important.  But in this case I was doing it just<br>
for myself and for the fun of it.)  The first edition was<br>
written 20 years ago in C.  I rewrote it about a decade ago<br>
in Python.  It works fine; can now easily deal with on-disk<br>
or IMAP4 or POP3 mailboxes, thanks both to modules as a<br>
concept and to convenient library modules to do the hard work;<br>
and updating in the several different work and home environments<br>
where I use it no longer requires recompiling (and the source<br>
code need no longer worry about the quirks of different<br>
compilers and libraries); I just copy the single executable<br>
source-code file to the different places it needs to run.<br>
<br>
For me, Python fits into the space between shell scripts and<br>
awk on one hand, and C on the other, overlapping some of the<br>
space of each.<br>
<br>
But personal taste is relevant too.  I didn't know whether I'd<br>
like Python until I'd tried it for a few real programs (and<br>
even then it took a couple of years before I felt like I'd<br>
really figured out out to use it).  Just as I recall, about<br>
45 years ago, moving from TECO (in which I had been quite<br>
expert) to ed and later the U of T qed and quickly feeling<br>
that ed was better in nearly every way; a year or so later,<br>
trying vi for a week and giving up in disgust because it just<br>
didn't fit my idea of how screen editors should work; falling<br>
in love with jim and later sam (though not exclusively, I still<br>
use ed/qed daily) because they got the screen part just right<br>
even if their command languages weren't quite such a good match<br>
for me.<br>
<br>
And I have never cottoned on to Perl for, I suspect, the same<br>
reason I'd be really unhappy to go back to TECO.  Tastes<br>
evolve.  I bet there's a lot of stuff I did in the 1980s that<br>
I'd do differently could I have another go at it.<br>
<br>
The important thing is to try new stuff.  I haven't tried Go<br>
or Rust yet, and I should.  If you haven't given Python or<br>
Perl a good look, you should.  Sometimes new tools are<br>
useless or cumbersome, sometimes they are no better than<br>
what you've got now, but sometimes they make things easier.<br>
You won't know until you try.<br>
<br>
Here endeth today's sermon from the messy office, which I ought<br>
to be cleaning up, but preaching is more fun.<br>
<br>
Norman Wilson<br>
Toronto ON<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><font face="'courier new', monospace"><span style="font-weight:900"><div>Advice is judged by results, not by intentions.</div><div>  Cicero</div></span></font><div><br></div></div>