Python Is Really Middleware

[Tim Daneliuk]

Peter Mayne wrote:
<SNIP>

> This seems to be the core of your argument, but I don't see this at all. I
> gather there aren't too many people here who think that one language, even
> Python, is good for everything. Surely the best place to abstract a system
> is in the libraries and the run-time.

No, I don't think Python is good for *everything*.  Recall that I am
describing middleware in the context of its use as an enabler for
*applications logic*.  My central argument is this (and perhaps I
should have made it clearer, but is *was* 4:30am when I wrote this ;):

1) Modern systems allow a far greater and far more complete level of 
   abstraction (away from the underlying infrastructure) than ever
   before because "throwing hardware/memory/bandwidth at the problem"
   is now economically rational.

2) This abstraction layer or 'middleware' needs to all (or most) of
   The Things Applications Need To Do in a consistently packaged
   and deployed manner.

3) Python qualifies here, not because of the language itself, per se,
   but because of the "Batteries Included" standardization of modules
   packaged with each release.

4) Python (and Perl) are the only rational choices here (at the moment)
   because Java, C#, VB, are under *vendor control* which immediately
   biases how they will abstract the application away from the
   infrastructure.  It is in neither Microsoft or Sun's interests to
   create integration harnesses which make it easy to jump back and 
   forth from, say, J2EE to .NET.

Whether the enabling is literally "in the language" or in its libraries
is a fine point of implementation.  The larger point is that the 
language *as deployed* has this high level of integration and abstraction
to offer applications developers.


> 
> .Net is the most recent popular example of this. Given the library support,
> it doesn't matter what language you use, and you can therefore use the best
> language for the task at hand. With .Net, you can use Fortran for the
> numeric modules, COBOL for the "traditional" database heavy lifting modules,
> and Python.Net to tie those modules together. (Yes, all three of those are
> or will be available for .Net.) You can even subclass your Fortran classes
> using Eiffel.Net, and subclass those with COBOL, whereas CPython can only be
> subclassed by, or from, more CPython. (Or C extensions, which is probably
> beyond the scope of this epistle.) Can someone please point out why being
> restricted to CPython is better here?

Because the CLR and JITs which are part of .NET force you into a Win32
operational runtime.  Marrying your vendor is bad.  Marrying their operating
system for life is worse - just ask all the companies who are now being
forced to pay outrageous fees to Microsoft to license additional copies
of their backleveled products like Win95 (because the company apps are not Win98
compatible and are so widely deployed that updating 100,000+ users to
98/ME/2000 Pro is not feasible).  This is not a shot a Microsoft, BTW,
this behavior is well established among all the major vendors like
IBM, Sun, HP, and so on.  They sell you first one cheap, and once you're
addicted, charge through the nose forever.

> 
> Note that .Net is *not* offering a core language, but a Common Language
> Runtime (CLR) upon which you can layer any language you like, and all of the
> languages will interact happily with each other. (I'm not recommending .Net
> in this post, just using it as a currently widely known example. Nor am I
> arguing that Microsoft may or may not be leading you up a garden path - I'm
> just using it as a technical example.)

.NET is an *architecture*, it is not yet an implementation. Nothing from
Microsoft indicates *any* interest on their part on realizing .NET on
anything other than Win32 and Win64 systems.  .NET is NOT vendor neutral
(and speaking as a MS stockholder, it should not be vendor neutral, it
should be a strategic hammer for Microsoft).

> 
> Python may be a middleware language in the sense that it is a language
> suitable for many things that it is suitable for (!), but it is not
> necessarily suitable for interfacing with other middleware. Another .Net
> example: you can write a C# (or VB, or whatever other language you feel like
> using) WebServer class, run the right utility on it, or just point your
> browser at it, and out pops the SDL for that class. Feed that SDL into
> another utility, and out pops a SOAP client stub: instant language
> independent client/server code. The run-time transparently handles
> SOAP/HTTP/SSL/et al, so you get exactly the same middleware no matter what
> language you started with. How easy is it to do this with CPython (as
> opposed to Python.Net, obviously 8-)?


There's no question that Microsoft is positioning .NET as middleware for
integrating the front-, back-, and middle- of every Enterprise.  Your example
illustrates, at least in principle, its technical virtue.  But,
having been a tech exec, lemme tell you, anyone who goes down this
road exclusively will really regret it.  Middleware owned by the OS and systems
vendor is a Trojan Horse for account control.  As I said in the original
essay (in so many words, anyway) - the distribution topology and 'glue'
that binds a distributed enterprise together, *must* be isolated from
the underlying vendor architectures or you will forever have to
play "Mother May I" with Balmer, McNealy, Gerstner, Ellison, et all -
and they don't play nice.

