Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ruminations on the future of Perl

35 views
Skip to first unread message

Dale Worley

unread,
Jun 27, 1991, 4:34:39 PM6/27/91
to
I've been giving some thought to the future of Perl. Of course, these
comments are a mite arrogant, but at least they may help Larry plan.

Probably the best thing for the long-run health of Perl (although the
worst for everybody now involved with it) is to scrap it and redesign
(and reimplement) it from the ground up. Having implemented and used
Perl, we now know *what it should have been*.

In my opinion, Perl's biggest weaknesses are (1) its syntax is
fantastically complex (consider the multiple meanings of / and $), and
(2) it is a collection of features more than a coherent language for
expressing algorithms.

However, rebuilding Perl is quite impractical. Not only would it
involve an enormous amount of work, all existing Perl code would have
to be rewritten.

The other idea I have for the future of Perl is that it is now
undergoing the transition from a "program" to a "program product".
This means that the users are demanding that it be much more reliable,
understandable, and portable than ever before. And, as Brooks noted,
it takes about three times as much effort to produce a program product
as to produce a program. (Consider the number of bugs and
difficulties that version 4 is having, because of the number of users
exercising it.) Where is all of this effort going to come from? Can
we really expect Larry to devote the rest of his life to maintaining
Perl?

In order for Perl to take its rightful place as a standard Unix tool,
it needs to become a product. However, I can't see how to finance the
large amount of work that is going to be necessary on a continuing
basis.

Dale

Dale Worley Compass, Inc. wor...@compass.com
--
If you can't drink a lobbyist's whiskey, take his money, sleep with his
women and still vote against him in the morning, you don't belong in
politics. -- Speaker of the California Assembly Jesse Unruh

Felix Lee

unread,
Jun 27, 1991, 8:00:25 PM6/27/91
to
>Probably the best thing for the long-run health of Perl (although the
>worst for everybody now involved with it) is to scrap it and redesign
>(and reimplement) it from the ground up.

I started to reimplement (but not redesign) Perl a while back. My
intent was to create a stand-alone parser (and scanner) that would
read a Perl program and output a syntax tree in lispy form. If you
then take the syntax tree and do a huge amount of semantic analysis,
you can output, say, Scheme code. Then you just need to implement a
Scheme engine with enough libraries to support Perl builtins.

Once you have a Scheme suitable for Perl-type programming tasks, you
can easily create a more politically correct syntax. And then you can
automatically convert Perl to the new syntax by way of the Perl to
Scheme translator.

I halfway implemented the parser before the project dropped by the
wayside. Do people care enough about Perl that it would be worth
pursuing again?
--
Felix Lee fl...@cs.psu.edu

Doug DeJulio

unread,
Jun 27, 1991, 10:06:03 PM6/27/91
to
In article <WORLEY.91J...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>In order for Perl to take its rightful place as a standard Unix tool,
>it needs to become a product. However, I can't see how to finance the
>large amount of work that is going to be necessary on a continuing
>basis.

It's not like it's a commercial product, it's available under
copyleft. People *will* continue to improve it, and we'll all benefit
from the result.
--
--
Doug DeJulio
d...@zardoz.club.cc.cmu.edu (NeXT mail)
dd...@andrew.cmu.edu (AMS/ATK mail)

Dan Bernstein

unread,
Jun 28, 1991, 12:27:14 AM6/28/91
to
In article <WORLEY.91J...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
[ on what to do in Son Of Perl ]

> In my opinion, Perl's biggest weaknesses are (1) its syntax is
> fantastically complex (consider the multiple meanings of / and $), and
> (2) it is a collection of features more than a coherent language for
> expressing algorithms.

Wait a minute. What's wrong with a complicated syntax, and what's wrong
with having a grab-bag of features?

The first thing I'd do in a rewrite is have the parser produce strictly
threaded intermediate code. Then setjmp() and longjmp() would disappear,
we could turn the optimizer back on, the intermediate code could easily
be compiled into C, and the Perl semantics (though never its syntax :-))
would be much easier to handle. The second thing I'd do is give the
program a strong sense of its internal state, so that it could properly
(and portably!) checkpoint and restart, pass state to another Perl
process even running on a different machine, and allow independent
debuggers. Third, I'd add non-preemptive threads. Finally, I'd try to
educate Perl's users into understanding when the established tools are
more appropriate for the job.

---Dan

Dale Worley

unread,
Jun 28, 1991, 11:07:59 AM6/28/91
to
In article <1991Jun28....@zardoz.club.cc.cmu.edu> d...@zardoz.club.cc.cmu.edu (Doug DeJulio) writes:
It's not like it's a commercial product, it's available under
copyleft. People *will* continue to improve it, and we'll all benefit
from the result.

My belief is that it needs a *lot* of improvement -- many times more
work than has been put into it so far. (That's the screw of going
from "program" to "product".) The present situation will only allow
for small, incremental improvements.

Of course, no one can make a commercial product out of it; the
copyleft will guarantee that anybody who tries will go broke. The one
exception is Larry -- he can make proprietary changes and keep people
from copying them!

Dale

Dale Worley Compass, Inc. wor...@compass.com
--

There are three kinds of people: those that can count, and those that can't.

Dale Worley

unread,
Jun 28, 1991, 11:04:13 AM6/28/91
to
Here's the quote I was looking for:

A programming language cooked up haphazardly as a collection of
briliant ideas is a menace to good programming methodology. It is
also more difficult to implement, so the odds favor an unreliable
compiler, whose unreliable parts programmers learn to avoid through
bitter experience...
-- Harland Mills, "Software Productivity"

(He was referring to PL/1.)

Dale

Michael T. Rampson

unread,
Jun 28, 1991, 1:40:23 PM6/28/91
to
In article <WORLEY.91J...@sn1987a.compass.com>,

wor...@compass.com (Dale Worley) writes:
> I've been giving some thought to the future of Perl. Of course, these
> comments are a mite arrogant, but at least they may help Larry plan.
>
> Probably the best thing for the long-run health of Perl (although the
> worst for everybody now involved with it) is to scrap it and redesign
> (and reimplement) it from the ground up. Having implemented and used
> Perl, we now know *what it should have been*.

I don't have any major problems with Perl. What do you envision that it
should have been?

>
> In my opinion, Perl's biggest weaknesses are (1) its syntax is
> fantastically complex (consider the multiple meanings of / and $), and
> (2) it is a collection of features more than a coherent language for
> expressing algorithms.

I think that 'fantasically complex' is too strong (IMHO), although I
readily admit that it's syntax does have a few quirks that take some
getting used to. It's syntax is closely related to C, csh, awk and sed
(with regards to regex) so it doesn't take too long to start doing
something useful with perl. Of course, as you want to do more and
more complex things with perl, you have to delve deeper into perl.

>
> However, rebuilding Perl is quite impractical. Not only would it
> involve an enormous amount of work, all existing Perl code would have
> to be rewritten.

Which means that you are basically talking about implementing
another language (if existing code is going to have to re-written)
unless your thinking about some kind of transition ala C-> ANSI-C.

>
> The other idea I have for the future of Perl is that it is now
> undergoing the transition from a "program" to a "program product".
> This means that the users are demanding that it be much more reliable,
> understandable, and portable than ever before. And, as Brooks noted,
> it takes about three times as much effort to produce a program product
> as to produce a program. (Consider the number of bugs and
> difficulties that version 4 is having, because of the number of users
> exercising it.) Where is all of this effort going to come from? Can
> we really expect Larry to devote the rest of his life to maintaining
> Perl?

The number of bugs isn't really all that suprising considering that
basically larry is mostly doing all of the work and he has no real
test organization to help him out other than his unit tests and his
user community. I don't think we can really expect larry to devote the
rest of his life to maintaining perl. I some point he is going to have
enough of perl and either someone else is going to have to pick it up,
or he is going to have to make arrangements with FSF to pick up
M&E on perl. As a member of this user community, I think in the near
future, larry is going to have to ask us for help, or we should volunteer our
help to larry.

>
> In order for Perl to take its rightful place as a standard Unix tool,
> it needs to become a product. However, I can't see how to finance the
> large amount of work that is going to be necessary on a continuing
> basis.
>

I beleive the original intent of perl was to be more functionally oriented
instead of being some general elegant language. The idea being that perl
could replace all of your csh, sh, awk, sed, etc scripts with one tool
that could
do all of these things, thus simplifing maintenance by only have to know one
tool, and speediup execution by not having to spawn off other processes to
do awk, sed, etc. To extend the functionality even further, include OS calls
so you didn't have to write C programs on top of writing perl, losing some in
speed, but gaining maintainability in that you still only needed to know
one tool
to get even more work accomplished, more quickly. Perl has been a godsend to
my organization and group where we had an SCM (Software Configuration
Management) tool set written in csh, ksh, sed, awk, etc. By rewriting in perl,
we have since improved maintainability of the toolset dramatically, letting us
add even more functionality. It has also sped up our build process
dramatically
seeing speed ups from 3 time faster on most tools, upto 30 time faster on
others (especially tools that were made up of csh and awk scripts, all
of the time was
spent firing up awk to do parsing on strings and lines). I'd like to
extend my thanx
to larry (and randal) for all of the hard work they have put in to
provide a tool
that has saved me and my company countless hours.

sincerely,
Mike Rampson


__
The objective of all dedicated employees should be to thoroughly
analyze all situations, anticipate all problems prior to their
occurrence, have answers for these problems, and move swiftly to solve
these problems when called upon.

However, When you are up to your ass in alligators it is difficult to
remind yourself your initial objective was to drain the swamp.

rampson@uswat

Don Mullins

unread,
Jun 28, 1991, 2:00:59 PM6/28/91
to

>I've been giving some thought to the future of Perl. Of course, these
>comments are a mite arrogant, but at least they may help Larry plan.

I like having Perl in it's preset form. I don't think it was really
intended to be a "programming" language as much as it was intended to be
a "scripting" language.

The one major improvement, IMHO, would be the ability to dump compiled
(interpreted?) code separate from the perl core, as done today.

Don

--
Don Mullins mul...@convex.COM {uiucuxc, uunet, sun, ...}!convex!mullins
Product Engineering Convex Computer Corporation, Richardson, Texas

Rusty Wright

unread,
Jun 28, 1991, 10:15:13 PM6/28/91
to
I suppose everyone has their list of what they'd like to see done to
improve perl. This list is what I dislike about perl; things that I
consider to be bad design and unnecessarily confuse new (and old) perl
users. It often seems to me that perl is one big hoary blob of
creeping featurism. I'll reference the perl man page here as that's
what I'm using to jog my memory.

1) The man page gives too many ways to do the same thing, for no
apparent reason other than hackeritis. For example, towards the end
of the "Data Types and Objects" section are some examples that are
preceded by the sentence "Anyway, the following lines are equivalent
to each other" and the first example is

while ($_ = <STDIN>) { print; }

and the last is

print while <STDIN>;

Similarly, in the "Syntax" section are examples for opening "foo" and
dying if it can't be opened, with the classic

open(foo) || die "Can't open $foo: $!";

(but which I find to be just hackeritis show-off).

And then further on there are the various examples on the "foo:"
block.

I suppose one might argue that some of these wierd constructs execute
faster than others; my response would be that programmers shouldn't be
wasting their time tweaking their perl code to try to speed it up. In
other words, perhaps perl needs more work in optimizing when it
compiles.

2) Functions as unary operators. Maybe I'm missing something here.
In the paragraph that precedes the list of perl functions it says "If
an operation is listed both with and without parentheses around its
arguments, it means you can use it as a unary operator or as a
function call." Now, tell me, when would I ever be required to or
need to or want to use chdir as a unary operator? Seems to me they
should all be functions. Towards the end of the man page there's the
"Precedence" section which tries to explain this mess.

3) getpgrp and getppid: what's wrong with this picture? I was once
trying to create a temporary file (wanting to use the process id for
the file's name) and was amazed that perl doesn't have a getpid
function. Then, when I was working on another perl program I stumbled
across $$. I was so aggravated I swore out loud.

4) last and next. What's wrong with using break and continue? Just
seems like a gratuitous incompatibility with C, csh, awk, etc.

5) length should accept an array as an argument and return the number
of elements in it. See for exmaple, tcl.

6) open. What a nightmare. I simply cannot believe that crap of
putting >, <, and | into the EXPR argument for specifying redirecting
input/output or piping to/from a command. I'd use the same syntax
that fopen(3) uses and popen for piping to/from commands.

7) Predefined names; $_, $., et. al. This is a worse nightmare than
open. What's the point of this? Hasn't anyone ever heard of using
DESCRIPTIVE NAMES for variables? I like the man page's disclaimer,
"Most of them have reasonable mnemonics, or analogues in one of the
shells." Where's my barf bag.

Felix Lee

unread,
Jun 28, 1991, 4:53:38 PM6/28/91
to
Perhaps I should clarify. What I have is pieces of a Perl parser.
Once that's done, the obvious next step is a semantic analysis and
optimization phase. And then a code generator can generate whatever
sort of back-end code you like: assembler, C, Scheme, whatever.
Scheme seems to me to have several advantages over C.

If this ever gets that far and I do decide that Scheme would work
well, there will probably be a Scheme compiler and interpreter bundled
in. One of my friends has been wishing for a lightweight Scheme that
can occupy the same niche as Perl and C as a systems programming tool.

If you're unfamiliar with Scheme, the language is somewhat a
descendent of Algol and Lisp. The lispy syntax will probably turn off
anyone who doesn't like lispy parentheses, but it's pretty trivial to
paste a different syntax in front. Existing Scheme compilers generate
code comparable in speed to C compilers; heavily recursive code is
usually faster in Scheme.
--
Felix Lee fl...@cs.psu.edu

Tom Christiansen

unread,
Jun 28, 1991, 5:26:06 PM6/28/91
to
From the keyboard of wor...@compass.com (Dale Worley):
: It's not like it's a commercial product, it's available under

: copyleft. People *will* continue to improve it, and we'll all benefit
: from the result.
:
:My belief is that it needs a *lot* of improvement -- many times more
:work than has been put into it so far. (That's the screw of going
:from "program" to "product".) The present situation will only allow
:for small, incremental improvements.

:Of course, no one can make a commercial product out of it; the
:copyleft will guarantee that anybody who tries will go broke. The one
:exception is Larry -- he can make proprietary changes and keep people
:from copying them!

This is not true: there are companies that ship perl. Mine is one of
them. Of course, we also ship GNU emacs. Sigh. :-) But I can't imagine
the goal of the copyleft is to limit accessbility to perl. Notice the
alternative licence it's now shipped with.

What do you want added for a commercial product? Something you can
hand over to kindergarteners? Or do you want marketing glossies?
User manuals that teach it in a slower, more tutorial style?
Interactive learning tools? Salesman who push it because they get a
commission? Some of these ideas perhaps have merit. Some perhaps do
not. What are you looking for?

Larry does have a test organization, and a vast one: comp.lang.perl,
distributed regressions testing in action. There aren't many people who
are up for fixing the bugs we sometimes find. I admit that we probably
couldn't handle it without Larry's dedication.

If I had my druthers, I wouldn't mind seeing the following things in
perl. Some are more feasible than others.


1) Replace the $~, $|, etc handle-specific i/o variables with something
less painful. Maybe FILE'property or such.

2) Be able to generate C code. Be able to easily link in C code.
Not have to make a stab at getting your structure formats right.

3) Real structured variables. $struct'field'subfield'subsubfield
look ok. conversions between these and C structs.

