Ruminations on the future of Perl

30 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