> 
<SNIP>
> 
> > But, Python has one, very important commercial advantage.  It's
> > not owned by a vendor.
> 
> An advantage over Microsoft and Sun, maybe, but there are other languages
> that aren't owned by a vendor either. Whether you and I prefer a language
> that we can actually read, rather than one that looks like modem line noise,
> doesn't seem (so far) to be a commercial ad
> Much of the epistle could as easily apply to Perl rather than Python, and
> the rest could be summed up as "I like Python because of the usual reasons".
> Not that there's anything wrong with that. 8-)
> 


Remember, this is a multipart argument:

Implentation Completeness +
Vendor Neutrality +
Fitness For Applications Needs +
Multi-Platform +
Ease Of Coding +
Ease Of Maintenance +
Fitness For Large Applications Development

= "Applications Middleware"

I specifically avoided getting into a Python vs (Perl, Eiffel, ML, ...)
argument because that's pointless.  I will claim this, though -
of the extant candidates language implementions/packagings,
only Python meets the *all* the critera above.  Java and C# belong to
vendors.  Perl is not as completely packaged as Python, is not as productive
to code in, and is harder to maintain. C is unfit for large applications
programs.  C++ is unfit for everything ;)  Currently, the only thing that
bodes badly for Python is its performance, but this can be solved by
writing C subroutines and in any case, I expect we'll see very good
Python native code compilers (or JITs)  not too long from now.


> Some trivia...
> 
> >
> > Even the original 'sockets' implementation at Berkeley
> > had this in mind - the code has provision (never well/completely
> > implemented) for protocols other than AF_UNIX and AF_INET.  In
> > principle, we should have seen AF_SNA...
> 
> Well, AF_DECnet certainly exists, and I have no reason to believe that it
> wasn't well implemented.

That's interesting - I wonder how many installations actually still use this
today...

> 
> > But, for most (systems) things, 'C' is a fine choice.  I've done
> everything
> > from real-time kernel work to OS utilities in 'C'.
> 
> A fine choice compared to what? There seems to be an on-going misconception
> that a "low-level" language such as C is required to do "system" things. At
> least one OS has been written in Modula-2, for instance. The design of VMS
> means that you can write system code in any language you like (MONITOR was
> written in PL/I, and the DEC Pascal variant was very nice for doing system
> stuff), or indeed, any number of languages in a single executable.
> 
> Although arguably lower-level than C, I would choose BLISS (typeless, no
> implicit derefencing so no distinction between lvalues and rvalues, an
> integrated macro facility that puts the C preprocessor to shame) over C
> every time. Sadly, there isn't the choice these days.
> 
> Sadly again, popularity ("dominance") and excellence seem to be inversely
> related, but I don't need to say that in this newsgroup. 8-)


But "fitness" for a task isn't just about the technology details.  It's
much moreso about commercial viability (which is at the heart of my Python
pitch).  'C' won the day because of the relative ease of getting it on to
new machine architectures, thereby creating a growing pool of 'C' programmers.
Companies do what works, not necessarily what is technically optimal.
Languages like PL/I and BLISS, no matter how elegant technically, failed
to garner the *wide* commercial adoption needed for dominance (even though
both DEC and IBM promoted PL/I heartily). 

> > - Their [Windows] OS core is so UI centric, it is doubtful that it can
> easily
> >   really make the jump to being a serious back-room large-scale
> >   contender.
> 
> No. It has been noted that the Windows NT core is remarkably like VMS, and
> serious, back-room, and large-scale are all phrases that have been applied
> to VMS. (It has also been noted that "remarkably" may be a remarkable
> understatement here. 8-) What *is* UI centric is the Win32 API which sits on
> top of the core, and this may or may not be scaleable.

Yes, Cutler brought all his Old Tricks with him from DEC to MS.  And, yes,
Win32 should have been an enterprise class OS.  But, no, its not, because Gates was
(and is, so far as I can determine sitting here in the Peanut Gallery) desktop 
and end-user centric in his world-view.  The Enterprise people at MS have been 
fighting for almost a decade to get the Powers That Be to accept the 
world as heterogeneous and that the back room is very different than the 
desktop in many big ways.  

Instead, MS conciously chose to integrate the UI crap into the kernel of NT
to get the thing to perform even moderately well.  Cutler fought this tooth 
and nail with Gates and lost the battle when Gates more-or-less forced it
to be done (see "Showstopper" by Zachary for some of the details).  Today's
Win32 systems blur the line considerably between what is 'kernel' and what is
'UI' support.

Now, all of a sudden, they've got Enterprise Religion and Win32 is morphing
into an "Enterprise Class Operating System", with .NET as the integration
harness.  I don't blame them for trying to market their way out of the
situation they're in (the DOJ pointing guns at their head for actually being
successful, the sea-change brought upon them by the Internet, the declining
role of PCs, the Linux/Open Source threat, the ascendent role of PDAs...),
 but Win2K as an enterprise platform... I don't buy it, but I guess I'm 
willing to have it proven to me.

In the mean time write in Python, C, and Perl as needed, define and control
your own enterprise architectures, and make the vendors beg for your business...


------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com