Is Python really a scripting language?

[Eric S. Johansson]

John Nagle wrote:
> Eric S. Johansson wrote:
>> John Nagle wrote:
>>>      Yes.  One of the basic design flaws of UNIX was that interprocess
>>> communication was originally almost nonexistent, and it's still not 
>>> all that
>>> great.  It's easy to run other programs, and easy to send command line
>>> parameters, but all you get back is a status code, plus console-type 
>>> output.
>>>
>>>      The UNIX world might have been quite different if, when you ran a
>>> subprocess, at the end you got return values for the command line
>>> parameters (argv/argc) and the environment back.  Then programs
>>> would behave more like big subroutines. 
>> not if you use pickle.  
> 
>      That assumes both programs were designed to intercommunicate that way.
> Most UNIX applications aren't.  There's no accepted standard on how
> UNIX programs should intercommunicate, other than the 1970s technology
> of piping human-readable strings around.  Yes, there are marshalling
> systems, of which Python's "Pickle" is one.  But there's no standard
> interprocess call system.  And Pickle is only a marshalling system,
> not a full IPC system.  There's no resource location system. ("Where's
> the browser process?" "Where's the database back-end?")

I apologize if this gets you a bit cranky but I think you're conflating a few 
interprocess communications issues.  I know I didn't fully articulate what I had 
been doing and I apologize.

As your description above shows, there are multiple types of interprocess 
communications.  My example shows how it's possible to make two cooperatively 
designed programs act as if they are communicating via a remote procedure call 
across a parent-child process boundary.  Yes, other marshaling systems may be 
useful across multiple language environments.  I wasn't concerned about that.  I 
had to get a job done so I used pickle.

when it comes right down to it, IPC systems are hard to do right. 
http://birrell.org/andrew/papers/ImplementingRPC.pdf is a pretty good reference 
for how to do it for our PCs.  Also, the definition of right, depends on the 
communications medium used.  For example, if the application is using pipes with 
sub processes, what I wrote is a workable implementation especially if you need 
to deal with privilege escalation.  If you're talking over sockets or some 
equivalent communications channel, then yes, you need some form of resource 
location as well as handling methods exposure and resolution on both server and 
client side.  But even if you have all of these items, you're still not out of 
the woods.  There's a fundamental issue of reliability in the face of this 
complexity.  I've written some code with psycho and, this is not meant as a slam 
against psycho, but the resource location subsystem was causing more problems 
than I care to deal with so I eliminated it from my project by hard coding 
certain essential bits of information.


> 
>      Both Gnome and OpenOffice use CORBA. But they use incompatible versions,
> and you have to have a "CORBA ORB" running for that to work.  There's
> OpenRPC, which isn't used much any more.  There's "System V IPC", which
> isn't used much.  There are XML-based systems. There's REST, JSON, and
> similar approaches.  None of these approaches ever got the kind of
> widespread use that OLE did in the Microsoft world.

All of these examples are great examples of overly complex IPC mechanisms. 
while the complexity may be necessary if you are going to handle 99% of all 
cases, the complexity makes it more difficult to document functionality in a 
comprehensible way.  complexity reduces take up because it's too much work to 
figure out and use especially if it's a one-shot job.  I believe it's fairly 
clear that a very simple IPC mechanism could handle a significant majority of 
project needs while making IPC functionality accessible to more developers.  XML 
RPC almost achieves that except for its functional call orientation.  But, I'm 
not a waste any more breath on "what ifs" because there's way too much 
technological alpha male behavior to ever build a simple common infrastructure 
component for IPC (or almost any other widely usable components for that matter).

---eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.