3) Dump internal state as Dan Bernstein mentioned. Not rogue dumping.
Keeping the whole thing on disk for each dump is a pain.

4) More knowledge of touching variables outside your scope. -w
should be able to know this. This would catch more typos and
potentially dangerous opeations.

5) Dynamic loading of C libraries. [should be feasible on say Suns.]

6) Ability to get call co-routines in perl from a C program, such as
for string routines.

7) Optimized (k)sh2p translator. Obviously sed and awk calls are easy,
but I mean catching `basename' and head and tail etc.

8) Some nice way to have perl as my shell environment.

9) Perl used as an extension language. (For editors, newsreaders, etc.)

10) Guaranteed presence on more machines. That means shipment by
more vendors. Target the workstation vendors first for market
penetration: sun, dec, ibm, hp, sgi, etc.

11) Shared memory variables for cooperating processes.

12) Easier IPC (or RPC) library interfaces than what's there now.

13) Lightweight threads. fork (or open(FOO, "-|") cost too much.

14) Fewer surprises for newusers. See the gotchas to know what I mean.

15) Better recovery from syntax errors.

16) More fine-grained (and determistic) signal handling. I want
sigblock() etc.

17) Being able to know whether my read()s will restart or not instead
of being at the mercy of the O/S I'm running under.

18) A nice, moderately-paced book for non-hackers who want to learn it.
Don't get me wrong: I love the Camel book. It's just not for everyone.
Maybe such users should go back and learn C and UNIX and awk and
all that first before they return to the Camel book, but maybe
there should be another way.

19) More applications written in perl publicly available. A place
where these can be stored and inquired about.

20) More people to answer questions about it. Maybe 18 would help.

21) More people who understand the actual code well so we don't have
all our eggs in one basket. Larry, look out for falling rocks.

22) A database with good access methods for all the archives of
comp.lang.perl.


That's all for now.


--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"So much mail, so little time."

Ed Vielmetti

unread,
Jun 28, 1991, 8:23:33 PM6/28/91
to

19) More applications written in perl publicly available. A place
where these can be stored and inquired about.

22) A database with good access methods for all the archives of
comp.lang.perl.

Good things to have. Might be worth sticking the archives into WAIS?

--Ed

-- MSEN Archive Service file verification
quake.think.com
total 5561
drwxrwxrwx 2 14 1024 Jun 25 00:07 wais-discussion
-rw-rw-rw- 1 1637 635857 Jun 21 21:50 WAIStation-Canned-Demo.sit.hqx
-r--r--r-- 1 14 463981 Jun 13 20:44 wais-8-b1.tar.Z
-rw-rw-r-- 1 1556 475161 May 21 18:43 wais-8-a12-3.tar.Z
-rw-rw-rw- 1 1637 635225 May 16 03:01 WAIStation-0-62.sit.hqx
-rw-rw-rw- 1 999 321268 May 13 20:48 wais-ir12.ZU
-rw-rw-rw- 1 14 409388 Apr 5 00:44 wais-8-a11.tar.Z
-rw-rw-rw- 1 1637 1094536 Mar 28 00:37 WAIStation-0-62-Sources.sit.hqx
-rw-rw-rw- 1 14 1070714 Mar 23 01:24 WAIStation-0-61.sit.hqx
-rw-rw-rw- 1 14 475815 Mar 23 01:19 wais-8-a10.tar.Z
found wais ok
quake.think.com:/pub/wais/

Johan Vromans

unread,
Jun 29, 1991, 5:23:09 AM6/29/91
to
In article <2gaH&?b#@cs.psu.edu> fl...@cs.psu.edu (Felix Lee) writes:

Perhaps I should clarify. What I have is pieces of a Perl parser.
Once that's done, the obvious next step is a semantic analysis and
optimization phase. And then a code generator can generate whatever
sort of back-end code you like: assembler, C, Scheme, whatever.
Scheme seems to me to have several advantages over C.

How about a perl front-end for gcc?

Johan
--
Johan Vromans j...@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------

Gene Spafford

unread,
Jun 29, 1991, 6:47:52 PM6/29/91
to
I use Perl because I can quickly come up with a solution to
programming problems that need a fast, simple hack that I may need to
reconfigure later. I used to use C, but for a long time C has had too
much overhead because of all the include files, declaring structs,
etc. With some of the cruft in ANSI C, its worse. I've used ksh and
awk for a while, but neither had all the functions I wanted. Then I
found Perl.

The "hackeritis" features that Rusty complains about are *exactly* why
people like me like to use Perl -- if there was only one way to
accomplish each task, the amount of memorization and understanding
involved to accomplish any arbitrary problem would be huge. It's the
same reason why people prefer C to Ada, for instance. It's also why a
knowledgable mechanic treasures his pair of ViseGrips over his 7mm
open-end box wrench. And its the same principle that gives us many
hundreds of thousands of words in spoken language that few of us know
or use, but we can still communicate effectively with a smaller set of
less precise words.

Larry is a "hacker's hacker" in the sense that he knows how to produce
working code to do useful things. Perl is a tool that he developed to
match the way he produces code. Not all of us have the same
programming "idioms" in mind Larry does, and that may be why we view
some of the features of Perl with curiosity, horror, or indifference.
I've found as I've used Perl, however, and read the book, that I am
developing new idioms and techniques, and the language helps me
express them without undue difficulty.

I don't mean to discourage people from talking about how Perl might be
changed to be more efficient, or add new features, or otherwise change
its nature. However, I caution everyone to consider that moves in
that direction may lead to horrors like ANSI standards :-). The very
concept of an ANSI committee to standardize Perl horrifies me.

Before we take anyone's comments on changes too seriously, I'd suggest
we ought to make them take this little quiz:

1) Have you read the Camel book at least twice?
a) No
b) Yes
c) The what? Camels?

2) Can you understand 6 months of the various "Just another Perl hacker"
signature programs Randal has used in his postings?
a) No way
b) Yes, and I can optimize some of them
c) Randal who?

3) Your favorite compiled language of the following is
a) Pascal
b) C++
c) Ada

4) You think design-by-committee is a good thing
a) Of course
b) Hell no -- look at Ada
c) Hell yes -- look at Ada

5) How many working, useful lines of Perl code have you written in the
last 6 months:
a) less than 10,000
b) more than 10,000
c) I have others write my code for me

6) How many of the following languages are you familiar with (written
substantial amounts of code): APL, nawk, C++, Eiffel, Scheme, abc, Modula,
SNOBOL, ML, SmallTalk, Prolog, Icon, .....(insert other appropriate
languages here)
a) 1 or 2
b) most of them
c) There are languages with names like that?

7) How may compilers/interpreters have you every written or helped with?
a) One in my compilers undergrad class, once
b) Many
c) I have others write my code for me

8) Approximately how many people are regularly using anything you designed
and/or wrote?
a) Me, and maybe a few friends
b) Several hundred at a minimum
c) I use the code written by others


Anybody answering (a) to more than 2 questions is not yet qualified to
discuss the future of Perl (or pretty much any language).

Anybody answering (c) to any of them shouldn't be allowed to post to
this group! :-)

# Besides, why would you want to change a language that lets you
# write a program like this? :-)
exit unless eval q[sub then {substr($b,1)cmp substr($a,1);} print sort then
split if ($\,$_,$,)=(qx,echo .,,q,Perl Just hacker another,,q, ,)];

Robert Krawitz

unread,
Jun 29, 1991, 10:19:58 PM6/29/91
to
A couple of other things I would like in perl:

1) True multidimensional arrays. Associative arrays simply don't cut
it, if nothing else for the fact that looping over associative arrays
yields values in an unpredictable order, whereas I want something that
looks a bit more like a matrix. Some ideas:

rank(@a) returns the rank of a (the number of dimensions). This enables
support for true arbitrarily (and variably) dimensioned arrays.

$a[@dims] uses the list as a group of dimensions. Thus a list of
dimensions could be used to access an array that may be of variable
dimensionality (such as might be passed to a subroutine). Scalar and
vector dimensions could be mixed, e. g. $a[$dim0,@dim1_n].

maxindex(@a,$dim) returns the maximum index along dimension $dim (since
the array might not be square, it would return the largest index along
any vector aligned with dimension $dim). Similar for minindex.

foreach $i (@array) sets a variable @_DIMS to a list of the indices of
the current element of @array.

isin (@array @indices) returns true or false (1 or 0) depending on
whether @indices represent an element of @array.

2) A mode to catch references to an undefined variable and error out at
runtime, along with some kind of optional typing system to catch stupid
errors (for example, using a string as a number). Also a method to
"declare" typed arguments to subroutines with runtime type checking.
--
ames >>>>>>>>> | Robert Krawitz <r...@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)234-2116

Rodney Peck II

unread,
Jun 30, 1991, 5:31:48 PM6/30/91
to
In article <RUSTY.91J...@groan.Berkeley.EDU> ru...@groan.Berkeley.EDU (Rusty Wright) writes:
[...]

>Similarly, in the "Syntax" section are examples for opening "foo" and
>dying if it can't be opened, with the classic
>
> open(foo) || die "Can't open $foo: $!";
>
>(but which I find to be just hackeritis show-off).

I don't understand -- I use this all the time. really. what's the
problem?

[...]

>3) getpgrp and getppid: what's wrong with this picture? I was once
>trying to create a temporary file (wanting to use the process id for
>the file's name) and was amazed that perl doesn't have a getpid
>function. Then, when I was working on another perl program I stumbled
>across $$. I was so aggravated I swore out loud.

You must be new to unix -- from the csh man page:

CSH(1) USER COMMANDS CSH(1)

[...]

$$ Substitute the process number of the (parent) shell.


Sun Release 4.1 Last change: 2 October 1989 9

It wasn't Larry's idea. Everyone has been using $$ as the pid since time
began. It didn't occur to me that it might not be obvious until you
mentioned that you were swearing out loud about it. In fact, if you say
man perl and then search for 'process number' it goes right to $$.

Please, lets not be changing perl just because some people can't read the
man page.

--
Rodney

Tom Christiansen

unread,
Jun 30, 1991, 6:45:32 PM6/30/91
to
From the keyboard of rod...@dali.ipl.rpi.edu (Rodney Peck II):
:In article <RUSTY.91J...@groan.Berkeley.EDU> ru...@groan.Berkeley.EDU (Rusty Wright) writes:
:>Similarly, in the "Syntax" section are examples for opening "foo" and

:>dying if it can't be opened, with the classic
:>
:> open(foo) || die "Can't open $foo: $!";
:>
:>(but which I find to be just hackeritis show-off).
:
:I don't understand -- I use this all the time. really. what's the
:problem?

Perhaps those folks not heavily into shell programming do not take well
to using && and || for flow control. But those who are, do, and are
glad it's there.

Rodney Peck II

unread,
Jun 30, 1991, 7:29:08 PM6/30/91
to
In article <1991Jun30.2...@convex.com> tch...@convex.COM (Tom Christiansen) writes:
>From the keyboard of rod...@dali.ipl.rpi.edu (Rodney Peck II):
>:In article <RUSTY.91J...@groan.Berkeley.EDU> ru...@groan.Berkeley.EDU (Rusty Wright) writes:
>:>Similarly, in the "Syntax" section are examples for opening "foo" and
>:>dying if it can't be opened, with the classic
>:>
>:> open(foo) || die "Can't open $foo: $!";
>:>
>:>(but which I find to be just hackeritis show-off).
>:
>:I don't understand -- I use this all the time. really. what's the
>:problem?
>
>Perhaps those folks not heavily into shell programming do not take well
>to using && and || for flow control. But those who are, do, and are
>glad it's there.

hm. I suppose that's probably what the problem is. I find it perfectly
normal. I don't do much with shell scripts, but I used to program in
Lisp a lot and it's pretty common to write:
(or (function-1)
(fun-2)
(fun-3))

to try a sequence of things to get something done... like:

(or (open-local)
(open-remote-via-tftp)
(open-remote-via-ftp)
(open-remote-via-rlogin)
(open-remote-via-telnet))

so... open || die makes perfect sense to me and is very readable.

What isn't so readable is:

$number-- || print "Number is zero.";

then again, maybe it is...

--
Rodney

Joshua Osborne

unread,
Jun 30, 1991, 11:43:33 PM6/30/91
to
In article <1991Jun30.2...@convex.com> tch...@convex.COM (Tom Christiansen) writes:
>From the keyboard of rod...@dali.ipl.rpi.edu (Rodney Peck II):
>:In article <RUSTY.91J...@groan.Berkeley.EDU> ru...@groan.Berkeley.EDU (Rusty Wright) writes:
>:>Similarly, in the "Syntax" section are examples for opening "foo" and
>:>dying if it can't be opened, with the classic
>:>
>:> open(foo) || die "Can't open $foo: $!";
>:>
>:>(but which I find to be just hackeritis show-off).
>:
>:I don't understand -- I use this all the time. really. what's the
>:problem?
>
>Perhaps those folks not heavily into shell programming do not take well
>to using && and || for flow control. But those who are, do, and are
>glad it's there.

Lots of people have assumed he is objecting to the use of || for flow
control. However I think he is objecting to open(foo) using $foo to
find the file-name to open. It is certinly a less then oft-used feature.

I almost never use it. I don't rember any example programs using it.
However I don't rember any JAPH's using it, so it can't be ther just to
make obscure perl code :-)

(this is what I assumed he was refering to when I made my orig reply)
--
str...@eng.umd.edu "Security for Unix is like
Josh_Osborne@Real_World,The Multitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
"CNN is the only nuclear capable news network..."
- lbr...@eng.umd.edu (Lewis Bruck)

Joshua Osborne

unread,
Jun 30, 1991, 1:32:40 PM6/30/91
to
In article <RUSTY.91J...@groan.Berkeley.EDU>, ru...@groan.Berkeley.EDU (Rusty Wright) writes:
> 1) The man page gives too many ways to do the same thing, for no
> apparent reason other than hackeritis.

Ahh, but there is a good reason. One way is good for programs that will
live a long time. One way is for programs that won't. One way is easy
for C people to use, another is for sh'ers, yet another for awk'ers. Another
way is more general. I don't really think we should have one way for C, another
way for sh, and another way for awk'ers, but that may just be because I only
know C (well, C is the one I know well), and of corse I want the C version to
be taken in just about all conflicting cases...

> For example, towards the end
> of the "Data Types and Objects" section are some examples that are
> preceded by the sentence "Anyway, the following lines are equivalent
> to each other" and the first example is
>
> while ($_ = <STDIN>) { print; }

This is showig a "longcut", I _like_ the way "while(<FOO>)" works, it is
very easy to use.

> and the last is
>
> print while <STDIN>;

I'll admit, this may be a bit much (am I just saying that because _I_ never
use it?).

> Similarly, in the "Syntax" section are examples for opening "foo" and
> dying if it can't be opened, with the classic
>
> open(foo) || die "Can't open $foo: $!";
>
> (but which I find to be just hackeritis show-off).

This is useless for a script you will use for a while. It is useful for
something you are going to write in 3 minutes or less (because it will only
take 4 to do by hand...). I'll have to admit I almost never use it.

> And then further on there are the various examples on the "foo:"
> block.
>
> I suppose one might argue that some of these wierd constructs execute
> faster than others; my response would be that programmers shouldn't be
> wasting their time tweaking their perl code to try to speed it up. In
> other words, perhaps perl needs more work in optimizing when it
> compiles.

Rember that it compiles every time you run your script. I don't want to make
the compile much slower, do you?

> 2) Functions as unary operators. Maybe I'm missing something here.
> In the paragraph that precedes the list of perl functions it says "If
> an operation is listed both with and without parentheses around its
> arguments, it means you can use it as a unary operator or as a
> function call." Now, tell me, when would I ever be required to or
> need to or want to use chdir as a unary operator? Seems to me they
> should all be functions. Towards the end of the man page there's the
> "Precedence" section which tries to explain this mess.

chdir? Likely never. However sin you may, some of the string functions would
be good that way. For once perl's syntax is regular (all foo bay be goo, not
all foo except bar may be goo, unless used elsewhere in the script as baz, or
when $* is set...), and you jump on it?

> 3) getpgrp and getppid: what's wrong with this picture? I was once
> trying to create a temporary file (wanting to use the process id for
> the file's name) and was amazed that perl doesn't have a getpid
> function. Then, when I was working on another perl program I stumbled
> across $$. I was so aggravated I swore out loud.

Nothing, I would like them.

> 4) last and next. What's wrong with using break and continue? Just
> seems like a gratuitous incompatibility with C, csh, awk, etc.

I donno, mabie Larry wants to remind us that they are diffrent from C's
break & continue? Mabie because Larry just like last and next, and chose them
before perl came out of the closet? Mabie because perl isn't C? Who knows?

> 5) length should accept an array as an argument and return the number
> of elements in it. See for exmaple, tcl.

This would be quite nice.

> 6) open. What a nightmare. I simply cannot believe that crap of
> putting >, <, and | into the EXPR argument for specifying redirecting
> input/output or piping to/from a command. I'd use the same syntax
> that fopen(3) uses and popen for piping to/from commands.

More convient, sometimes. However it is (somewhat) difficult to use when
the filename is variable, but the mode isn't. I offen worry about someone passing
"foo|" as a filename (what happens if I open "<foo|"? or "sort -n foo||"?).

I hate the fopen mode charactors, I allway need to use the man page to
fine them. I like perl's more. Alot more. But some wouldn't work well
as a 3rd argument. What does fopen(BAZ, "cat foo", "|") do?

> 7) Predefined names; $_, $., et. al. This is a worse nightmare than
> open. What's the point of this? Hasn't anyone ever heard of using
> DESCRIPTIVE NAMES for variables? I like the man page's disclaimer,
> "Most of them have reasonable mnemonics, or analogues in one of the
> shells." Where's my barf bag.

I like $_, something more descriptave would be harder to type. I don't like
most of the others. $Perl'lineno, or $Perl'euid would be easyer to rember, it
would be nice to have them. I wouldn't mind keeping $., and $( (or is it $), or
$<, or $>, or what?) and the rest around for both compatibilty, and people with
better memmorys. Besides we are running out of symbols. (we needs an APL char
set if we keep it up...)

Dale Worley

unread,
Jul 1, 1991, 10:58:04 AM7/1/91
to
In article <1991Jun28.2...@convex.com> tch...@convex.COM (Tom Christiansen) writes:
:Of course, no one can make a commercial product out of it; [...]

This is not true: there are companies that ship perl.

Shipping != making a commercial product.

What do you want added for a commercial product? Something you can
hand over to kindergarteners? Or do you want marketing glossies?
User manuals that teach it in a slower, more tutorial style?
Interactive learning tools? Salesman who push it because they get a
commission? Some of these ideas perhaps have merit. Some perhaps do
not. What are you looking for?

Basically, yes, I want something you can hand over to kindergarteners.
The following ideas come to mind:

- New versions work, out of the box, on multiple architectures. (This
demands a test suite perhaps an order of magnitude (or two) larger
than the existing test suite, run on a couple of dozen architectures,
for each release.) (By "work", I mean that code which worked
correctly on old versions works correctly on the new version.)

- It *never* core dumps, and except in the most unusual circumstances,
produces a usable error message.

- Enhancements that make the user's life better are made frequently.
(Writing out "compiled Perl" is a prime example -- people are
clamoring for it all the time, it would help enormously, but it would
take a great deal of work to write and maintain and is technically
uninteresting.)

The position I'm coming from is this: My company is starting to write
some serious applications in Perl. This means that our continuing
operation is going to be dependent on the proper functioning of Perl.
Thus, we have a powerful need for Perl to be *dependable*. (That's
why the many bugs reported in Perl 4 disturb me -- how reliable is it,
anyway?) We would also like to not have to dedicate programmers to
keeping Perl running -- we need software that works consistently, out
of the box.

Providing this level of reliability requires more work on the part of
the development operation than Larry can afford, really. However, if
it were available, we would gladly pay for it (at usual
commercial software prices).

Dale Worley Compass, Inc. wor...@compass.com
--

Perhaps this excerpt from the pamphlet, "So You've Decided to
Steal Cable" (as featured in a recent episode of _The_Simpsons_)
will help:
Myth: Cable piracy is wrong.
Fact: Cable companies are big faceless corporations,
which makes it okay.

Randal L. Schwartz

unread,
Jul 1, 1991, 12:56:09 PM7/1/91
to
In article <1991Jul01.0...@eng.umd.edu>, stripes@eng (Joshua Osborne) writes:
| I almost never use it. I don't rember any example programs using it.
| However I don't rember any JAPH's using it, so it can't be ther just to
| make obscure perl code :-)

Nearly *every* Perl feature has been used in a JAPH. I make sure of
that. I'm pretty sure someone beat me to this one by using "_" as a
file handle and variable name... I remember chuckling at the result.

If not, here we go... :-)

perl -e 'print"Just another Perl hacker,"'|perl -e '$_="-";open(_);print<_>;'
--
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III |
| mer...@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/

Robert Steven Glickstein

unread,
Jul 1, 1991, 12:20:43 PM7/1/91
to
rod...@sun.ipl.rpi.edu (Rodney Peck II) writes:
>Perhaps those folks not heavily into shell programming do not take well
>to using && and || for flow control. But those who are, do, and are
>glad it's there.

This reminds me of a problem that I ran up against recently. I
discovered that this didn't work:

@foo = &bar(...) || die "Can't bar...";

while this did:

(@foo = &bar(...)) || die "Can't bar...";

In both cases, bar was returning a non-empty list.

I understand that the "||" binds more tightly than the "=", but even
in the explicitly-parenthesized case

@foo = (&bar(...) || die "Can't bar...");

it seems to me that if bar returns a valid result, it should get
assigned to foo.

______________ _____________________________
Bob Glickstein | Internet: bo...@andrew.cmu.edu
Information Technology Center | Bitnet: bobg%and...@cmuccvma.bitnet
Carnegie Mellon University | UUCP: ...!harvard!andrew.cmu.edu!bobg
Pittsburgh, PA 15213-3890 |
(412) 268-6743 | Sinners can repent, but stupid is forever

Randal L. Schwartz

unread,
Jul 1, 1991, 2:23:06 PM7/1/91
to
In article <YcPpNPe00...@andrew.cmu.edu>, bobg+@andrew (Robert Steven Glickstein) writes:
| I understand that the "||" binds more tightly than the "=", but even
| in the explicitly-parenthesized case
|
| @foo = (&bar(...) || die "Can't bar...");
|
| it seems to me that if bar returns a valid result, it should get
| assigned to foo.

That's because

x || y

is a scalar expression.

print "Just another Perl hacker,"

Tom Christiansen

unread,
Jul 1, 1991, 3:25:48 PM7/1/91
to
From the keyboard of wor...@compass.com (Dale Worley):
:- New versions work, out of the box, on multiple architectures.

I certainly have an ad-hoc test suite, maybe 20k lines
of code we run in house. I put the new version up in
a beta place for a while and see what breaks. :-)

:- It *never* core dumps,

Sorry, all software has bugs. The utopian goal is
that is should never coredump, but this if but
a goal for which you can make strivings. It
doesn't really happen.

:and except in the most unusual circumstances,


:produces a usable error message.

Well, usually I'm happy.

:The position I'm coming from is this: My company is starting to write


:some serious applications in Perl.

Welcome to the club. There are even things that I can't really talk
about, and you'll never see. But yes, we rely upon them for
various product releases. Heck, our entire product installation
software, the stuff that comes on every tape, is written in perl.
I admit to being occasionally nervous for many of the same reasons
you mention.


:This means that our continuing


:operation is going to be dependent on the proper functioning of Perl.

True.

:Thus, we have a powerful need for Perl to be *dependable*. (That's


:why the many bugs reported in Perl 4 disturb me -- how reliable is it,
:anyway?)

I've found a lot lately, but note two things: 1) not all I'm doing
is playing by the rules, that is, I'm really stretching the rules to
their nethermost extemes, and 2) most of these are not new bugs.

:We would also like to not have to dedicate programmers to


:keeping Perl running -- we need software that works consistently, out
:of the box.
:
:Providing this level of reliability requires more work on the part of
:the development operation than Larry can afford, really. However, if
:it were available, we would gladly pay for it (at usual
:commercial software prices).

I suppose we could always bribe him. :-)

Which is yet another glib answer that buys us nothing,
although I guess it might buy Larry a lunch. Anybody
have any bright ideas on this?

Randal L. Schwartz

unread,
Jul 1, 1991, 5:26:35 PM7/1/91
to
In article <1991Jul01....@convex.com>, Tom Christiansen <tchrist@convex writes:
| :Providing this level of reliability requires more work on the part of
| :the development operation than Larry can afford, really. However, if
| :it were available, we would gladly pay for it (at usual
| :commercial software prices).
|
| I suppose we could always bribe him. :-)
|
| Which is yet another glib answer that buys us nothing,
| although I guess it might buy Larry a lunch. Anybody
| have any bright ideas on this?

If every one of the 32,000 people that read comp.lang.perl were to buy
just *one* more copy of the Camel Book (or convince their employer or
school library to do the same), Larry would make enough money to spend
full time on Perl for the next 6-9 months (like he practically has
been for the last three years :-).

Well, maybe that's not an option, but if you're thinking about taking
Larry out to lunch, just buy 5 copies of the book instead, and he can
eat at McDonald's. Or buy one autographed copy (for which he gets
about 5 times the amount of money).

Just another Perl Book hacker,

disclaimer: yeah... if you bought that many books, *I'd* spend
full-time on Perl too... and thank you very wholeheartedly!

Michael T. Rampson

unread,
Jul 1, 1991, 7:02:20 PM7/1/91
to
In article <1991Jul01....@convex.com>, Tom Christiansen
<tch...@convex.COM> writes:
> From the keyboard of wor...@compass.com (Dale Worley):
> :- New versions work, out of the box, on multiple architectures.
>
> I certainly have an ad-hoc test suite, maybe 20k lines
> of code we run in house. I put the new version up in
> a beta place for a while and see what breaks. :-)
>

We do something similar here in my group.

> :The position I'm coming from is this: My company is starting to write


> :some serious applications in Perl.
>

> Welcome to the club. There are even things that I can't really talk
> about, and you'll never see. But yes, we rely upon them for
> various product releases. Heck, our entire product installation
> software, the stuff that comes on every tape, is written in perl.
> I admit to being occasionally nervous for many of the same reasons
> you mention.
>

We are starting to think along the same lines as well. Providing installation
or other services in perl that potentially get sent to the field.

> :We would also like to not have to dedicate programmers to


> :keeping Perl running -- we need software that works consistently, out
> :of the box.
> :
> :Providing this level of reliability requires more work on the part of
> :the development operation than Larry can afford, really. However, if
> :it were available, we would gladly pay for it (at usual
> :commercial software prices).
>

> Which is yet another glib answer that buys us nothing,
> although I guess it might buy Larry a lunch. Anybody
> have any bright ideas on this?
>

Helping Larry with the continuing development of perl would be a
hard task to put together, organize, and coordinate. However, we
could probably help in the testing end to help ensure that a new version
is *good*, by having certain beta-site (sites that make use of perl in
their day-to-day activities and have a substantial amount of perl
code) for the release try it out first for some specified period of time,
then report back to Larry any problems they found. Once it passes
beta-test, it could then be released for general distribution. These
beta-sites should be chosen not only for their 'installed user base'
and amount code, but also for the mix of machines and OS's they
have. One might also want to look at the complexity of code and
features that a site uses in determining if the site would make a
good beta-site. All this would be done on a voluntary basis of course.


__
The objective of all dedicated employees should be to thoroughly
analyze all situations, anticipate all problems prior to their
occurrence, have answers for these problems, and move swiftly to solve
these problems when called upon.

However, When you are up to your ass in alligators it is difficult to
remind yourself your initial objective was to drain the swamp.

ram...@uswat.uswest.com

Ronald S H Khoo

unread,
Jul 1, 1991, 6:31:12 PM7/1/91
to
wor...@compass.com (Dale Worley) writes:

> - It *never* core dumps, and except in the most unusual circumstances,
> produces a usable error message.

Seconded. E.g. Optionally, perl should not attempt I/O on file handles
whose open() failed. On my machine at least, this guarantees a core.

> The position I'm coming from is this: My company is starting to write
> some serious applications in Perl.

Snap.

> Providing this level of reliability requires more work on the part of
> the development operation than Larry can afford, really.

Larry's time is best spent inventing new toys. This includes new
features. Now currently, all perl maintenance comes from Larry, which
means that patches which contain fixes also contain new features, which
of course contain bugs.

For a commercial perl, what we need is something like:

Perl 4.0.10......Larrydevelops....Perl 5
. .
. .
. .
Perl 4.1.0 Perl 5.1

where Perl 4.1 contains bug fixes, with a frozen feature list.
Stuff like anti-coredump code that properly belongs only in a
commercial version might perhaps make it in.

The problem is that this is of course anathema to the perl community
who live for the new feature of the week. Well that's fine, we just
follow what Larry sends out on our own machines, but ship Perl 4.1
on the ones that go to customers. And code accordingly.

What we really need is someone to coordinate Perl 4.1, and of course
Larry's consent to do something like this.

I don't like the idea of truly commercialised Perl 4.1 because we'd
lose the major strength Perl: it's availibility. This would defeat
the object of the exercise. What we need is someone to do
what Stan Barber does for rn -- to take over the "stable" version
maintenance.

Tom C's seemingly correct observation that not enough people know perl
insides well enough shows one serious obstacle, but of course a version
maintainer does not really have to be as familiar with perl innards as
Larry, if the community were to give him as much support as I think we
would. However, I am not volunteering since I lose my net.access in 6
months time :-(

Larry, would you approve a scheme like this ? And if so,
Is there a volunteer in the house ?
--
Ronald Khoo <ron...@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)

Daniel Smith

unread,
Jul 1, 1991, 8:25:59 PM7/1/91
to

> In article <1991Jun28.2...@convex.com> tch...@convex.COM (Tom Christiansen) writes:
> What do you want added for a commercial product? Something you can
> hand over to kindergarteners?

> Basically, yes, I want something you can hand over to kindergarteners.

Then give them Logo, not Perl.

I'd show perl to, say, a 6th grader. I'd say Perl is fairly mature,
considering how long it has been out. Remember, C wasn't built in a day.

Daniel
--
dan...@island.com .....Daniel Smith, Island Graphics, (415) 491 0765 x 250(w)
dan...@world.std.com ...4000 CivicCenterDrive SanRafael MarinCounty CA 94903
dans...@well.sf.ca.us .I must write this, or Island will take away my coffee.
Could we continue with the petty bickering? I find it most intriguing-Data:TNG

Ted Stefanik

unread,
Jul 2, 1991, 1:42:02 AM7/2/91
to
You know, all this talk on how Perl could be better if it were a "product"
doesn't jive too well with the fact that most commercial "products" have an
incredibly large amount of bugs in them. I can't resist adding my two cents:


Let me ask and answer a few questions.

Have you ever upgraded to a new version of a commercial product? Or ported to
a different platform supporting the same version of a commercial product?
There are software companies with hundreds of millions in annual revenue that
routinely ship "products" whose bug track record in these regards makes Perl's
absolutely shine.

Have you ever ported Perl code to a different platform? Porting Perl always
takes about 30 predictable minutes. And the Perl code works with no surprises.
(I just finished a 5,000 line Perl program and ported it with NO problems to
DEC/Ultrix, Sun/SunOS4, Solbourne/SunOS4, HP-Apollo/Domain!). The "Portable" C
Compiler "Products" give me about 10 times as many portability fits as Perl
does.

Have you ever tried to do any substantial work with the awk "product" that is
shipped with UNIX? Now there is a robust "product"! :-(

Does your workstation's/computer's OS ever core dump? The operating system on
my workstations (from EVERY manufacturer that I've ever used) misbehaves
regularly, and it "panics" (i.e. dumps core) every month or so (sometimes even
more frequently). I assume that an operating system is one of the most tested
kinds of "product" that is out there. Did you every look at how poorly/messily
implemented a UNIX OS really is? Yuck! No wonder these "products" misbehave.


You know, I too wish Perl was more bug free, more stable, and easier to port.
(I'd probably even get my company to pay for it :-) For reference, in writing
that recent 5,000 line program, I discovered 3 probable bugs in 4.010 that I
had to work around.

However, romanticizing about how good "products" are ignores that fact that an
extremely small percentage of products are as good or better than Perl. Perl
is pretty well written, wonderfully documented, and bountifully supported by
this group.

In conclusion, I actually worry a little less about using Perl as a tool for
designing my company's products than most of the other tools and products that
I have to use.

PS: Thanks Larry, Randal, and comp.lang.perl!

Mark Harrison

unread,
Jul 2, 1991, 9:35:53 AM7/2/91
to
In article <1991Jul2.0...@uvaarpa.Virginia.EDU>
t...@evi.com (Ted Stefanik) writes:

[excellent comments about buggy "product" software]

>In conclusion, I actually worry a little less about using Perl as a tool for
>designing my company's products than most of the other tools and products that
>I have to use.

I have been pleased with Perl's quality of operation and the level of support
availible. The thing that worries me is that when something goes wrong
with the OS, etc, people tend to dismiss it as Standard Operating Procedure.
However, if Perl ever makes the slightest burp, people will be all over
my case for recommending "buggy freeware off the net."

I think it's some variation of the "nobody ever got fired for buying IBM"
syndrome. Larry, maybe if you had a special $100K version and hired
someone to load the tape and type "make"... :-)

>PS: Thanks Larry, Randal, and comp.lang.perl!

Amen!
--
Mark Harrison | Note: harr...@ssd.dl.nec.com and
harr...@csl.dl.nec.com | necssd!harrison are not operating at
(214)518-5050 | present. Please forward mail through the
| above address. Sorry for the inconvenience.

Dale Worley

unread,
Jul 2, 1991, 10:49:13 AM7/2/91
to
A bunch of replies:

To Ted Stfanik:

I don't know whose workstations you use, but we use Sun 3's and they
crash less on me than Perl does. And when they do, I just reboot and
re-run the program, and it works the second time. When Perl crashes,
it is reproducible, which is great for debugging Perl, but horrible
for building tools for the naive to use.

And there are some *excellent* products out there -- PC Lint comes to
mind. I'm not claiming that products are *necessarily* better, but
rather that above a certain level of effort, freeware cannot achieve
the necessary quality level, although products sometimes do.

To Tom Christiansen:


I suppose we could always bribe him. :-)

That would be a great idea, but it just wouldn't work. To maintain
Perl in reliable style would require Larry full-time (at least), and
we just can't afford that. If we were one of 100 customers, we could
afford our share, but we can't support him alone.

To Randall:


If every one of the 32,000 people that read comp.lang.perl were to buy
just *one* more copy of the Camel Book (or convince their employer or
school library to do the same), Larry would make enough money to spend
full time on Perl for the next 6-9 months (like he practically has
been for the last three years :-).

In reality, every one of the 32,000 people would have to buy a copy of
The Book every 6 months, in order to keep Larry paid. Unfortunately,
there is little incentive for any of them to do so, since the results
of his labor would be available for everyone. Hey, do you supply me
with a machine-readable text of The Book? :-)

Dale

Dale Worley Compass, Inc. wor...@compass.com
--

God appears to a lucky peasant to grant him his heart's desire, saying
only that whatever the peasant chooses, his neighbor will get two of.
After agonizing over his choice, the peasant says: "God, rip out one
of my eyes so that my neighbor goes blind."
-- Russian story, quoted in Hedrick Smith, "The New Russians"

Chris A. Anderson

unread,
Jul 2, 1991, 12:19:17 PM7/2/91
to
In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>Basically, yes, I want something you can hand over to kindergarteners.
>The following ideas come to mind:
>
>- New versions work, out of the box, on multiple architectures. (This
>demands a test suite perhaps an order of magnitude (or two) larger
>than the existing test suite, run on a couple of dozen architectures,
>for each release.) (By "work", I mean that code which worked
>correctly on old versions works correctly on the new version.)

I think that perl compiles and runs better "out of the box" than *any*
other product I have used: commercial or otherwise. At one time, I
had perl running on 16 different machines (including several SysIII
and one version 7 machine), and I rarely had any problems with porting
it -- even on computers that traditionally have given me fits with
porting.

As far as portability of scripts, with some very few exceptions you
can take any of the code I've written, plop it down on any of those
architectures, and expect it to run. The exceptions are where I've
knowingly used non-portable features without testing for it in an
eval, etc.

>- It *never* core dumps, and except in the most unusual circumstances,
>produces a usable error message.

That's my experience. At my last position, I had over 100,000+ lines
of code in production and I never saw a core dump. Of course, I take
*some* credit for that... :-) And the error messages beat the *hell*
out of "bailing out at or near line 23".

>- Enhancements that make the user's life better are made frequently.
>(Writing out "compiled Perl" is a prime example -- people are
>clamoring for it all the time, it would help enormously, but it would
>take a great deal of work to write and maintain and is technically
>uninteresting.)

Other than the "compiled perl" enhancement, what other enhancement has
not received serious attention from Larry? And more than a few have
made it into the release.

>The position I'm coming from is this: My company is starting to write
>some serious applications in Perl. This means that our continuing
>operation is going to be dependent on the proper functioning of Perl.
>Thus, we have a powerful need for Perl to be *dependable*. (That's
>why the many bugs reported in Perl 4 disturb me -- how reliable is it,
>anyway?) We would also like to not have to dedicate programmers to
>keeping Perl running -- we need software that works consistently, out
>of the box.

Honestly, do you really get this from most commercial software? I've
been in the position of supporting several commercial packages, and
I've often wished that they had support as good as perl. The bugs
we've seen are no worse than any commercial package I've seen, and
in most cases the bugs are fixed within *days* rather than some random
amount of time in the future.

>Providing this level of reliability requires more work on the part of
>the development operation than Larry can afford, really. However, if
>it were available, we would gladly pay for it (at usual
>commercial software prices).

Somehow, Larry *has* managed to provide this level of support. I
don't know if he can keep it up (or wants to, for that matter), but
for the moment perl is one of the shining examples of software on
the net.

Chris
--
+------------------------------------------------------------+
| Chris Anderson, Unify Corp. c...@unify.com |
+------------------------------------------------------------+

Sid Stuart

unread,
Jul 2, 1991, 1:09:27 PM7/2/91
to


>Which is yet another glib answer that buys us nothing,
>although I guess it might buy Larry a lunch. Anybody
>have any bright ideas on this?
>
>--tom
>
>

Does anyone know where one sends suggestions for MacArther
Foundation grants? They gave one to Richard Stallman,
they might spring some money for Larry.

--
Sid Stuart, Thinking Machines Corp.

s...@think.com
{uunet,harvard}!think!sid

David Boles

unread,
Jul 2, 1991, 4:00:08 PM7/2/91
to
Hello,

I am trying to have my perl script (my first of any size) ftp to
another computer to establish a connection, and upload some files,
(at least this is the kernel of the idea) running unattended.
How should I approach this? I would sort of like to start up the
ftp command with a open(PIPE,"ftp blah |"); command and then be able
to read from the characters being sent back to me, as well as send
characters to the other machine through the ftp link, i.e., just
like I was doing it myself.

Sorry if it's obvious, thanks for the help.

David Boles

--
-------------------------------------------------------------------------------
David Boles Applied Research Laboratories
dbo...@ccwf.cc.utexas.edu
apa...@chpc.utexas.edu This space for rent, apply within.
-------------------------------------------------------------------------------

Paul O'Neill

unread,
Jul 2, 1991, 4:09:11 PM7/2/91
to
In article <1991Jul2.1...@Think.COM> s...@think.com writes:
>
>Does anyone know where one sends suggestions for MacArther
>Foundation grants? They gave one to Richard Stallman,
>they might spring some money for Larry.
>

Send the poems to the NEA.


Paul O'Neill--Coastal Imaging Lab p...@oce.orst.edu DoD 000006
OREGON STATE UNIVERSITY
OCEANOGRAPHY ADMIN BLDG 104
CORVALLIS OR 97331-5503 503-737-3251

-=Runaway Daemon=-

unread,
Jul 2, 1991, 4:14:41 PM7/2/91
to
In article <b15...@Unify.Com> c...@Unify.Com (Chris A. Anderson) writes:
>In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>>- It *never* core dumps, and except in the most unusual circumstances,
>>produces a usable error message.
>
>That's my experience. At my last position, I had over 100,000+ lines
>of code in production and I never saw a core dump. Of course, I take
>*some* credit for that... :-) And the error messages beat the *hell*
>out of "bailing out at or near line 23".
>
Just thought I should mention here that if you take any tiniest piece of
chat2.pl code and try to run it on anything less than patchlevel 44
it WILL core dump. It was driving me up the wall as all my other scripts
work ot Plevel 41 and none of the most useful stuff with chat works..

Such is life.. Other than that, I agree with most everything else in this
thread..

ian

-=Runaway Daemon=-

-=Runaway Daemon=-

unread,
Jul 2, 1991, 4:41:49 PM7/2/91
to
I am submitting this working script with a question or two.
This script when fed a standard mailbox file will ouput something like
this.
1 From: mooree@tramp (MOORE ERIC S)
2 From: frec...@snoopy.Colorado.EDU Subject: Reading..
3 From: uma...@cc.ic.ac.uk Subject: Re: HP28S FAST PROGRAM
4 From: ude...@copper.Denver.Colorado Subject: Re: Hey there.
5 From: frechett@spot Subject: Fun fun fun
6 From: ALLE...@bronze.Colorado.EDU Subject: ST:TCG THE STORM BEFORE THE C
7 From: zecca@tramp (Emulator of Borg Subject: ST:TCG (LONG!)
8 From: ALLE...@bronze.Colorado.EDU Subject: THE STORM BEFORE THE CALM, PAR
9 From: ALLE...@bronze.Colorado.EDU Subject: THE STORM BEFORE THE CALM, PAR
10 From: bidwell (Teri Bidwell) Subject: Enjoy the party?
11 From: crawford Subject: irc question
12 From: allenmk@tramp (ALLEN MELINDA Subject: THE STORM BEFORE THE CALM, PAR
13 From: s89...@minyos.xx.rmit.OZ.AU Subject: Current GRAD list: please upda
14 From: s89...@minyos.xx.rmit.OZ.AU Subject: grad list (again)

It hasn't chocked on anything yet..
Quesions at the end..

#!/usr/bin/perl
# SMail by Ian Frechett
# Will show <number> <Who from> and <subject> of each message from a
# standard mailbox file in a nice format.

$|++; # Non Blocked output
$count = 0; # Init counter
while (<>) {
chop; # Kill newline
if (/^From\ / & /[0-9]/) { $count++;} # Inc counter at new message
# [0-9] is to check for Date field
# Store only first Subject: line for this message number reads:
# if Starts with Subject: and no Subject yet, Store this as Subject.
elsif (/^Subject:\ /) { if (!($Subject[$count])) {$Subject[$count] = $_;} }
# Store only first From: line for this message number
elsif (/^From:\ /) { if (!($From[$count])) { $From[$count] = $_; } }
}

for (1..$count) {
$frm = substr(join('',"$From[$_]"," " x 35),0,35); #Format From: line
$subj = substr($Subject[$_],0,39); #Format Subject: line
printf("%3s %35s %s\n",$_, $frm,$subj); #Print line
}


This whole thing is very effective but I *think* deathly slow.. I have a
feeling that it could be much faster. I would like to know if anyone
here sees a way to speed this up some. One thing to consider is that I
don't want to slurp the whole file into a variable as it uses
increadible amounts of memory. For a while I had 13,000 lines in my
mailbox.. Now it is down to 5000 and it is still running very slow.
Also, I cannot take the address from the From<space> header but it has to be
used for an accurate count of messages.

Any help would be appreciated..

ian

-=Runaway Daemon=-

Alex Martelli

unread,
Jul 2, 1991, 1:54:36 PM7/2/91
to
tch...@convex.COM (Tom Christiansen) writes:
...
::> open(foo) || die "Can't open $foo: $!";

::>(but which I find to be just hackeritis show-off).
::I don't understand -- I use this all the time. really. what's the
::problem?
:Perhaps those folks not heavily into shell programming do not take well
:to using && and || for flow control. But those who are, do, and are
:glad it's there.

Us closet ICON fen also love the 'do-this OR stop' idiom.
ADAers might also get to love it, by pronouncing '||' as OR ELSE, not so?
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) mart...@cadlab.sublink.org, (home:) al...@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).

David Muir Sharnoff

unread,
Jul 2, 1991, 5:54:54 PM7/2/91
to
In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>That would be a great idea, but it just wouldn't work. To maintain
>Perl in reliable style would require Larry full-time (at least), and
>we just can't afford that. If we were one of 100 customers, we could
>afford our share, but we can't support him alone.

Perhaps Larry could offer a support contract.

I just asked my boss (he has spending athority) and he seemed
agreeable to a $1-$2k/yr site support contract.

If enough of us are willing to toss in a few K, then we would
represent a serious proposition for Larry.

-Dave
--
David Muir Sharnoff. "RISC is about one year ahead"
mu...@csi.com (415) 358-3664 (415) 644-0441
Comdisco Systems Inc. 919 East Hillsdale Blvd, Foster City, CA 94404

Tom Christiansen

unread,
Jul 2, 1991, 7:18:01 PM7/2/91
to
From the keyboard of frec...@spot.Colorado.EDU (-=Runaway Daemon=-):
:I am submitting this working script with a question or two.

First, ten quick general observations:

1) You don't need to store the things in an array; just print
them when you find them.

2) for (1..$count) is slow for large $count.

3) When appending to an array, push is much faster.

4) When you see [$i] stuff in a perl script, it usually means
you not doing things the Perl way.

5) You should only be processing header lines if they're really
in the header.

6) That's a heck of a way to extract a 35space padded subject.

7) Printfs are kinda expensive, and largely unneeded.

10) This is just crying for formatted i/o.


Here's how I would have done it:

#!/usr/bin/perl
$/ = ''; # paragraph input mode
$* = 1; # ^ and $ match within strings

while (<>) {
next unless /^From /;
$count++;
s/\n\s+/ /g; # fix continuation lines
($subject) = /^subject:\s*(.*)/i;
($from) = /^from:\s*(.*)/i;
write;
}

format STDOUT =
@>> From: @<<<<<<<<<<<<<<<<<<<<<<<<<<<< Subject: @<<<<<<<<<<<<<<<<<<<<<<<<<<<<
$count, $from, $subject
.


This runs several times faster.

And yes, of course I was talking octal. :-)

Doug DeJulio

unread,
Jul 2, 1991, 11:49:35 PM7/2/91
to
In article <11...@charm.csi.com> mu...@cae780.csi.com (David Muir Sharnoff) writes:
>Perhaps Larry could offer a support contract.
>
>I just asked my boss (he has spending athority) and he seemed
>agreeable to a $1-$2k/yr site support contract.

How many of you folks clamoring for Perl support have contacted the
Cygnus folks about it? This is just the sort of thing they exist for.
--
Doug DeJulio
d...@zardoz.club.cc.cmu.edu (NeXT mail)
dd...@andrew.cmu.edu (AMS/ATK mail)

Tom Christiansen

unread,
Jul 2, 1991, 8:14:35 PM7/2/91
to
From the keyboard of frec...@spot.Colorado.EDU (-=Runaway Daemon=-):
:Just thought I should mention here that if you take any tiniest piece of
:chat2.pl code and try to run it on anything less than patchlevel 44
:it WILL core dump. It was driving me up the wall as all my other scripts
:work ot Plevel 41 and none of the most useful stuff with chat works..

I know what you mean. Right now I can't install 4.03 because we've
production code that breaks at 4.010, but I've got programs that will
coredump except at 4.010. The only "just check $]" suggestion doesn't
work because the parser might choke. Try running code using the
require operator through 3.018 for example, or try using $] numerically
a while ago.

Here's a work-around. Surround all your scripts with this
and you may be happier. Make sure to set version and patchlevel
appropriately for each script. This is nice cause it doesn't care
where perl is on your system, plus it will do something useful even
with old perls if your program uses new syntactic constructs.

--tom

#!/bin/sh -- need to mention perl here to avoid recursion

'true' || eval 'exec perl -S $0 $argv:q';
eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
& eval 'exec /usr/bin/perl -S $0 $argv:q'
if 0;


VERSION_SANITY: {
$PERL_PATH = '/usr/local/bin/perl';
local($version, $patchlevel) = (4, 10);

local($want_vp) = sprintf("%d.%03d", $version, $patchlevel);
local($need_perl) = $PERL_PATH . $want_vp;

die "can't get version"
unless $] =~ /(\d+\.\d+).*\nPatch level: (\d+)/;

if ($1 < $version || $2 < $patchlevel) {
local($got_vp) = sprintf("%d.%03d", $1, $2);
if (-e $need_perl) {
warn "current perl version ($got_vp) too low, execing perl v4.010";
exec $need_perl, $0, @ARGV;
die "exec of $need_perl failed: $!";
} else {
warn "WARNING: perl version too low: $got_vp < $want_vp; good luck...\n";
}
}
}

eval <<'___VERSION_SANITY___';

# BEGIN REAL PROGRAM

asdfasd
print "hello world!\n";

# END REAL PROGRAM

___VERSION_SANITY___

die "$0: OOPS, YOU LOSE: $@" if $@;

exit 0;

########## CLIP HERE ##############
--
"GUIs normally make it simple to accomplish simple actions and impossible
to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)

Tom Christiansen tch...@convex.com convex!tchrist

Ed Vielmetti

unread,
Jul 3, 1991, 1:07:05 AM7/3/91
to

How many of you folks clamoring for Perl support have contacted the
Cygnus folks about it? This is just the sort of thing they exist for.

How many of the Cygnus folks have been posting perl poems? I don't
have the sense (please correct me if I'm wrong) that they have any
special expertise or knowlege about perl beyond what the rest of us
have.

--Ed

Barry Schwartz

unread,
Jul 2, 1991, 10:07:31 PM7/2/91
to
dan...@world.std.com (Daniel Smith) writes:

] In <WORLEY.91...@sn1987a.compass.com>
] wor...@compass.com (Dale Worley) writes:

] > In article <1991Jun28.2...@convex.com>
] > tch...@convex.COM (Tom Christiansen) writes:
] > What do you want added for a commercial product? Something you can
] > hand over to kindergarteners?
]
] > Basically, yes, I want something you can hand over to kindergarteners.

Something more like Awk, I suppose. I was amused when it was
suggested that Perl would be a more proper addition to Unix
if it were made more like an MSDOS application. I have to admit
that there's a lot to be said for making software accessible,
but I'd say Perl was a lot more accessible than much of Unix!
The manpage is no worse documentation than any Awk manpage I've
seen; I'd say it was better.

] Then give them Logo, not Perl.

That depends on what the kindergarteners are supposed to be
doing. If they are fingerpainting with computers, give them
Logo. If they are writing install scripts, give them Perl.
Me, I think I'd give them modeling clay. They get dirtier
with clay than with computers, and getting dirty is good for
a five year old.

--
Barry Schwartz b...@hankel.rutgers.edu tras...@crud.UUCP

Root Boy Jim

unread,
Jul 3, 1991, 2:06:17 AM7/3/91
to
Let me congratulate (I believe it was Dale) on the choice of
the subject line: a camel is a ruminant!

tch...@convex.COM (Tom Christiansen) writes:
>From the keyboard of rod...@dali.ipl.rpi.edu (Rodney Peck II):
>:ru...@groan.Berkeley.EDU (Rusty Wright) writes: [right:-]
>:>Similarly, in the "Syntax" section are examples for opening "foo" and
>:>dying if it can't be opened, with the classic
>:>


>:> open(foo) || die "Can't open $foo: $!";
>:>
>:>(but which I find to be just hackeritis show-off).
>:
>:I don't understand -- I use this all the time. really. what's the
>:problem?
>
>Perhaps those folks not heavily into shell programming do not take well
>to using && and || for flow control. But those who are, do, and are
>glad it's there.
>

>--tom
>--
>Tom Christiansen tch...@convex.com convex!tchrist
> "So much mail, so little time."

C has this construct, probably before sh did.
It's NOT hackeritis, it's saying what you mean, briefly.

I'll go one step further: If statements are for unstudly dweebs
who can't think anyway but linearly. Get hip to symbols.

I rarely use them when || or && will do.
I only wish we had a construct that replaced `while',
something like: p[n] !! (q[n] = p[n], n++);

