Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ames!haven.umd.edu!mimsy!mojo.eng.umd.edu!eng.umd.edu!stripes From: stripes@eng.umd.edu (Joshua Osborne) Newsgroups: comp.lang.perl Subject: Re: Ruminations on the future of Perl Message-ID: <1991Jun30.173240.25041@eng.umd.edu> Date: 30 Jun 91 17:32:40 GMT References: Reply-To: stripes@eng.umd.edu (Joshua Osborne) Organization: College of Engineering, Maryversity of Uniland, College Park Lines: 117 In article , rusty@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 ($_ = ) { print; } This is showig a "longcut", I _like_ the way "while()" works, it is very easy to use. > and the last is > > print while ; 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 " 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...) -- stripes@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..." - lbruck@eng.umd.edu (Lewis Bruck)