From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: Scripting in general
Originator: tchrist@pixel.convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Date: Thu, 16 Apr 1992 19:28:35 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

From the keyboard of bengtl@maths.lth.se (Bengt Larsson):
:I don't think it's possible to change Perl like I would want and be
:in any way backwards-compatible. I can try to be specific, but it will
:look like a lot of whining. If you don't want to see it hit "n" now:
:

> Strange constructs for interpolating variables in regexps,

Not sure what you mean there.  /$foo/ and /${foo}bar/ seem
reasonably intuitive to me.  But not to you?

> filename globbing etc. 

<*.c> is ok.

<${foo}> being different from <$foo> isn't.

> No structured types. 

Larry's mumbled about fixing this in the next major release,
but he has to find a good syntax first, and then have the
time to implement it.

Certainly I've got at least half-a-dozen (obscure) methods 
for getting this done anyway, including recursive and
structured data types.  But they're really all hacks
in that they are synthesized and not a formal part of 
the language's syntax.

> Lots of interesting cases
> where parantheses are needed or not.

Just always use them, and it won't be a problem.

> Confusing scalar/vector contexts.

Yup.  It is kinda nice to be able to have
    
    $scalar = `cmd`;
    @array  = `cmd`;

behave as they do, though.

> Integer/floating/string ambiguity.

That's just an awk thing.  I can't think of anywhere outside
of syscall that it matters much.

> "A word that doesn't have any other interpretation in the grammar is
> treated as if it had single quotes around it". I'm not quite sure
> what it means, but it looks strange.

This is the so-called poetry optimization, which has probably only
one or maybe two reasonable uses in the language.
This bothers me too.  It means that you don't have to quote single words.
consider

    $x = foo . bar;

meaning

    $x = 'foo' . 'bar';

I don't quite like it.  But I don't want to user $'s *or* quotes, and
you can't really have both.

But it lets you treat the weird FILEHANDLE thingies more as first-
class objects, which is a win.  You also get to write:

    @DoW = (Sun,Mon,Tue,Wed,Thu,Fri,Sat);
    @MoY = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec);

Which increases legibility.

> Returning structures like from "stat" as plain arrays is ugly.

(I might point out that perl was never designed to win a 
 beauty contest in programmming langauges.  It was meant
 to get the job done.)

How might you like it?  Either of these is pretty legible:

    @sb = stat($file);
    if ($sb[$ST_MODE] & 0111) { ... }

    ($st_dev,$st_ino,$st_mode,$st_nlink,$st_uid,$st_gid,$st_rdev,$st_size,
        $st_atime,$st_mtime,$st_ctime,$st_blksize,$st_blocks) = stat($file);


> The syntax for file names in "open" does not appeal to me, even though
> it's Unixy. "fopen" and "popen" is more like it.

> Sed-like s/ tr/ and y/ is ugly, or at least obscure.

Both of these are just vestiges of trying to unify UNIX's already
obscure syntax.  I like the s/ kind of operators myself, and 
don't see how they're obscure.

> Lots of cute predefined names. But I suppose Larry will make aliases for 
> that.

Right -- you can give the punctiation variables reasonable names by
creating aliases this way:

    *CUR_LINE 			= *_;
    *BUFFER 			= *|;
    *REGEXP_NEWLINE_SENSITIVE 	= **;

and use the aliases, like $BUFFER = 1 instead of $| = 1.

> It's not enough like C for my taste. Obviously it's much a question of
> taste. 

> I sure like the no-builtin limits, 

quite.

> consistent regexp syntax (except
> var interpolation.)

See above -- I'm unclear here.

> Using eval is an egregious hack. 

Well, for some things it is.  For building up on-the-fly
subroutines to avoid performance hits, probably.  For 
writing a debugger or sourcing another file, it's indispensable.
For catch/throw or setjmp/longjump emulation, as in:

    eval {
	# your code goes here
    }; 

It's probably a bit overloaded.

> In the language I
> referred to you compile a regexp with "var = regexp(string)"). 

Perl tries to compile regexps when it thinks it has to, and it's usually
right.  I wouldn't want to be explicit always.  To get more constrol, you
sometimes have to do things like //o or an eval.

> Packages
> is a good thing. Nice debugger. Good support. Good portability.

all these things are true.

> I'm not a regular user of Perl, as you may guess. I make do with shell
> + awk/sed/sort etc. 

Me too -- 5 years ago.

> If you are going to make a new scripting language anyway, why make
> it as unreadable as shell scripts? There is no point.

There is no language written in which is it impossible to write illegible 
code.  Perl code needn't be obscure; some coders (not excepting this one)
occasionally get this APL or obfuscated-C bent and try to make it so.
This is probably setting a poor example.

--tom