However, I usually avoid:

(cond) && {
true; stuff;
} || {
false; stuff
}

If I need to get that elaborate, I'll spring for the if-else.

I have much more on this subject to say,
but this will have to do for now.
--
[rbj@uunet 1] stty sane
unknown mode: sane

Root Boy Jim

unread,
Jul 3, 1991, 2:29:35 AM7/3/91
to
In article <1991Jul2.0...@uvaarpa.Virginia.EDU> t...@evi.com (Ted Stefanik) writes:
>You know, all this talk on how Perl could be better if it were a "product"
>doesn't jive too well with the fact that most commercial "products" have an
>incredibly large amount of bugs in them. I can't resist adding my two cents:

Not to mention that some products are just plain designed wrong.

Simply stated, the net supports products better than any vendor can.
In fact, vendor support is almost an oxymoron. They just don't
have the resources. I frequently talk to people who know less
than I do about the software they sell.

Now I'm going to put Tom on the spot. Convex ships perl. However,
I would think that they view it more as a public service, kind
of a UCS (user contributed software) kind of thing. Now Tom reads
this group and helps people out, customers and heathens alike.

My question to Tom is: do you consider what you do part of the
former (the net) or the latter (vendor support)? Why?

Dale Worley

unread,
Jul 3, 1991, 11:08:05 AM7/3/91
to
In article <b15...@Unify.Com> c...@Unify.Com (Chris A. Anderson) writes:
I think that perl compiles and runs better "out of the box" than *any*
other product I have used: commercial or otherwise.

