Re: Is Python really a scripting language?
Terry Reedy
"Ron Provost" <ron....@cox.net> wrote in message
news:009101c83c55$4ee07a00$6501a8c0@aristotle...
But here's my problem, most of my coworkers, when they see my apps and
learn that they are written in Python ask questions like, "Why would you
write that in a scripting language?" Whenever I hear a comment like that I
can feel myself boiling inside.
===================
I don't blame you. Python is an full-fledged algorithm/programming
language that was designed to *also* be used a scripting language.
oj
> "Ron Provost" <ron.lo...@cox.net> wrote in message
It depends on your definition of scripting language, I guess.
Python it byte-compiled and run in an interpreter. Much like how Java
is run, only the compilation of python scripts is usually hidden from
the user.
You could argue that python is no more of a scripting language then
Java.
Steven D'Aprano
I have repeatedly argued in the past that we do ourselves a disservice by
describing Python as an interpreted language. Python is compiled. It has
a compiler. It even has a built-in function "compile". It's just not
compiled to *machine code* -- but with even machine code often running on
a virtual machine in the CPU(s), the distinction is far less important
now than it was when Sun described Java as a compiled language despite
the lack of JIT compilers.
--
Steven
Doug Morse
one aspect of them is that they are often used to "glue" a wide variety of
other components together. perl's initial and continued success is in no
small part to all the wrappers and interfaces it has to all sorts of other
software components and applications. part of python's utility, IMHO, is the
ease with which it can be used, like perl, to glue together a lot of disparate
parts.
Donald 'Paddy' McCarthy
I'm with Doug on this. Python *is* a scripting language which is a *good*
thing. It's their perceptions of what scripting languages are capable of
that are out-of-date.
- Paddy.
Bruno Desthuilliers
<ot>top-post corrected</ot>
>>>> But here's my problem,
>>>> most of my coworkers, when they see my apps and learn that they are
>>>> written in Python ask questions like, "Why would you write that in a
>>>> scripting language?" Whenever I hear a comment like that I can feel
>>>> myself boiling inside.
> although perhaps not a part of the definition of scripting languages per se,
I still wait to see any clear, unambiguous definition of "scripting
language". Which one are you refering to here ?
(snip)
Bruno Desthuilliers
> "Ron Provost" <ron....@cox.net> wrote in message
> news:009101c83c55$4ee07a00$6501a8c0@aristotle...
> But here's my problem, most of my coworkers, when they see my apps and
> learn that they are written in Python ask questions like, "Why would you
> write that in a scripting language?"
Then ask them what's a "scripting language" exactly... or download this,
print it and put it on the wall near your desktop:
http://apipes.blogspot.com/2005/01/choose-python.html
> Whenever I hear a comment like that I
> can feel myself boiling inside.
As far as I'm concerned, anyone (I mean, anyone pretending to be a
programmer) being ignorant enough to ask such a question ranks high in
my bozo list. Don't waste time with bozos.
>
> I don't blame you. Python is an full-fledged algorithm/programming
> language that was designed to *also* be used a scripting language.
Indeed.
Marco Mariani
> As far as I'm concerned, anyone (I mean, anyone pretending to be a
> programmer) being ignorant enough to ask such a question ranks high in
> my bozo list. Don't waste time with bozos.
Alan Kay said it well enough without using words like "pretending",
"ignorant" and "bozo" :)
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273
It's worth a read.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>> As far as I'm concerned, anyone (I mean, anyone pretending to be a
>> programmer) being ignorant enough to ask such a question ranks high in
>> my bozo list. Don't waste time with bozos.
>
>
> Alan Kay said it well enough without using words like "pretending",
> "ignorant" and "bozo" :)
Probably. But I do like using these words, and having the opportunity to
use them three in a same post really made me happy !-)
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273
>
> It's worth a read.
Whenever I'll get a couple minutes.
Neil Cerutti
> I have repeatedly argued in the past that we do ourselves a
> disservice by describing Python as an interpreted language.
>
> Python is compiled. It has a compiler. It even has a built-in
> function "compile". It's just not compiled to *machine code* --
> but with even machine code often running on a virtual machine
> in the CPU(s), the distinction is far less important now than
> it was when Sun described Java as a compiled language despite
> the lack of JIT compilers.
When folks say Python is an interpreted language I think they
mean it informally--they just mean you have to run an interpreter
to execute it. *How* it's translated is irrelevent to the
*informal* meaning.
And I'd further argue that the informal meaning is the only one
that makes any sense.
Formally:
>>> hasattr(Language, 'iterpreted')
False
>>> hasattr(Implementation, 'interpreted')
True
;-)
--
Neil Cerutti
Bruno Desthuilliers
> On 2007-12-13, Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
>> I have repeatedly argued in the past that we do ourselves a
>> disservice by describing Python as an interpreted language.
>>
>> Python is compiled. It has a compiler. It even has a built-in
>> function "compile". It's just not compiled to *machine code* --
>> but with even machine code often running on a virtual machine
>> in the CPU(s), the distinction is far less important now than
>> it was when Sun described Java as a compiled language despite
>> the lack of JIT compilers.
>
> When folks say Python is an interpreted language I think they
> mean it informally--they just mean you have to run an interpreter
> to execute it.
How often do you hear that Java is "an interpreted language" ?
Neil Cerutti
The difference is the p-code factor. Python's p-code is
(generally) internal only. We could fool more people if we forced
them to create .pyc files before executing the code. ;-)
--
Neil Cerutti
Paul Rudin
> On 2007-12-13, Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
>> I have repeatedly argued in the past that we do ourselves a
>> disservice by describing Python as an interpreted language.
>>
>> Python is compiled. It has a compiler. It even has a built-in
>> function "compile". It's just not compiled to *machine code* --
>> but with even machine code often running on a virtual machine
>> in the CPU(s), the distinction is far less important now than
>> it was when Sun described Java as a compiled language despite
>> the lack of JIT compilers.
>
> When folks say Python is an interpreted language I think they
> mean it informally--they just mean you have to run an interpreter
> to execute it. *How* it's translated is irrelevent to the
> *informal* meaning.
>
> And I'd further argue that the informal meaning is the only one
> that makes any sense.
>
Many people still talk about lisp as "interpreted" despite the fact
that there have been compilers (that compile to machine code) for
decades.
I'm not sure it's really a property of a language, rather of an
implementation.
sturlamolden
cybersource.com.au> wrote:
> I have repeatedly argued in the past that we do ourselves a disservice by
> describing Python as an interpreted language. Python is compiled. It has
> a compiler. It even has a built-in function "compile".
Python is compiled to bytecode. Python's bytecode is interpreted. Does
that make Python interpreted or compiled? I could not care less.
The terms 'scripting language' and 'interpreted language' have
somewhat different meanings. 'Scripting language' typically means a
language used for one of:
- Shell scripts
- Automation macros in a larger application
- Code embedded in a web page
- CGI
Python, Perl, Lisp and Visual Basic are certainly used as scripting
languages in some settings. But that does not mean it is the only
thing they can be used for. On the other hand, JavaScript and Bourne
shell have little use except as scripting languages.
Steven D'Aprano
> On 13 Des, 02:19, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>
>> I have repeatedly argued in the past that we do ourselves a disservice
>> by describing Python as an interpreted language. Python is compiled. It
>> has a compiler. It even has a built-in function "compile".
>
> Python is compiled to bytecode. Python's bytecode is interpreted.
If you want to be pedantic, machine-code is interpreted by the CPU.
> Does
> that make Python interpreted or compiled? I could not care less.
Sadly, many people who shouldn't, do. Instead of asking "Is Python fast
*enough* for my task?" they ask "Is Python fast?", and then compound it
by assuming that since it's "interpreted" it obviously must be slow.
--
Steven.
greg
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273
An interesting quote from that:
> If you combine Simula and Lisp—Lisp didn’t have data structures, it had
> instances of objects—you would have a dynamic type system that would
> give you the range of expression you need.
Sounds like AK is talking about Python here and doesn't know it...
--
Greg
Chris Mellon
> On Thu, 13 Dec 2007 10:43:18 +0100, Bruno Desthuilliers
> <bruno.42.de...@wtf.websiteburo.oops.com> declaimed the
> following in comp.lang.python:
>
> >
> > I still wait to see any clear, unambiguous definition of "scripting
> > language". Which one are you refering to here ?
> >
> bash, etc.) I can think of only ONE language that I'd consider a true
> "scripting language"... ARexx on the Amiga, as it could "address" any
> application that created a compatible ARexx message port.
>
> This meant one could write ARexx programs that could, by changing
> the "address", send application native commands to an application,
> retrieve returned data, and then send that data to a second application
> using its native commands.
>
> No hassle with subprocess spawning or pipe I/O blocking...
>
Applescript works in a very similar way.
John Nagle
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.
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"
John Nagle
mensa...@aol.com
> "Ron Provost" <ron.lo...@cox.net> wrote in message
When you buy a new car, which is more important, the styling
or what's under the hood?
Take, for example, Microsoft's slick new language F#.
<Wikipedia>
F# (pronounced F Sharp) is a multi-paradigm programming language,
targeting the .NET Framework, that encompasses functional programming
as well as imperative object-oriented programming disciplines.
It is a variant of ML and is largely compatible with the OCaml
implementation.
</Wikipedia>
Sounds pretty sexy, eh? And programs compile to .exe files, none
of that byte-code interpretation nonsense.
But you would never buy a car without taking a test drive, right?
So we can fire up the F# Interactive (Console) and put it in gear.
> #time;;
--> Timing now on
> open Math;;
Time 0.046875
> let mutable Z = 0I;;
val mutable Z : bigint
Time 0.156250
> Z <- Z + (BigInt.pow 3I 123295I) * (BigInt.pow 2I 0I);;
val it : unit = ()
Time 0.515625
>
About a half second to compute a number with 58827 decimal digits.
OTOH, that was only the first of 123296 terms. The time to compute
the full sequence is 0.515625*123296 seconds or 17.65 hours.
If it takes that long for a compiled .exe to run, just imagine how
long a lowly, byte-code interpreted language would take!
But wait...
...we don't have to imagine, we can take the Python out for a test
drive also.
>>> import collatz_functions
>>> import time
>>> sv = collatz_functions.build_sv(19,19,1000000,1541095)
>>> def Big_Z(sv):
Z = 0
e2 = 0
e3 = len(sv) - 1
t0 = time.time()
for v in sv:
Z += 3**e3 * 2**e2
e3 -= 1
e2 += v
t1 = time.time()
print (t1-t0)/60,'minutes'
>>> Big_Z(sv)
25.6775999983 minutes
Hold on...
That's for the whole sequence, not a single term!
25.67 MINUTES compared to 17.65 HOURS!
So, sure, some languages compile to .exe programs.
In the trade, we call that "polishing a turd".
Chris Mellon
> On Dec 11, 10:34 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
> > "Ron Provost" <ron.lo...@cox.net> wrote in message
> >
> > news:009101c83c55$4ee07a00$6501a8c0@aristotle...
> > But here's my problem, most of my coworkers, when they see my apps and
> > learn that they are written in Python ask questions like, "Why would you
> > write that in a scripting language?" Whenever I hear a comment like that I
> > can feel myself boiling inside.
> > ===================
> >
> > I don't blame you. Python is an full-fledged algorithm/programming
> > language that was designed to *also* be used a scripting language.
>
> When you buy a new car, which is more important, the styling
> or what's under the hood?
>
> That's for the whole sequence, not a single term!
>
> 25.67 MINUTES compared to 17.65 HOURS!
>
> So, sure, some languages compile to .exe programs.
>
> In the trade, we call that "polishing a turd".
>
While I agree with the sentiment, surely this can't be a good example
of F#s general performance? I would expect .NET code to smoke stock
(non-Psycoed) Python in this benchmark.
mensa...@aol.com
> On Dec 14, 2007 2:09 PM, mensana...@aol.com <mensana...@aol.com> wrote:
>
>
>
> > On Dec 11, 10:34 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
> > > "Ron Provost" <ron.lo...@cox.net> wrote in message
>
> > >news:009101c83c55$4ee07a00$6501a8c0@aristotle...
> > > But here's my problem, most of my coworkers, when they see my apps and
> > > learn that they are written in Python ask questions like, "Why would you
> > > write that in a scripting language?" Whenever I hear a comment like that I
> > > can feel myself boiling inside.
> > > ===================
>
> > > I don't blame you. Python is an full-fledged algorithm/programming
> > > language that was designed to *also* be used a scripting language.
>
> > When you buy a new car, which is more important, the styling
> > or what's under the hood?
>
> <snip>
>
> > That's for the whole sequence, not a single term!
>
> > 25.67 MINUTES compared to 17.65 HOURS!
>
> > So, sure, some languages compile to .exe programs.
>
> > In the trade, we call that "polishing a turd".
>
> While I agree with the sentiment, surely this can't be a good example
> of F#s general performance?
Of course. They example was deliberately chosen to make
F#'s BigInt library look as bad as possible.
> I would expect .NET code to smoke stock
> (non-Psycoed) Python in this benchmark.
Probably. It just so happens that the example chosen
is typical of _my_ number theory research and I was
toying with the idea of converting my Collatz Conjecture
function library to F#.
And that would take a lot of work since F# doesn't have
anywhere near the functionality of gmpy. There isn't
even a BigInt.mod function for cryin' out loud, let alone
stuff like GCD or modular inverse, critical to my research.
Sure, I could write my own Extended Euclidean Algorithm,
but now that I now that F# is just a Volkswagen with a
fiberglass shell that looks like a Ferrari, there isn't
much point, eh?
And don't even get me started about the stupid stuff,
like having TWO different type of Big Rationals. One's
more efficient than the other, they say. So why two?
The less efficient one has functions not implemented
in the other. And F# is strongly typed, so you can't
use BigRational methods with BigNum types. And they
have all sorts of conversion methods for to/from ints,
strings, bigints, etc. Guess which conversions they
don't have? BigRational <-> BigNum, of course.
MAybe I'll check it out again in the future after it
has gone through several revisions.
Martin P. Hellwig
prefer (java |.net). I can always say, oh no problem there is a python
interpreter for that. Python can be used as a scripting language, yes,
also OO wise or procedural and whatever more. So for me it is quite
logical to use a language that gives me the advantage to go from quick
and dirty to full fledged unit tested programming in whatever
programming paradigm is hot these days. Python might still lack a bit on
the GUI side, but I believe this is not a problem of python but mere to
the interpretation of GUI. GUI is still an art in it's early stage.
Python is in my view a liberal programming language, it has power,
simplicity while containing flexibility and it doesn't preach whatever
programming paradigm. So yes Python can shoot you in the foot in ways
you could never imagined before, but remember it is you who held the
barrel that way, and remind yourself, with other languages you probably
weren't able to build the gun anyway. So which of these is better is
your choice.
--
mph
Steven D'Aprano
> 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.
sturlamolden
cybersource.com.au> wrote:
> oowriter --print some.doc | ps2pdf
> encapsulate, encapsulate. Unfortunately, apps using inter-app
> communication tend to do the opposite.
That pipe is a form of IPC as well.
Marc 'BlackJack' Rintsch
> 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
Can be done this way… ::
soffice -invisible macro:///Standard.MyConversions.SaveAsPDF(some.doc)
…if you write a small macro in StarBasic for the conversion.
Full story:
http://www.xml.com/pub/a/2006/01/11/from-microsoft-to-openoffice.html
Ciao,
Marc 'BlackJack' Rintsch
Piet van Oostrum
>SD> I have repeatedly argued in the past that we do ourselves a disservice by
>SD> describing Python as an interpreted language. Python is compiled. It has
>SD> a compiler. It even has a built-in function "compile". It's just not
>SD> compiled to *machine code* -- but with even machine code often running on
>SD> a virtual machine in the CPU(s), the distinction is far less important
>SD> now than it was when Sun described Java as a compiled language despite
>SD> the lack of JIT compilers.
The above is not a description of the language but of an implementation.
Albeit the currently major implementation. But it could be that in the
future python would be compiled to machine code. That wouldn't change the
language.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org
Piet van Oostrum
>JN> There's CORBA, for example, and in theory
>JN> you can script OpenOffice and Gnome via CORBA. But nobody does that.
>JN> Exercise: write a Python program to convert a ".doc" file to a ".pdf"
>JN> file by invoking OpenOffice via CORBA. At least in theory, this is
>JN> possible. All the necessary parts supposedly exist. Somebody
>JN> tried back in 2003, but gave up. See
>JN> "http://mail.python.org/pipermail/python-list/2003-April/198094.html"
[Nitpicking] Scripting Openoffice.org (!) is with UNO, not Corba.
Eric S. Johansson
> 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.
not if you use pickle. the example below is not complete and I need to fix it
to not raise privileges if name is None but it is complete enough to give you an
idea. the parent uses spawn_sub to send data to/from child. child uses
read_input/write_output to move data from/to the parent. I should convert it to
something like json to make it possible to work with other languages.
class process_handler (object):
def read_input (self):
"""get the input from standard and can convert to Python
object"""
pickle_input = sys.stdin.read()
real_object = pickle.loads(pickle_input)
return real_object
def write_output (self, real_object, err_object = None):
""" errors to standard error, output to standard out, objects
in pickled form"""
pickled_error = pickle.dumps(err_object)
sys.stderr.write(pickled_error)
pickled_output = pickle.dumps(real_object)
sys.stdout.write(pickled_output)
def spawn_sub(self, cmd_list,stuff_in, run_as=None):
"""command_list is just that, a list of the command and all of its
arguments.
stuff_in is the string sent to the sub process via standard in
stuff_out is the string returned from the sub process via standard out
error_stuff is the string returned from standard error.
stuff_out and error_stuff are returned as a tuple
run_as is the user name you want to run as. This uses a trick with
sudo to enable privilege escalation
this is an example of a bad escalation specification in
sudoers. It's sometimes bad because it doesn't restrict
who can use the command. If you are trying to run a
program as a common but different user (such as www-data
because you need to share a database with a Web server, the
badness is measured in terms of what data said program can
change or reveal. If the access cannot be exploited, then
they should be okay. Unfortunately, in almost every
circumstance where privilege escalation techniques are
useful, there is an exploit waiting to happen.
be careful.
ALL ALL = (www-data) NOPASSWD: /home/esj/vacation_scan.py
"""
# syslog.syslog("subprocess args %s"%str(cmd_list))
p = subprocess.Popen(cmd_list, shell=False, bufsize=4000,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
close_fds=True)
# always pickle what passes through even if it is a None
pickle_in = pickle.dumps(stuff_in)
(pickled_output, pickled_error) = p.communicate(pickle_in)
stuff_output = pickle.loads(pickled_output)
error_stuff = pickle.loads(pickled_error)
# syslog.syslog(" stuff_output %s, error_stuff %s"%( stuff_output,
error_stuff))
return (stuff_output, error_stuff)
--
Speech-recognition in use. It makes mistakes, I correct some.
John Nagle
> 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.
>
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?")
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.
John Nagle
Eric S. Johansson
> 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
MonkeeSage
Since F# is a caml derivative, you may want to look at OCaml. Though,
I've never used OCaml for any kind of heavy number-crunching, so maybe
it has even worse library support; can't say. Ps. The two types are
probably for boxed and unboxed versions, q.v. this article, about half-
way down: http://msdn.microsoft.com/msdnmag/issues/1200/dotnet/
Regards,
Jordan