Subject: Use PERL rather than C for system commands?
From: tim@pokey.cs.caltech.edu (Timothy L. Kay)
To: linux-activists@joker.cs.hut.fi
Date: Wed, 15 Jan 92 22:08:25 -0800
I've been following the Linux discussion with great interest, and I
hope to download a copy and try it as soon as I have time.
I'd like to make a suggestion to the activists group. The suggestion
goes against the grain of typical Unix system administrator
philosophy, but I think the suggestion warrants serious consideration.
Here is my suggestion.
It seems to me that the language PERL is ideal for implementing many
of the pieces that are currently missing from Linux. For example,
init, getty, login, shutdown, halt, cron, inetd, etc. could very
easily be written in PERL rather than C. Most OS-support programs
(including the ones mentioned previously) are not time critical. They
run very infrequently, and the performance degradation (if there is
any) should be inconsequential.
There are several advantages to using PERL rather than C.
First of all, programs would take up much less disk space and RAM. It
is true that the PERL executable must be in RAM in order to run a PERL
program, but only one copy ever need be in RAM at any time, and I
think the savings elsewhere will more than make up the difference.
(On my workstation, the PERL .text section is about 4 times as large
as the login .text section. If perhaps four or five memory-resident
programs are replaced by PERL scripts, the break-even point is
reached.) Also, if the PERL executable is always resident, then
loading PERL programs from disk should require very little time.
A more obvious advantage is that writing PERL programs is much less
time-consuming that writing C programs. This is due to the fact that
the compile step gets skipped, and because PERL has a built-in
debugger.
Third, I find PERL a *much* better script language than either sh or
csh.
Additionally, PERL contains special support to aid in writing secure
programs. It is easier to write secure SUID programs in PERL than it
is in C.
Finally, PERL scripts are architecture-independent. If Linux ever
gets ported to multiple architectures (which I am guessing it will),
all support programs written in PERL port with no effort at all.
There are several disadvantages to using PERL.
First of all, PERL must be ported to Linux. Of course, PERL should be
ported to Linux whether or not my suggestion is adopted.
PERL is a very *expert* friendly language. Learning to program in
PERL involves a steep learning curve. It takes quite a bit of
practice to become proficient at writing in PERL. I believe the
effort is well spent.
Subject: PERL
Date: Wed, 15 Jan 92 23:14:50 PST
From: pmacdona@sanjuan.UVic.CA (Peter MacDonald)
To: linux-activists@joker.cs.hut.fi
I am a little opposed to using PERL for development.
Because.
We already are using C for most things.
Sh script has to be there because bash is.
Everyone would have to become experts in a third language.
I mean, as far as I am concerned, I'am a little peaved that sh isn't
more like C. Going to PERL will take us even further from the KISS
principle. And..
Shared libraries are coming, so executables will be getting smaller,
and the break even point for PERL will be increased.
Don't get me wrong, DO port PERL. But sell the farm...
Subject: Re: Use PERL rather than C for system commands?
To: tim@pokey.cs.caltech.edu (Timothy L. Kay)
Cc: linux-activists@joker.cs.hut.fi
In-Reply-To: Your message of Wed, 15 Jan 92 22:08:25 -0800.
Date: Thu, 16 Jan 92 00:28:19 MST
From: drew@hazelrah.cs.Colorado.EDU
It seems to me that the language PERL is ideal for implementing many
of the pieces that are currently missing from Linux. For example,
init, getty, login, shutdown, halt, cron, inetd, etc. could very
easily be written in PERL rather than C. Most OS-support programs
(including the ones mentioned previously) are not time critical. They
run very infrequently, and the performance degradation (if there is
any) should be inconsequential.
Can't do standard library calls in perl :( -
init, shutdown are definates
getty - maybe
cron - probably want to use alarms for the next event, so no
inetd - we want to use listen, so no
Third, I find PERL a *much* better script language than either sh or
csh.
Agreed! Let's get perl for Linux.
Finally, PERL scripts are architecture-independent. If Linux ever
gets ported to multiple architectures (which I am guessing it will),
all support programs written in PERL port with no effort at all.
Non-issue : any of the programs mentioned above, halt excepted (If we
are to code in an infinite loop with interrupts disabled) will go
no deeper than mayuking system calls.
--------
Subject: Re: Use PERL rather than C for system commands?
From: tim@pokey.cs.caltech.edu (Timothy L. Kay)
To: linux-activists@joker.cs.hut.fi
Date: Thu, 16 Jan 92 10:55:30 -0800
I recently submitted a message suggesting that Linux use PERL as the
implementation lanugage for many of its system support programs. The
follow-ups indicated that people aren't familiar with the abilities of
PERL. To address specific points mentioned in the followup, PERL does
give access to essentially all of the Unix system calls, including
alarm() and listen(). There is no technical reason why PERL couldn't
be used; it is simply a question of whether people think the
philosophical change is justified by the advantages gained.
Tim