Well, the PC software I've used works when I put the disk into the
drive. On the other hand, I'm not about to install Perl 4 until I
stop seeing messages like "Perl 4 patchlevel 10 doesn't compile on
Ultrix 4.1". And I have been able to coredump Perl while running a
simple read-eval-print loop. It proved damned annoying.

I just looked at the Subject: lines of the last 318 messages on
comp.lang.perl. 93 of them seemed to be about bugs (or what people
thought were bugs), most of them about difficulties in building on
specific platforms.

Dale Worley Compass, Inc. wor...@compass.com
--

The genius of you Americans is that you never make any clear-cut
stupid moves, only complicated stupid moves that leave us scratching
our heads wondering if we might possibly have missed something.
-- Gamel Abdel Nasser

Paul Lyon

unread,
Jul 3, 1991, 1:45:26 PM7/3/91
to
In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>Well, the PC software I've used works when I put the disk into the
>drive. On the other hand, I'm not about to install Perl 4 until I
>stop seeing messages like "Perl 4 patchlevel 10 doesn't compile on
>Ultrix 4.1". And I have been able to coredump Perl while running a
>simple read-eval-print loop. It proved damned annoying.

It strikes me that this is not a useful comparison in the present
context. The authors of the PC software do not have to cope with
the vagarities of the C compilers, compiler libraries, and the like
on the various UNIX boxes; those trying to get perl up and running
on UNIX systems do. Those writing PC software do have to cope with
differences in hardware, but they are aided by the competitive
pressures in the PC market towards compatibility, and as just noted
they distribute executables, not source.

