Python Is Really Middleware

[Terry Reedy]

"Tim Daneliuk" <tundra at tundraware.com> wrote in message
news:3B667EBA.DA6C298 at tundraware.com...

an interesting essay with many things to think about.  Thanks for
sharing your experience-based thoughts with us.
...
> - How do we write more correct, maintainable, code *faster*?

If Python does not enable this, no special reason it should expand.
If it actually does, for many programmers who give it a try, then it
seems to this Darwinian that the resulting competitice advantage
should lead to an almost inevitable growth  -- or is Dilbert more true
to life than I would like to believe?

> (For those of you Neo-Marxists in the audience who think that
"Information
> Just Wants To Be FREE", I should mention that the survivability of
> any technology has always been primarily a function of commercial
adoption,
> at least in the long run.  How many people write in COBOL today?
(Many!)
> How many program in Eiffel? Snobol? ML?  Oberon?  Haskell?  'Nuff
said.
> Economic Reality trumps Bad Collectivist Theory every time.
Thank-You,
> Adam Smith.)

As a Smithian hippie, I think the better adage is "Entertainment
information want to be free", which is to say that people like to
share non-critical information as part of their social interaction and
play.  On the other hand, several people have noted that Python being
free is a barrier to commercial acceptance.  As a free user, I would
like to see more commercial exploitation without enclosure.  (Software
and information in general does *NOT* suffer from the tragedy of the
commons.)  One selling point 'should' be that the 100,000 (or
whatever) 'free' users help research, develop, and test the polished
versions bundled with paid-for support services.

> But, there's a rub.  When you buy Middleware, you are
> (if you did your homework right) removing a large part of the
> dependency the apps have on networking, OS, and so forth.
> BUT, you are marrying the Middleware vendor until that
> application goes away.

So part of the pitch of Python-as-Middleware vendors 'should' be that
because Python is open rather than proprietary, there can/are/will be
multiple such vendors, and so clients will never be totally dependent
on any one such vendor.

> I worry about one thing and one thing only in the Python world.  It
> is something I have witnessed in *every* new technology I've
> ever seen.  Python is dangerously close to becoming a victim of
> Feeping Creaturism - not so much In Fact, but rather in this
community's
> mindset of forever wanting to fiddle one more feature into the
> language

One thing I like about Python is that it, like C, is currently small
enough to be kept in mind all at once, in a way that C++, for
instance,  is not.  I would not like this to change, so I consider
simplification vs. complexification to be one criterion for evaluation
proposals.  Of course, one proposal can do both, depending on
viewpoint.

> I, for one, would like to see a date picked for a permanent
moratorium
> on the language proper,

All the changes in the last year have been discussed for years.  So I
expect/hope that in another year we will see something of a plateau
again with Python2final.

> after which, only bug fixes and new modules  could be added.

You are free to sponsor such releases, along the lines of 2.0.1 and
2.1.1 but with new modules, of any version *you* want to stabilize ,
for an many years as you think it useful.  Unless someone offers to
*pay* Guido enough to persuade him to do this, there is no reason *he*
should.

>  After that date, language changes would have to be
> part of some new language

Consider Python3 to be a new language, if you want.  Or even Python
2.2.  I personally prefer to move,when I want, from one language I
like to another that is only slightly different in ways I see as
improvement, than to an unrelated language.

I think it worth noting that 2.2 without 'import future' is arguably
more compatible with 2.1 than most versions of, for instance, 'C' have
been with each other.  ['Version of  C' = defacto language of
particular compiler on  particular platform with particular settings.]
In this sense alone, you are correct: Python is middleware that has
already successfully hidden some annoying variations in the underlying
platforms it runs on.

Terry J. Reedy