Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.perl
Subject: Re: perl compared to other Unix tools
Message-ID: <9592:Dec920:40:5190@kramden.acf.nyu.edu>
Date: 9 Dec 90 20:40:51 GMT
References: <1990Dec5.060300.21410@midway.uchicago.edu> <275E7B47.2EB9@tct.uucp> <STEF.90Dec7130410@zweig.exodus>
Organization: IR
Lines: 23
X-Original-Subject: a pointer for a perl compare script

Here are the three biggest things I can't really do in Perl but can do
with (some) other UNIX tools:

1. Compile some large subset of the language to portable C code.

2. Pass descriptors back and forth between programs. This is hellishly
useful for combining programs in different languages, for passing
messages securely, and for minimizing the overhead of a modular resource
controller. Practically every system in existence has some mechanism for
descriptor passing, but Perl doesn't standardize it.

3. Use signal-schedule (aka non-preemptive) threads. In various
languages I can schedule threads to execute when the program receives a
``signal''---including signals such as ``descriptor 2 is writable,''
``we have just taken control of resource x,'' etc. This makes coroutines
and multithreaded programs a joy rather than a pain to write. Different
kinds of signals are available under different UNIX variants, but Perl
could certainly standardize the basic mechanism.

If Perl had these features, my objections about portability, efficiency,
and interoperability would almost disappear.

---Dan