Paul Lyon

Doug Roberts

unread,
Jul 3, 1991, 2:49:14 PM7/3/91
to
Much of the "Ruminations" posted here recently fall into a category
that I call "whining, bitching, & moaning".

Or, to put it another way, if any of _our_ customers carried on like
that when new versions our product was released to them, I would spank
them and send them to bed without their supper.

Trust me on this one, fellas: PERL IS AN EXCELLENT PRODUCT! The fact
that new versions sometimes present backward compatibility problems is
an expense you incur for using a dynamic, growing product. (It, by
the way, is the _only_ expense you incur, because as you may have
noticed, Perl is FREE!)

RE: support -- I get much better support for Perl via the net
than I have ever gotton for _ANY_ Unix software that I've purchased
during the past six years.

So, if I may suggest to you complainers (in the _friendliest_ of
fashions, of course [1/2 :-)]): Lighten up, wise up, and grow up.

While I'm at it, Atta boy Larry! Non carborundum illigitimi.

--Doug
--

================================================================
Douglas Roberts
Los Alamos National Laboratory
dz...@lanl.gov

^C^C ^X^C ^X^Z :w :q :wq :wq! ^d X exit
X Q :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT
^[zz ^[ZZ ZZZZ ^H ^@ ^L ^[c ^# ^E ^X ^I ^T ?
help helpquit ^D ^d ^C ^c helpexit ?Quit ?q ^Kx /QY
sync;halt

Chip Salzenberg

unread,
Jul 3, 1991, 2:13:16 PM7/3/91
to
According to wor...@compass.com (Dale Worley):

>Basically, yes, I want something you can hand over to kindergarteners.
>The following ideas come to mind:
>
>- New versions work, out of the box, on multiple architectures.
>- It *never* core dumps ...

Fine.

>- Enhancements that make the user's life better are made frequently.

Whoa. This desire contradicts the first two.
--
Chip Salzenberg at Teltronics/TCT <ch...@tct.com>, <uunet!pdn!tct!chip>
"You can make use of the fact that UDP does not provide `reliable and
efficient streams' to eliminate the state, but then you are unreliable
and inefficent. There Ain't No Such Thing As A Free Lunch." -- Chris Torek

Raul Rockwell

unread,
Jul 4, 1991, 3:28:05 PM7/4/91
to
Dale Worley:

Well, the PC software I've used works when I put the disk into the
drive.

Well, the perl 4.10 that I've used works without even putting a disk
in the drive. Of course, I did have to ftp it, and then I had to run
a command like this:
find . -name 'perl.kit??' -exec {} ';' && Configure && make >log depend all test install &

And I had to verify that some guesses were correct. This seemed no
harder to me than installing a decent sized program on a PC.

On the other hand, I'm not about to install Perl 4 until I stop
seeing messages like "Perl 4 patchlevel 10 doesn't compile on
Ultrix 4.1". And I have been able to coredump Perl while running a
simple read-eval-print loop. It proved damned annoying.

I've got a friend who works for DEC -- he says Ultrix is all right.
Says the machine that I'm working on is a royale pain. Go figure.

I just looked at the Subject: lines of the last 318 messages on
comp.lang.perl. 93 of them seemed to be about bugs (or what people
thought were bugs), most of them about difficulties in building on
specific platforms.

Gee, you expect to see reports that bugs don't exist? Ok, here goes:
The other day, I ran a perl program and nothing went wrong. I'm running
Perl 4.10 on an HP 9000/835 under hpux.

--
Raul <rock...@socrates.umd.edu>

Johan Vromans

unread,
Jul 5, 1991, 3:14:52 AM7/5/91
to

In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
| ... On the other hand, I'm not about to install Perl 4 until I

| stop seeing messages like "Perl 4 patchlevel 10 doesn't compile on
| Ultrix 4.1".
| ...

| I just looked at the Subject: lines of the last 318 messages on
| comp.lang.perl. 93 of them seemed to be about bugs (or what people
| thought were bugs), most of them about difficulties in building on
| specific platforms.

Compiling perl triggers some nasty bugs in some Unix implementations
or compilers (e.g. Ultrix). It is not fair to blame perl for this...

Johan
--
Johan Vromans j...@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------

Dale Worley

unread,
Jul 5, 1991, 11:24:58 AM7/5/91
to
In article <51...@ut-emx.uucp> pl...@ut-emx.uucp (Paul Lyon) writes:
It strikes me that this is not a useful comparison in the present
context. The authors of the PC software do not have to cope with
the vagarities of the C compilers, compiler libraries, and the like
on the various UNIX boxes; those trying to get perl up and running
on UNIX systems do. Those writing PC software do have to cope with
differences in hardware, but they are aided by the competitive
pressures in the PC market towards compatibility, and as just noted
they distribute executables, not source.

Your analysis is quite accurate, but misses my point: I want the
vendor to handle such hassles (as they do now when they distribute
binaries), rather than myself. This would be far cheaper for my
company.

Dale Worley Compass, Inc. wor...@compass.com
--

Americans eat about one pound of insects per year. -- Todd Kaufmann

Joe Wells

unread,
Jul 5, 1991, 11:25:21 PM7/5/91
to
In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:

I'm not claiming that products are *necessarily* better, but rather
that above a certain level of effort, freeware cannot achieve the
necessary quality level, although products sometimes do.

I see no evidence for this statement. Some "products" appear better
because they hide the bug list.

--
Joe Wells <j...@uswest.com>

Joe Wells

unread,
Jul 5, 1991, 11:18:13 PM7/5/91
to
In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:

- It *never* core dumps, and except in the most unusual circumstances,
produces a usable error message.

What world is this from? I know how to core dump more than half of the
programs in SunOS 4.1, some of them more than one way (csh doesn't count).
Would you say then that SunOS 4.1 is not commercial quality?

The operating system itself panics (and "dumps core") about once a month.

And Sun charges a *lot* for support.

--
Joe Wells <j...@uswest.com>

Joe Wells

unread,
Jul 5, 1991, 11:20:43 PM7/5/91
to
In article <b15...@Unify.Com> c...@Unify.Com (Chris A. Anderson) writes:

I've often wished that they had support as good as perl. The bugs
we've seen are no worse than any commercial package I've seen, and
in most cases the bugs are fixed within *days* rather than some random
amount of time in the future.

I believe the speed with which important bugs are squashed is the most
amazing thing about Perl.

--
Joe Wells <j...@uswest.com>

Ted Lemon

unread,
Jul 6, 1991, 5:39:35 AM7/6/91
to

In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
>I'm not claiming that products are *necessarily* better, but rather
>that above a certain level of effort, freeware cannot achieve the
>necessary quality level, although products sometimes do.

Hm. Dale, consider that SunOS, Ultrix, AIX and OSF/1 are all
products. Now, consider that 4.4 BSD is *not* a product. Which would
*you* rather be running?

_MelloN_

Brandon S. Allbery KF8NH

unread,
Jul 6, 1991, 12:35:27 PM7/6/91
to
As quoted from <WORLEY.91...@sn1987a.compass.com> by wor...@compass.com (Dale Worley):
+---------------

| In article <b15...@Unify.Com> c...@Unify.Com (Chris A. Anderson) writes:
| I think that perl compiles and runs better "out of the box" than *any*
| other product I have used: commercial or otherwise.
|
| Well, the PC software I've used works when I put the disk into the
| drive. On the other hand, I'm not about to install Perl 4 until I
| stop seeing messages like "Perl 4 patchlevel 10 doesn't compile on
| Ultrix 4.1". And I have been able to coredump Perl while running a
| simple read-eval-print loop. It proved damned annoying.
+---------------

Not to mention that, during my net.absence, I've been regularly panic-ing it
on a local(). (I'm still trying to trace it; all I know so far is that it's
griping about local() on a string tagged as "free".)

(I won't comment on the original poster' product as compared to Perl. :-)

++Brandon
--
Me: Brandon S. Allbery KF8NH: DC to LIGHT! [44.70.4.88]
Internet: all...@NCoast.ORG Delphi: ALLBERY
uunet!usenet.ins.cwru.edu!ncoast!allbery

Richard Harter

unread,
Jul 7, 1991, 12:56:53 AM7/7/91
to
In article <1991Jul06.2...@eng.umd.edu>, str...@eng.umd.edu (Joshua Osborne) writes:
> In article <WORLEY.91...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
> [...]

> >Your analysis is quite accurate, but misses my point: I want the
> >vendor to handle such hassles (as they do now when they distribute
> >binaries), rather than myself. This would be far cheaper for my
> >company.

> If you do this you will be lucky to see a new version of perl every year (as
> a bundled product), or every 6 months (unbundled). I'm sure you can find
> someone who will ship you 2 working perl's a year for lots of money.

Which is indeed what a lot of companies want. Among all software users
there is always a leading edge that is willing and able to work with
the latest, newest, and maybe best. Perl users, to date, tend to be
leading edge users. The bulk of users are more conservative -- they
don't adopt the latest technologies as they come and they don't turn
over software versions very fast -- if it ain't broke, don't fix it.
Neither group is wrong. It's all a question of the tradeoffs between
the advantages of innovation and the cost of innovation. People will
use GCC as the vendor ships it whereas they wouldn't go out and acquire
it on their own.
--
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb. This sentence short. This signature done.

Roger Droz

unread,
Jul 8, 1991, 5:36:18 PM7/8/91
to

I'm amazed too! How do people like Larry, Henry Spencer, and a few
others manage to create and support "neat things like Perl" and still
have time to do their "day jobs"?

More power to them. I'm just looking to the wizzards for career advice,
as well as Perl advice. (-;
____________
Roger Droz Domain: ro...@mav.COM
() () Maverick International UUCP: uw-beaver!gtisqr!roger
(_______) Mukilteo, WA
( )
| | Disclaimer: "We're all mavericks here:
| | Each of us has our own opinions,
(___) and the company has yet different ones!"

Mike McNamara

unread,
Jul 9, 1991, 7:30:40 PM7/9/91
to

Perl worked straight out of the box on Stardent machines,
except for two bugs in our system software.

One was in our dbm library. Perl ran into it, and I can't
figure out how to regenerate it with a C program. We have fixed the
dbm bug though.

The other is kind of a feature. John Reiser rewrote cpp for
us ( when we were Ardent) and he wanted cpp to replace strings within
"quotes." This is nonstandard, and perl notices.

-mac
--
+-----------+-----------------------------------------------------------------+
|m...@kpc.com| Increasing Software complexity lets us sell Mainframes as |
| | personal computers. Carry on, X windows/Postscript/emacs/CASE!! |
+-----------+-----------------------------------------------------------------+

Colin Plumb

unread,
Jul 11, 1991, 5:00:55 PM7/11/91
to
In article <MELLON.91...@nigiri.pa.dec.com> mel...@nigiri.pa.dec.com (Ted Lemon) writes:
>Hm. Dale, consider that SunOS, Ultrix, AIX and OSF/1 are all
>products. Now, consider that 4.4 BSD is *not* a product. Which would
>*you* rather be running?
>
> _MelloN_

I'd rather be running 4.4BSD, of course! Vapourware is invariably
better then anything currently existing, and is characterised by a lack
of bugs. I've got a lot of vapour hardware lying around I can run it
on, but I can't seem to get paid for doing vapour work on it... :-)
--
-Colin

Larry Wall

unread,
Jul 12, 1991, 9:09:45 PM7/12/91
to
In article <WORLEY.91J...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
: I've been giving some thought to the future of Perl. Of course, these
: comments are a mite arrogant, but at least they may help Larry plan.

All language designers are arrogant. Goes with the territory... :-)

: Probably the best thing for the long-run health of Perl (although the
: worst for everybody now involved with it) is to scrap it and redesign
: (and reimplement) it from the ground up. Having implemented and used
: Perl, we now know *what it should have been*.

I think you'll find that, while we all know what it should have been,
we all know it should have been something different from what everybody
else things it should have been.

: In my opinion, Perl's biggest weaknesses are (1) its syntax is
: fantastically complex (consider the multiple meanings of / and $), and
: (2) it is a collection of features more than a coherent language for
: expressing algorithms.

Unfortunately, these are also Perl's biggest strengths. If you cure Perl's
biggest weaknesses, you'll also cure it's biggest strengths. Then we'll
basically be back where we started.

The purpose of Perl is to systematize Unix culture. To do that, you have
to use the syntax of Unix culture. That one fact drove nearly the entire
design of the language. It may be that Loglan is more precise and more
consistent than English, but I don't see people abandoning English for
Loglan in large numbers. It's just too foreign. Getting people to
learn and use "Standard English" is trivial by comparison. Perl is
kinda like "Standard Unix".

Much as I hate to say it, the Computer Science view of language design has
gotten too inbred in recent years. The Computer Scientists should pay
more attention to the Linguists, who have a much better handle on how
people prefer to communicate.

: However, rebuilding Perl is quite impractical. Not only would it
: involve an enormous amount of work, all existing Perl code would have
: to be rewritten.

So write a translator. I delayed the public release of Perl until I had
a2p and s2p. I didn't want people to have that excuse for not migrating.

: The other idea I have for the future of Perl is that it is now
: undergoing the transition from a "program" to a "program product".
: This means that the users are demanding that it be much more reliable,
: understandable, and portable than ever before. And, as Brooks noted,
: it takes about three times as much effort to produce a program product
: as to produce a program. (Consider the number of bugs and
: difficulties that version 4 is having, because of the number of users
: exercising it.) Where is all of this effort going to come from? Can
: we really expect Larry to devote the rest of his life to maintaining
: Perl?

The difficulties of 4.010 stem from two sources. First, I've thrown a
few long-desired optimizations in that busted things. Optimizations always
bust things, because all optimizations are, in the long haul, a form of
cheating, and cheaters eventually get caught.

The other reason for the difficulties is that it's become about 4 times
harder to write portable code since all these new standards came out.
For each new standard, there are those that haven't implemented it, those
that have implemented part of it and indicate they've implemented all of it,
those that have implemented almost all of it but don't indicated that they've
implemented any of it, those that have implemented more than the standard
but only indicate they've implemented the standard, and those that have
implemented the standard in a buggy fashion. There are n different ways
of indicating you've implemented part of the standard. Nobody's solved
the basic problem that the C preprocessor thinks it's a fatal error for
an include file not to exist. Nobody's solved the other basic problem
that the C preprocessor can't tell which routines and types are available
to the compiler.

: In order for Perl to take its rightful place as a standard Unix tool,
: it needs to become a product. However, I can't see how to finance the
: large amount of work that is going to be necessary on a continuing
: basis.

I think the answer is to distribute the work better. Putting the hints
stuff into Configure is a step in that direction--you guys can exchange
hints files without me moderating the mess. Not everything in Configure
can be driven with hints yet, however. Configure should really be
written in Perl, but there's this little bootstrapping problem... :-)

Larry

Larry Wall

unread,
Jul 12, 1991, 10:09:00 PM7/12/91
to
In article <RUSTY.91J...@groan.Berkeley.EDU> ru...@groan.Berkeley.EDU (Rusty Wright) writes:
: I suppose everyone has their list of what they'd like to see done to
: improve perl. This list is what I dislike about perl; things that I
: consider to be bad design and unnecessarily confuse new (and old) perl
: users. It often seems to me that perl is one big hoary blob of
: creeping featurism.

That's okay as long as the features creep in the right direction... :-)
Or are you saying that evolution can't produce something nice? Wait
till I tell my wife...

: I'll reference the perl man page here as that's
: what I'm using to jog my memory.
:
: 1) The man page gives too many ways to do the same thing, for no
: apparent reason other than hackeritis. For example, towards the end
: of the "Data Types and Objects" section are some examples that are
: preceded by the sentence "Anyway, the following lines are equivalent
: to each other" and the first example is
:
: while ($_ = <STDIN>) { print; }
:
: and the last is
:
: print while <STDIN>;

Some people think in terms of transformations--I guess I'm one of
them. I like to know which things are equivalent. That's how you do
algebra, after all.

: Similarly, in the "Syntax" section are examples for opening "foo" and


: dying if it can't be opened, with the classic
:
: open(foo) || die "Can't open $foo: $!";
:
: (but which I find to be just hackeritis show-off).

Heaven knows I show off often enough, but this ain't one of them. [I
presume you're referring to the || construction, and not the abominable
fact that open(foo) implicitly references $foo, which is merely
grandfathered in because that was the only way to open files in Perl
version 1.]

Perl gives you several ways to write conditionals because I feel it's
important for readability. I always put the important thing first,
and try to hide unimportant details to the right side of the screen.
In some conditional constructs, the conditional expression is the most
important. In others, it's the action that's important. I always write

open(FOO, "foo") || die "Can't open foo: $!\n";

because the open statement is the important thing. On the other hand,
I always write

print "Now we're starting the second pass\n" if $verbose;

because the print statement is the important thing, not the modifier.

: And then further on there are the various examples on the "foo:"
: block.
:
: I suppose one might argue that some of these wierd constructs execute
: faster than others; my response would be that programmers shouldn't be
: wasting their time tweaking their perl code to try to speed it up. In
: other words, perhaps perl needs more work in optimizing when it
: compiles.

Perl does a heck of a lot of work when it compiles. In fact, all those
different switch constructs compile down to the same thing, more or
less. The point of having those different constructs is not so that
you can optimize for speed. It's so that you can optimize for
readability, or writeability, or maintainability, or portability, or
familiarity, or editability by a particular editor, or, or, or...

Did you ever notice that there's more than one way to say something in
English? The following are more or less equivalent:

If you persist in your current actions, I shall have to terminate you.
Stop that, or I'll shoot!
Freeze! Police!

These are each optimal for different situations.

: 2) Functions as unary operators. Maybe I'm missing something here.
: In the paragraph that precedes the list of perl functions it says "If
: an operation is listed both with and without parentheses around its
: arguments, it means you can use it as a unary operator or as a
: function call." Now, tell me, when would I ever be required to or
: need to or want to use chdir as a unary operator? Seems to me they
: should all be functions.

Then write them all as functions, if it makes you happy. A lot of
shell programmers prefer

chdir "/tmp" || die "Can't cd to /tmp: $!\n";

: Towards the end of the man page there's the "Precedence" section which
: tries to explain this mess.

And says, if you write it like a function, it IS a function. What could
be simpler? If you prefer

print(join(' ', reverse(sort(grep(-T, @ARGV)))));

to

print join(' ', reverse sort grep(-T, @ARGV));

then go ahead and write in that way. Just don't show it to me when
my % key is busted. Some people optimize for lack of resemblance to LISP.

: 3) getpgrp and getppid: what's wrong with this picture? I was once
: trying to create a temporary file (wanting to use the process id for
: the file's name) and was amazed that perl doesn't have a getpid
: function. Then, when I was working on another perl program I stumbled
: across $$. I was so aggravated I swore out loud.

That's what the / key in your pager is for. Or grep. It so happens that
$$ interpolates into double quotes, and getpid doesn't. Guess where you
want your pid all the time?

: 4) last and next. What's wrong with using break and continue? Just
: seems like a gratuitous incompatibility with C, csh, awk, etc.

