Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!agate!agate!rusty
From: rusty@groan.Berkeley.EDU (Rusty Wright)
Newsgroups: comp.lang.perl
Subject: Re: Ruminations on the future of Perl
Message-ID: <RUSTY.91Jun28181513@groan.Berkeley.EDU>
Date: 29 Jun 91 02:15:13 GMT
References: <WORLEY.91Jun27163439@sn1987a.compass.com>
	<1991Jun28.020603.1069@zardoz.club.cc.cmu.edu>
	<WORLEY.91Jun28110759@sn1987a.compass.com>
	<1991Jun28.212606.19054@convex.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California Berkeley
Lines: 66
In-Reply-To: tchrist@convex.COM's message of 28 Jun 91 21: 26:06 GMT

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.