Is Python really a scripting language?

[Steven D'Aprano]

On Fri, 14 Dec 2007 10:26:54 -0800, 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.  But all you get back is a status
> code, so running programs from a "script" tends to be a somewhat "blind"
> one-way process.

I'm not entirely convinced that's a flaw. True, it makes certain things 
more difficult, but in my opinion it has one *major* advantage that 
outweighs that a thousand times: it encourages developers to build small 
programs that do one thing well, rather than huge everything-including-
the-kitchen-sink monstrosities. When you're limited to a status code plus 
stdout, the tendency is write simple programs that behave more or less 
like a function: do one thing with the minimum number of options, using 
(conceptually) a single entry point and a single exit point. Because it 
is hard to expose the internal workings of your program, encapsulation 
follows naturally.

When you have rich inter-application communication, there is (it seems to 
me) a tendency to write programs that behave more or less like BASIC with 
goto: you can jump in to and out of them anywhere. Because it is easier 
to expose the internal workings of your program, encapsulation is harder.

(Naturally all of the above are generalizations. One can write monstrous 
Unix programs too, and I need give no examples as they are so well known.)


>      The UNIX world now has various forms of interprocess communication,
> but none of them is as pervasive as Microsoft OLE and its successors on
> Microsoft platforms.
> 
>      There's CORBA, for example, and in theory
> you can script OpenOffice and Gnome via CORBA.  But nobody does that.
> Exercise: write a Python program to convert a ".doc" file to a ".pdf"
> file by invoking OpenOffice via CORBA.  At least in theory, this is
> possible.  All the necessary parts supposedly exist.  Somebody tried
> back in 2003, but gave up. See
> "http://mail.python.org/pipermail/python-list/2003-April/198094.html"


That thread contains two posts. There's no indication that the person 
gave up, or if he did, why he gave up.

In any case, I would say that your exercise is the Wrong Way to go about 
it. A task as simple as "produce PDF output from this file" shouldn't 
need access to the internals of the OpenOffice GUI application. The Right 
Way (in some Ideal World where OO wasn't so stupid) would be some 
variation of:

oowriter --print some.doc | ps2pdf

That is, tell OO to render the document into Postfix, which is then sent 
to another program to convert it into a PDF.

Even for more complicated tasks, the Right Way is: encapsulate, 
encapsulate, encapsulate. Unfortunately, apps using inter-app 
communication tend to do the opposite.


-- 
Steven.