That has to do with loop labels. I much prefer

next FILE if -B;

to

continue FILE if -B;

and

last LINE if /^$/;

to

break LINE if /^$/;

It just maps into my English verbal apparatus much better. If you think
that's gratuitous, then you ought to feel some gratitude.

: 5) length should accept an array as an argument and return the number
: of elements in it. See for exmaple, tcl.

Perhaps on the do-what-I-expect principle. I can't think of any other
good reason to. Perl makes little attempt to treat arrays like scalars.

: 6) open. What a nightmare. I simply cannot believe that crap of
: putting >, <, and | into the EXPR argument for specifying redirecting
: input/output or piping to/from a command. I'd use the same syntax
: that fopen(3) uses and popen for piping to/from commands.

Gee, you wouldn't be a little prejudiced in favor of C, now would you?
Still and all, I agree that it's a bit baroque. Something I might do
differently next time. It's nice for feeding multiple input pipes
to a process that thinks it's reading files from the command line, though.

: 7) Predefined names; $_, $., et. al. This is a worse nightmare than
: open. What's the point of this? Hasn't anyone ever heard of using
: DESCRIPTIVE NAMES for variables? I like the man page's disclaimer,
: "Most of them have reasonable mnemonics, or analogues in one of the
: shells." Where's my barf bag.

So alias them.

*DEFAULT_INPUT_AND_PATTERN_MATCHING_VARIABLE = *_;
*CURRENT_LINE_NUMBER_OF_LAST_FILE_WE_READ_FROM = *.;

Make a library file of those, and post them. See how many people use it. :-)
Some people optimize for conciseness.

There's More Than One Way To Do It.

Love,
Larry

Marc Horowitz

unread,
Jul 13, 1991, 6:02:21 PM7/13/91
to

|> If you persist in your current actions, I shall have to terminate you.
|> Stop that, or I'll shoot!
|> Freeze! Police!

You forgot

You have twenty seconds to comply.

:-)

Marc

Brandon S. Allbery KF8NH

unread,
Jul 14, 1991, 8:46:28 AM7/14/91
to

As quoted from <1991Jul13.0...@netlabs.com> by lw...@netlabs.com (Larry Wall):
+---------------

| The other reason for the difficulties is that it's become about 4 times
| harder to write portable code since all these new standards came out.
+---------------

You mean I'm *not* imagining it? I've been wishing that someone had shot the
ANSI C and POSIX committees before they'd finished; writing things portable to
both the systems I use is a nightmare. :-( Yet another reason to use Perl.
:-) (And if an ANSI Perl committee ever shows up, I won't wait; I'll shoot
'em myself. :-)

+---------------


| can be driven with hints yet, however. Configure should really be
| written in Perl, but there's this little bootstrapping problem... :-)

+---------------

What you really need is a bootstrapping Perl subset written in awk. (But then
someone would a2p it and we'd have Perl in Perl :-)

Dale Worley

unread,
Jul 15, 1991, 4:48:13 PM7/15/91
to
In article <1991Jul5.0...@pronto.mh.nl> j...@mh.nl (Johan Vromans) writes:
Compiling perl triggers some nasty bugs in some Unix implementations
or compilers (e.g. Ultrix). It is not fair to blame perl for this...

True, but I'd rather than the vendor's staff had dealt with it and
sent me the binary, than having to think about it myself. And it
would be cheaper for my company.

Dale Worley Compass, Inc. wor...@compass.com
--

The question if a computer can think is as interesting as the question if
a submarine can swim. -- E. Dijkstra

Paul Vixie

unread,
Jul 16, 1991, 12:57:34 AM7/16/91
to
I usually stay out of Perl jihads, but this one is getting out of hand.
Besides, I've had too much coffee tonight :-). Forgive me, Larry, for
I am about to expostulate(*) on what I hope is your behalf...

[l...@chinet.chi.il.us (Leslie Mikesell) writes:]
# [...] To make perl become "Standard Unix" it
# needs to be as efficient as any other language as well as being easier
# to use. Plus, it needs to be linkable to "C" programs without a lot of
# extra work.

Perl is already standard UNIX. I'll bet somebody a dollar that there
are more systems running Perl than nawk, and many (many!) more programmers
able to get serious work done in Perl than in nawk.

Given that awk without functions is either an efficiency or coding (or
both) nightmare for projects of more than a thousand lines or so of code,
I'd say perl has won the battle for UNIX's scripting language.

Like lots of others in this forum, I would like to have a Perl compiler.
However, I don't think execing a separate binary for scripts which call
"eval" is the right solution. There are three worthwhile approaches:

(1) p-code. byte-compile the script to get the parsing into a fixed cost.
there's still the cost of the p-code interpreter, but on modern UNIX systems
the text is shared across all the processes that use it at any given time,
so it's still a fixed cost. note that the perl binary's text is already
shared if you are running a BSD or System V -derived UNIX.

(2) undump. we have this now, and there are versions of unexec() around
for 90% of the processors actually in use these days. if you think a perl
compiler would be able to successfully and portably target 90% of the proc-
essors in use today, even by generating C and calling the native compiler,
then you have not closely examined KCL, Scheme->C, or SRC Modula-3. in any
case, undump is inefficient since it creates nonsharable copies of the Perl
text segment. but it's there if you're desperate and can't wait for...

(3) shared libraries. generate C with lots of callouts for the hard stuff,
then link it against an enormous "libperl.so" that has eval and all the other
glorious goo that makes Perl so special. this would be a bit of work for
Larry, but since System V, OSF/1, and 4.4BSD will all have shared libs, the
chances of getting this to work in a large-scale way are fairly good.

Note that if you have a processor which is in the other 10% or for which
there will never be another OS release, which has a terrible C compiler
or will never have shared libraries, you can still run Perl scripts -- the
way we all run them now.

Of the three approaches, I prefer #3 since it lets loops get turned into
just a few instructions and could actually result in Perl number-crunchers
which were as fast as those written in C or Fortran or at least Pascal. If
your system vendor isn't planning on giving you shared libraries this year,
complain.

I kinda like the idea of replacing most of /bin with one- or five-line
Perl scripts. If nothing else it would keep Perl's text segment in memory
all the time.

(*)ex.pos.tu.late \ik-'spa:s-ch*-.la-t\ vb [L expostulatus, pp. of expostulare
to demand, dispute, fr. ex-)X + postulare to ask for obs : DISCUSS,
EXAMINE : to reason earnestly with a person for purposes of dissuasion or
remonstrance

Cheers,
--
Paul Vixie, DEC Western Research Lab
Palo Alto, California, USA "Be neither a conformist or a rebel,
<vi...@decwrl.dec.com> decwrl!vixie for they are really the same thing.
<pa...@vixie.sf.ca.us> vixie!paul Find your own path, and stay on it." (me)

John Macdonald

unread,
Jul 15, 1991, 10:54:12 AM7/15/91
to

In article <1991Jul13.0...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
|In article <WORLEY.91J...@sn1987a.compass.com> wor...@compass.com (Dale Worley) writes:
|: However, rebuilding Perl is quite impractical. Not only would it
|: involve an enormous amount of work, all existing Perl code would have
|: to be rewritten.
|
|So write a translator. I delayed the public release of Perl until I had
|a2p and s2p. I didn't want people to have that excuse for not migrating.

That's easy for you to say. For writing translator, you could
list the ease of trackability as:

Language Trackability

sed sitting duck
awk moving target
perl speeding bullet

I'd hate to be the one trying to generate a translator for
(shoot at) Perl. It wouldn't leave any time for writing
the target language of the translation.
--
Usenet is [like] the group of people who visit the | John Macdonald
park on a Sunday afternoon. [...] luckily, most of | jmm@eci386
the people are staying on the paths and not pissing |
on the flowers - Gene Spafford

Leslie Mikesell

unread,
Jul 15, 1991, 12:19:55 PM7/15/91
to
In article <1991Jul13.0...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>: In my opinion, Perl's biggest weaknesses are (1) its syntax is
>: fantastically complex (consider the multiple meanings of / and $), and
>: (2) it is a collection of features more than a coherent language for
>: expressing algorithms.

>Unfortunately, these are also Perl's biggest strengths. If you cure Perl's
>biggest weaknesses, you'll also cure it's biggest strengths. Then we'll
>basically be back where we started.

But there's no reason to put up with the weakness at runtime to obtain
the strengths.

>The purpose of Perl is to systematize Unix culture. To do that, you have
>to use the syntax of Unix culture. That one fact drove nearly the entire
>design of the language. It may be that Loglan is more precise and more
>consistent than English, but I don't see people abandoning English for
>Loglan in large numbers. It's just too foreign. Getting people to
>learn and use "Standard English" is trivial by comparison. Perl is
>kinda like "Standard Unix".

As such, it should exist as a translator from human coding to machine
coding. While it is nice to provide a syntax that encompasses nearly
everything in current use on the human side, it doesn't seem (to me)
like the best approach from the machine side to interpret that syntax
at runtime.

>So write a translator. I delayed the public release of Perl until I had
>a2p and s2p. I didn't want people to have that excuse for not migrating.

So how about narrowing the runtime interpretation to the most efficient
language possible and moving the kitchen-sink translator out to a separate
program that is exec'ed only when needed? Yes, it will probably screw
up programs that use 'eval' as an optimization until those evals are
written in the runtime language. To make perl become "Standard Unix" it


needs to be as efficient as any other language as well as being easier

to use. Plus, it needs to be linkable to "C" programs without a lot of

extra work.

Les Mikesell
l...@chinet.chi.il.us

Michael Meissner

unread,
Jul 16, 1991, 10:36:53 AM7/16/91
to
In article <1991Jul15.1...@chinet.chi.il.us>
l...@chinet.chi.il.us (Leslie Mikesell) writes:

| As such, it should exist as a translator from human coding to machine
| coding. While it is nice to provide a syntax that encompasses nearly
| everything in current use on the human side, it doesn't seem (to me)
| like the best approach from the machine side to interpret that syntax
| at runtime.
|
| >So write a translator. I delayed the public release of Perl until I had
| >a2p and s2p. I didn't want people to have that excuse for not migrating.
|
| So how about narrowing the runtime interpretation to the most efficient
| language possible and moving the kitchen-sink translator out to a separate
| program that is exec'ed only when needed? Yes, it will probably screw
| up programs that use 'eval' as an optimization until those evals are
| written in the runtime language. To make perl become "Standard Unix" it
| needs to be as efficient as any other language as well as being easier
| to use. Plus, it needs to be linkable to "C" programs without a lot of
| extra work.

To paraphrase what Dennis Ritchie said about PL/1, if you want a third
generation compiler that compiles directly to machine instructions
(ie, C), you know where to get it. Removing eval for the sake of
'efficiency' is throwing the baby out with the bath water. Just
because you don't use things like eval, doesn't mean others don't.

For instance, I just wrote a syslog monitor that takes an argument
from the command line and eval's a function, using the argument as the
body of the function. It was a fairly simple thing to do, and made my
program lots easier to write and use.

State machines are another area eval is extremely useful.....

--
Michael Meissner email: meis...@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

Steve Harris

unread,
Jul 16, 1991, 12:39:10 PM7/16/91
to
In article <1991Jul13.0...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>
>... Configure should really be

>written in Perl, but there's this little bootstrapping problem... :-)
>
>Larry


How about a small perl (sperl??), just a subset of all the
features/functions/whistles/bells of big perl? Just enough to run
Configure.pl. Might even be kinda useful on its own. (Some of us
use perl almost exclusively for text processing! :-)

I don't know if this solves anything, you still have to run Configure.sh
to figure out how to build sperl, but that might not require all those
hints, etc.

Just a thought.

--
Steve Harris - Eaton Corp. - Beverly, MA - uunet!etnibsd!vsh

Felix Lee

unread,
Jul 16, 1991, 2:09:50 PM7/16/91
to
I harbor some vague, unfounded hope that a sufficiently smart compiler
will be able to recognize the common uses of eval and transform them
in an intelligent manner.

s///e is a simple case, because it doesn't really require an eval.
Multiple e suffixes will require an eval, but hopefully that's rare.

eval applied to constant string literals should be straightforward to
parse at compile time. This is probably good enough to catch evals
used as feature tests. Or feature tests could be added to the
language: 'defined' can easily be extended to allow you to ask things
like 'defined symlink'.

Something like
$op = '+'; $x = eval "3 $op 4";
is harder, but perhaps still doable in some cases. You have to
analyze the possible values of $op when the eval is called and hope
it's something simple (what if $op = "+ ++$k while --$x > 0; $k *"?)
Code like this can be rewritten with indirect subroutines, which are
easier to optimize.

eval as an efficiency hack for run-time patterns can be fixed by
improving performance of run-time patterns.

eval of user input cannot be optimized, but this case doesn't need
optimization anyway.

eval used to define and redefine subroutines and formats depends on
how much analysis you can do on the eval'ed string. Or first-class
subroutines and formats could be added to the language. Something
like:
&add = sub ($a, $b) { $a + $b; };

Is there some common use of eval that I've overlooked?
--
Felix Lee fl...@cs.psu.edu

Dave Hayes

unread,
Jul 16, 1991, 3:22:32 PM7/16/91
to
l...@chinet.chi.il.us (Leslie Mikesell) writes:
>>Unfortunately, these are also Perl's biggest strengths. If you cure Perl's
>>biggest weaknesses, you'll also cure it's biggest strengths. Then we'll
>>basically be back where we started.
>But there's no reason to put up with the weakness at runtime to obtain
>the strengths.

Then why use it? Are you still using it? You should probably stop, right?

It seems kind of futile to complain about something when it takes much less
energy to stop using it. 8)
--
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ames!elroy!dxh

Complete possesion is proved only by giving
All you are unable to give posseses you

Leslie Mikesell

unread,
Jul 16, 1991, 1:29:30 PM7/16/91
to
In article <1991Jul16....@pa.dec.com> vi...@pa.dec.com (Paul Vixie) writes:
>Like lots of others in this forum, I would like to have a Perl compiler.
>However, I don't think execing a separate binary for scripts which call
>"eval" is the right solution. There are three worthwhile approaches:

>(1) p-code.
>(2) undump.
>(3) shared libraries

Actually I was thinking of something slightly different. Just make the
run-time code capable of parsing a restricted syntax equivalent to
p-code but still humanly writable. Eval'ing code written in the restricted
form wouldn't require running the translator although it could still be
done on the fly whenever anything that the runtime parser didn't understand
is encountered.

>(1) p-code. byte-compile the script to get the parsing into a fixed cost.
>there's still the cost of the p-code interpreter, but on modern UNIX systems
>the text is shared across all the processes that use it at any given time,
>so it's still a fixed cost. note that the perl binary's text is already
>shared if you are running a BSD or System V -derived UNIX.

The problem I have with perl is start-up time, and I think it mostly
consists of paging in the parsing code before anything useful happens.
If there were no evals, the p-code could be saved between runs. On
demand-paged machines it probably wouldn't matter if the parsing
code was part if the same object file if you just didn't execute it
on every run.

>(2) undump. we have this now, and there are versions of unexec() around
>for 90% of the processors actually in use these days.

Haven't found anything that works on a 3B2 yet, besides, who wants those
huge files around.

>(3) shared libraries. generate C with lots of callouts for the hard stuff,
>then link it against an enormous "libperl.so" that has eval and all the other
>glorious goo that makes Perl so special. this would be a bit of work for
>Larry, but since System V, OSF/1, and 4.4BSD will all have shared libs, the
>chances of getting this to work in a large-scale way are fairly good.

I like this one, but it's still going to page in a huge amount of code
if it continues to parse everything at runtime. But this would work
along with the separation of the parser and runtime functions and if
the p-code is translatable to C with calls into the shared libary you
could either run under an interpreter or spew out the c code and
compile it.

>Note that if you have a processor which is in the other 10% or for which
>there will never be another OS release, which has a terrible C compiler
>or will never have shared libraries, you can still run Perl scripts -- the
>way we all run them now.

This scheme doesn't really require shared libs except for efficiency.
You could do the same thing with a normal library but if you allow
runtime parsing of the full syntax in the same executable it will
probably make files about the same size as undump.

>Of the three approaches, I prefer #3 since it lets loops get turned into
>just a few instructions and could actually result in Perl number-crunchers
>which were as fast as those written in C or Fortran or at least Pascal.

Plus, of course, you could just drop in existing or specialized C code
and call the perl lib functions for the messy stuff.

>I kinda like the idea of replacing most of /bin with one- or five-line
>Perl scripts. If nothing else it would keep Perl's text segment in memory
>all the time.

Exactly, but if you're going to execute something thousands of times
a day, do you really want to go through the parsing step each time?

Les Mikesell
l...@chinet.chi.il.us

Tom Christiansen

unread,
Jul 16, 1991, 6:38:36 PM7/16/91
to
From the keyboard of l...@chinet.chi.il.us (Leslie Mikesell):
:The problem I have with perl is start-up time, and I think it mostly

:consists of paging in the parsing code before anything useful happens.

I'm not so sure of that: shouldn't your parse code be loaded already?
I know that my system always has a perl or seven running somewhere
or other.

Nonetheless, I definitely think pcode is the way to go. These days
it takes me about 2 seconds to parse plum (half that with autoloading
tricks), which is mildly annoying. On slower machines (I run on a
256-megabyte Convex C220) it's worse.

--tom
--
"GUIs normally make it simple to accomplish simple actions and impossible
to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)

Tom Christiansen tch...@convex.com convex!tchrist

Tom Christiansen

unread,
Jul 16, 1991, 7:37:01 PM7/16/91
to
I count ~60 uses of eval in plum. Here's what I use it for:

1 Using pseudo-anonymous packages for emulating more complex data
types. Like an assocative array of structures, each of which contains
various field, including other aggregates.

2 Printing out the assertion that fails as text on assert failures.
I do the same thing with cpp and C code.

3 Creating function stubs for autoloading.

4 Faulting in functions from my data segment.

5 Checking whether "&$fun" is defined before calling it.

6 Creating pseudo-anonymous functions for arbitrary user code for
binding to key sequences.

7 Running generic user code input not bound in an anonymous function.

8 Exception handling, more like catch/throw than setjmp/longjmp, since
you can longjmp to arbitrary points up your stack, but at least in
my catch/throw implementation, each layer of handler has to decide
whether to reraise the exception.

9 Creating valued enums.

10 Making sure I don't die on a bad regexp compile from user input.

11 Running down my own symbol table and checking for new function
(and sometimes variable) definitions loaded by arbitrary user code for
inclusion on various internal lists.

12 s/foo/bar/e where bar is usually sprintf or pack or some such thing.

13 s/foo/bar/ee for interpolation of variables from user input.

14 Creating a format where the field widths are dynamically sized to your
window size.


Of these, solutions other than eval seem possible for numbers 5, 8, 9, 10,
11, 12, and 14 if we extend the language a wee bit.

#1 could be solved by structured data types or changing package to be able
to accept a runtime symbol table switching instead of merely compile
time.

#2 could be solved using cpp as we do in C.

#3 could be partially dealt with using the attractive "&func = sub ()"
idea Felix proposed, although the rest would be still a 'do'.

Numbers 4, 6, 7, and 13 involve compiling code I don't know about when I
start, so I don't see what one might do here.

Upon contemplation of Felix's posting here and all these evals I found I
use, and perhaps also prompted by Felix's other posting of losing his
perlish virginity, the following just came to me in the shower. Submitted
for your amusement.

--tom

Eval, My Pal
(sung to the tune of "Michelle, ma Belle")

Eval, my pal,
You kludge code
Like no compiler shall,
My eval.

I love you,
I love you,
I love you.

I'll use you every day,
Until we find a way,
To compile the code that needs your mode
and still may that day.

My eval.

Eval, mon pal,
Fait des truques au dehors du rational,
mon eval.

I love you,
I love you,
I love you..........

Joe Wells

unread,
Jul 16, 1991, 11:30:57 PM7/16/91
to
In article <1991Jul16....@convex.com> Tom Christiansen <tch...@convex.COM> writes:

4 Faulting in functions from my data segment.

Wow! Why do you do that?

--
Joe Wells <j...@uswest.com>

Tom Christiansen

unread,
Jul 16, 1991, 11:52:25 PM7/16/91
to
From the keyboard of j...@maverick.uswest.com (Joe Wells):

:In article <1991Jul16....@convex.com> Tom Christiansen <tch...@convex.COM> writes:
:
: 4 Faulting in functions from my data segment.
:
:Wow! Why do you do that?

Think of it as autoloading from <DATA>.

I'll show the whole system, plus a bunch more, when I release plum. My
toolset should be generic enough for it to work for any program. It
really cuts down on the time to get something up on the user's screen for
the big ones with lotsa functions you either don't call right away or
maybe ever at all.

--tom

Brandon S. Allbery KF8NH

unread,
Jul 16, 1991, 9:40:08 PM7/16/91
to
As quoted from <$5eH!56...@cs.psu.edu> by fl...@cs.psu.edu (Felix Lee):
+---------------

| Is there some common use of eval that I've overlooked?
+---------------

How about eval as unwind-protect (setjmp/longjmp)? I have a rather large
script which eval's its main entry points in order to trap errors and clean up
after itself. (Now if only it could clean up after a panic... or if I can
figure out why it's panic'ing....)

Henk P. Penning

unread,
Jul 16, 1991, 3:56:35 PM7/16/91
to
In <$5eH!56...@cs.psu.edu> fl...@cs.psu.edu (Felix Lee) writes:

> I harbor some vague, unfounded hope that a sufficiently smart compiler
> will be able to recognize the common uses of eval and transform them
> in an intelligent manner.
>

> [ list of eval usage ]


>
> eval of user input cannot be optimized, but this case doesn't need
> optimization anyway.

Why not?

How would you do a spreadsheet in Perl ?
Define a new language for expressions and parse/evaluate them ?

> Felix Lee fl...@cs.psu.edu

Henk Penning he...@cs.ruu.nl
--
Henk P. Penning, Dept of Computer Science, Utrecht University.
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-534106
e-mail : he...@cs.ruu.nl (uucp to hp4nl!ruuinf!henkp)

Ted Stefanik

unread,
Jul 17, 1991, 12:55:52 PM7/17/91
to
|From the keyboard of tch...@convex.COM (Tom Christiansen):

|I count ~60 uses of eval in plum. Here's what I use it for:
| ...

|5 Checking whether "&$fun" is defined before calling it.
| ...

|Of these, solutions other than eval seem possible for numbers 5, 8, 9, 10,
|11, 12, and 14 if we extend the language a wee bit.

I thought Perl currently supports number 5 more efficiently via symbol table
manipulation. To prove it, I wrote the following little test program:

################################## Cut Here ###################################
#!/usr/bin/perl
sub foo
{
return undef;
}

@syms = ("foo", "bar");

foreach $sym (@syms)
{
($user,$system) = times;

for ($i = 1; $i < 10000; $i++)
{
{ # Why are these braces necessary ???
*entry = $_main{$sym};
$defined = defined(&entry);
} # Why are these braces necessary ???
}

print STDERR "defined(&$sym) = $defined (via _main)\n";

($nuser,$nsystem) = times;
print STDERR "Total time: ", ($nuser+$nsystem) - ($user+$system), "\n";

($user,$system) = times;

for ($i = 1; $i < 10000; $i++)
{
$defined = eval("defined(&$sym)");
}

print STDERR "defined(&$sym) = $defined (via eval)\n";

($nuser,$nsystem) = times;
print STDERR "Total time: ", ($nuser+$nsystem) - ($user+$system), "\n";
}
################################## Cut Here ###################################

Well, it is faster. However, if you remove the lines with the ??? on them,
then Perl gets a "segmentation fault" on the second time through the outer
loop. Does anybody know why? Am I doing something wrong, illegal, or messy?

(By the way, I test this perl3.044, 4.000beta, and 4.000 on the
DECStation/Ultrix and perl3.044 on the SUN/Sparc.)

BTW: In case you were wondering, if you use:

local(*entry) = $_main{$sym};

it seems to take about the same time as the eval. Of course, in the second
for loop, local would chew up memory if you didn't have the ??? braces.

Tom Christiansen

unread,
Jul 17, 1991, 3:02:39 PM7/17/91
to
From the keyboard of t...@evi.com (Ted Stefanik):
:|From the keyboard of tch...@convex.COM (Tom Christiansen):

:|I count ~60 uses of eval in plum. Here's what I use it for:
:| ...
:|5 Checking whether "&$fun" is defined before calling it.
:| ...
:|Of these, solutions other than eval seem possible for numbers 5, 8, 9, 10,
:|11, 12, and 14 if we extend the language a wee bit.
:
:I thought Perl currently supports number 5 more efficiently via symbol table
:manipulation. To prove it, I wrote the following little test program:

Yes, that is better; thanks. It's maybe not nice to reference %_main,
but considering that I'm actually doing far worse than this with %_main,
I can't see that one more will hurt.

I wonder if the coredump has to do with space deallocation. I'm
just surprised that it would care without a local().

Leslie Mikesell

unread,
Jul 17, 1991, 1:09:16 PM7/17/91
to
In article <1991Jul16.1...@jato.jpl.nasa.gov> da...@jato.jpl.nasa.gov writes:
>>But there's no reason to put up with the weakness at runtime to obtain
>>the strengths.

>Then why use it? Are you still using it? You should probably stop, right?

Yes and no. I don't use it on our busy machines during the daytime.

>It seems kind of futile to complain about something when it takes much less
>energy to stop using it. 8)

Well, I don't mind doing one or two futile things before lunch. But it's
more of a wish than a complaint. The only complaint I have about perl
is all the talk about portability when that huge switch makes it impossible
to compile anything beyond v3pl28 with the stock compiler on 3B2/400's.
(Anyone remember the claims that the 3b2 line was going to be where the
porting base for all new versions of unix would be developed?)

I realize it is not popular to be concerned about efficiency but if
your machine is busy, cycles are cycles. If you are wasting half of
them then you either need to spend twice as much for the machine or
get half the work done. Can everyone else afford that??

Les Mikesell
l...@chinet.chi.il.us

Felix Lee

unread,
Jul 18, 1991, 2:40:35 PM7/18/91
to
I wrote:
> eval of user input cannot be optimized, but this case doesn't need
> optimization anyway.

Henk P. Penning asks:
> Why not?

Well, I meant that if a Perl program P reads user input U and evals U,
then you don't need to analyze the use of U in P while compiling P.
The interpreter/compiler will have to be part of P anyway, so analysis
of U can be deferred until runtime of P.

Brandon Allbery asks:


>How about eval as unwind-protect (setjmp/longjmp)?

I forgot about that. This shouldn't be too hard either. Every eval
will do something like a catch, unless you can prove that a die won't
happen within the eval.

How about more complex control structures? Can you do coroutines or
coexpressions? Can you get a continuation in Perl? What nasty games
can you play with signal handlers?
--
Felix Lee fl...@cs.psu.edu

Tom Christiansen

unread,
Jul 19, 1991, 1:24:20 AM7/19/91
to
From the keyboard of fl...@cs.psu.edu (Felix Lee):
:How about more complex control structures? Can you do coroutines or

:coexpressions? Can you get a continuation in Perl? What nasty games
:can you play with signal handlers?

I tried to do co-routines that switched off by SIGIO or SIGALRM or
voluntarily when writing the plum folder demon. It was a horrible mess.
I kept getting interrupted partly through a read line, or longjumping out
and not having everything set up right (maybe while malloc was busy), or
just blowing my stack entirely and getting messy coredumps when I didn't
expect it. It just didn't seem up to it. So I backed off and made the
demon just another forked thread. I tend to do that a lot. It's easier
than real co-routines. The only nasty game I've been satifactorily
successful at is LASTing out of a dynamically enclosing loop label from inside
a signal handler. You just better make sure you're really inside it.

Tom Christiansen

unread,
Jul 19, 1991, 1:31:42 AM7/19/91
to
From the keyboard of t...@evi.com (Ted Stefanik):
:I thought Perl currently supports number 5 more efficiently via symbol table

:manipulation. To prove it, I wrote the following little test program:
:
:################################## Cut Here ###################################
:#!/usr/bin/perl
:sub foo
:{
: return undef;
:}
:
:@syms = ("foo", "bar");
:
:foreach $sym (@syms)
:{
: ($user,$system) = times;
:
: for ($i = 1; $i < 10000; $i++)
: {
: { # Why are these braces necessary ???
: *entry = $_main{$sym};
: $defined = defined(&entry);
: } # Why are these braces necessary ???
: }
:}

You know, I just wrote this little isdef function:

sub isdef {
local($function);
local(*entry);
for $function (@_) {
*entry = $_main{$function};
return 0 unless defined &entry;
}
1;
}

And got a coredump. Adding an extra set of braces didn't help.

This did:

sub isdef {
local($function);
for $function (@_) {
local(*entry) = $_main{$function};
return 0 unless defined &entry;
}
1;
}

sub checkdef {
print join(', ', @_),
@_ == 1
? " is "
: " are ",
&isdef
? ""
: "not ",
"defined\n";
}

&checkdef('abc');
&checkdef('xyz', 'pdq');
&checkdef('isdef');
&checkdef('abc','isdef');
&checkdef('isdef','abc');
&checkdef('isdef','checkdef');
&checkdef('isdef','checkdef', 'abc');

I realize I don't want all those entries around, but
on the other hand, I'm not going to be calling this
with extremely long lists. And Larry does warn against
anything but this.

Tom Christiansen

unread,
Jul 19, 1991, 7:39:45 PM7/19/91
to
From the keyboard of ch...@tct.com (Chip Salzenberg):
:Dollars to doughnuts that hack won't work under Xenix. (Under Xenix
:you can't longjmp() out of a signal handler. At least, not reliably.)

Eek. If you can't longjmp out of a signal handler, what fun is it?
Reminds me of Pascal days where you kept around stupid booleans to let you
back out of loops or routines. All these darn while-not-done-and-real-test
loops.

--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"Perl is to sed as C is to assembly language." -me

Chip Salzenberg

unread,
Jul 19, 1991, 1:22:23 PM7/19/91
to
According to tch...@convex.COM (Tom Christiansen):

>The only nasty game I've been satifactorily successful at is LASTing out
>of a dynamically enclosing loop label from inside a signal handler.
>You just better make sure you're really inside it.

Dollars to doughnuts that hack won't work under Xenix. (Under Xenix


you can't longjmp() out of a signal handler. At least, not reliably.)

--
Chip Salzenberg at Teltronics/TCT <ch...@tct.com>, <uunet!pdn!tct!chip>
"You can make use of the fact that UDP does not provide `reliable and
efficient streams' to eliminate the state, but then you are unreliable
and inefficent. There Ain't No Such Thing As A Free Lunch." -- Chris Torek

Martin Foord

unread,
Jul 18, 1991, 8:20:47 PM7/18/91
to
In article <1991Jul16....@etnibsd.uucp> v...@etnibsd.UUCP (Steve Harris) writes:
>
>In article <1991Jul13.0...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>>
>>... Configure should really be
>>written in Perl, but there's this little bootstrapping problem... :-)
>>
>>Larry
>
>
>How about a small perl (sperl??), just a subset of all the
>features/functions/whistles/bells of big perl? Just enough to run
>Configure.pl.

How 'bout a Configure.pl for those who already have a previous version of perl
already installed on their machine.

Martin.
--
Martin Foord. MHSnet/ACSnet: m...@dbsm.oz.au
SBC Dominguez Barry. Internet Gateway:
Phone: +61-2-258-2724 maf%dbsm....@munnari.oz.au

Paul E. Maisano

unread,
Jul 22, 1991, 4:53:44 AM7/22/91
to
Tom Christiansen <tch...@convex.COM> writes:

[Lots of nice ways to use eval...]

Please correct me if I'm wrong but I can't see any way to avoid using
an eval if I want to get the efficiency of the "tr" function when I don't
know the searchlist and/or replacelist beforehand.

I got bitten once by the fact that the tr function does not interpolate
variables. ie. $a = 'abc'; $_ = $a; tr/$a//d; will not do quite what I expected.
On checking the manual, I suppose I had no reason to expect this to work but
the s/xxx/yyy/ seems so similar to tr/xxx/yyy/...

...I must admit I was surprised. It seems like a useful thing to be able to do
without having to kludge it with an eval.

Then there's always the possibility of tr/xxx/yyy/e as well. :-)

---
Paul Maisano
AAII, Australia

Alan Thew

unread,
Jul 23, 1991, 7:16:53 PM7/23/91
to
In article <1991Jul16....@pa.dec.com>, vi...@pa.dec.com (Paul Vixie)
says:
>
......

>Perl is already standard UNIX. I'll bet somebody a dollar that there
>are more systems running Perl than nawk, and many (many!) more programmers
>able to get serious work done in Perl than in nawk.
>
>Given that awk without functions is either an efficiency or coding (or
>both) nightmare for projects of more than a thousand lines or so of code,
>I'd say perl has won the battle for UNIX's scripting language.
>
I should probably mail this but.....
PERL may have won but awk/nawk/gawk is NOT a scripting language, at
least you're the first person I've seen make the claim. Aho et al
certainly don't. If there has to be a war, it's between ksh (or something)
and PERL :-)
Yes I know PERL can do all awk/nawk/gawk/mawk (etc etc) can.

Alan Thew
q...@liverpool.ac.uk

0 new messages