tchrist@convex.COM (Tom Christiansen) (11/21/89)
In article <1194@radius.UUCP> radius!lemke@apple.com (Generic Account) writes: >In article <4025@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >}This is where perl is designed for ... > >OK, but what about those of us who don't have perl? Is there already such >a script or program in plain old "c" that can make the same pretty reports >as shown above? We're running a NeXT with version 1.0 OS... >===== Steve Lemke, Engineering Quality Assurance, Radius Inc., San Jose ===== Please don't take this wrong, but why DON'T you have perl? If you can post this note, you can get perl. It's freely available from FTP and plain old uumail-type archive servers all over the net. Its author, Larry Wall, is the same man who brought you rn, metaconfig, and patch. He privately supports perl better than any industrial software house that I've ever seen. He's extremely helpful in getting perl running on new machines, and I'll bet it's already been tweaked for your architecture. If you've ever run one of Larry's Configure scripts, you know what I mean. Perl is light years ahead of awk, sed, and sh as far as tools go. I very strongly believe that it will be around for many years to come, and that it will be extremely widely used throughout the world. You can see how much source has come across the net just lately that's been written in perl. I have not written any awk or sed scripts since I got perl, and certainly none of those horrendous sh scripts full of multiple calls to sed and awk and tr and sort and cut and paste and expand and grep and all their brethren. I've saved myself quite a bit of development time by writing fewer C programs as well. Furthermore, perl programs are portable without modification or recompilation to a wealth of architectures. I only have around 5 architectures now to send common programs too, but in my last job there were no fewer than a dozen. It's really nice to just close your eyes and rdist your program and know it will run. Do yourself a favor: get perl. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
chip@ateng.com (Chip Salzenberg) (11/21/89)
According to lemke@radius.UUCP (Steve Lemke):
>OK, but what about those of us who don't have perl?
You may not know it, but you need Perl. Get it.
--
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip>
"Did I ever tell you the Jim Gladding story about the binoculars?"mr@cica.cica.indiana.edu (Michael Regoli) (11/22/89)
tchrist@convex.COM (Tom Christiansen) writes: >Furthermore, perl programs are portable without modification or >recompilation to a wealth of architectures. interesting, this perl code dies here with: Script started on Tue Nov 21 13:08:07 1989 [1] [cica:/u.cica/mr] sh uutraf.pl syntax error in file ./uutraf.pl at line 19, next token "%" Execution aborted due to compilation errors. now that's portable! :-) line 19 of uutraf.pl is: %hosts = (); # hosts seen (BTW, our "xferstats" is in /usr/spool/uucp/LOG, not /usr/spool/.Admin.) -- michael regoli mr@cica.indiana.edu regoli@iubacs.bitnet ...rutgers!iuvax!cica!mr
tchrist@convex.COM (Tom Christiansen) (11/22/89)
In article <222@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes: |Script started on Tue Nov 21 13:08:07 1989 |[1] [cica:/u.cica/mr] sh uutraf.pl |syntax error in file ./uutraf.pl at line 19, next token "%" |Execution aborted due to compilation errors. |now that's portable! :-) |line 19 of uutraf.pl is: |%hosts = (); # hosts seen You're probably running pre-version 3 perl. With 3.0, associative arrays became first-class citizens and could be talked about as a whole using the %foo notation to distinguish them from @foo indexed arrays. |(BTW, our "xferstats" is in /usr/spool/uucp/LOG, not /usr/spool/.Admin.) I'll bet Johan will make it a switch or dynamically determined thing if you ask him to. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
jgreely@oz.cis.ohio-state.edu (J Greely) (11/22/89)
In article <3273@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: >He's extremely helpful in getting perl running on >new machines, and I'll bet it's already been tweaked for your >architecture. Well, no. He's using a NeXT, which requires a trivial patch to Configure that Larry hasn't installed yet (despite two requests from me, sigh). And, of course, you have to compile with the -bsd switch and ignore the supplied malloc. *** Configure.dist Tue Nov 21 16:23:15 1989 --- Configure Fri Nov 17 22:24:14 1989 *************** *** 1470,1475 **** --- 1470,1476 ---- : see if sprintf is declared as int or pointer to char echo " " cat >.ucbsprf.c <<'EOF' + #include <stdio.h> main() { char buf[10]; exit((unsigned long)sprintf(buf,"%s","foo") > 10L); } EOF if $cc $ccflags .ucbsprf.c -o .ucbsprf >/dev/null 2>&1 && .ucbsprf; then -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
jgreely@oz.cis.ohio-state.edu (J Greely) (11/22/89)
In article <222@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes: >interesting, this perl code dies here with: RTFM. Upgrade to Perl 3.0, which is required for uutraf.pl. >(BTW, our "xferstats" is in /usr/spool/uucp/LOG, not /usr/spool/.Admin.) Not a Perl-related portability problem. That's just generic UUCP incompatibility, which would plague a C program as well (and you don't have to recompile the Perl script after making the change). -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
richardt@mica.Berkeley.EDU (Richard Threadgill) (11/22/89)
In article <3273@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: >>OK, but what about those of us who don't have perl? > I have not written any awk or sed scripts since I got > perl, and certainly none of those horrendous sh scripts full of > multiple calls to sed and awk and tr and sort and cut and paste and > expand and grep and all their brethren. To my mind this is the most powerful argument I heard *against* using perl. Perl, like any other monolithic integrated system is wonderful for performing the tasks it was designed to encompass. However, that also ties you to that monolithic system. The whole point of having filters is that with a filter you can massage the input in just about any fashion you like. Need a different filter? Spend the few minutes it takes to write one. Maybe perl has the capabilities for all the filters you need now - if so, great. However, the filter paradigm is still a hell of a lot more useful than the monolithic pardigm. Don't forget how to do filter programming - moreover, don't tie new script authors to your pet monolithic system. RichardT
jgreely@oz.cis.ohio-state.edu (J Greely) (11/22/89)
In article <RICHARDT.89Nov21141554@anableps.berkeley.edu> richardt@mica.Berkeley.EDU (Richard Threadgill) writes: >In article <3273@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: >> I have not written any awk or sed scripts since I >> perl, and certainly none of those horrendous sh scripts full of >> multiple calls to sed and awk and tr and sort and cut and paste and >> expand and grep and all their brethren. >To my mind this is the most powerful argument I heard *against* using >perl. Perl, like any other monolithic integrated system is wonderful >for performing the tasks it was designed to encompass. However, that >also ties you to that monolithic system. I don't think Tom is advocating Perl as a complete replacement for the Unix Way(TM), but as a complement to it. There is a type of programming task that's too clumsy or slow (or both) when written the "old-fashioned" way, but not easily implemented in C (or just not worth the time). This is what Perl is for. By some strange coincidence, tasks of this type are extremely common in system administration. I suspect a straw poll of Perl users would turn up a large number of sysadmins. Personally, when I want the first field of a text file quickly, I still use awk, mostly because my fingers type "awk '{print $1}'" faster than perl -ane 'print shift(@F),"\n";' Had I ever bothered to make a short script 'pf': #!/usr/bin/perl $f = shift - 1; while (<>) { chop; @F=split(' '); print $F[$f],"\n"; } I'd just say "pf 1". Of course, if I were writing it, I'd add a switch to allow arbitrary regexps as field delimiters, and meaningful error checking, but I digress. >The whole point of having filters is that with a filter you can >massage the input in just about any fashion you like. Need a >different filter? Spend the few minutes it takes to write one. Unfortunately for your argument, I write filters in Perl. Lots of them. Sometimes I chain them together, sometimes I just turn them into a simgle program. By the way, what's your stand on awk? It's more than just a filter; hell, it has FOR LOOPS. It can do things TOTALLY UNCONNECTED with massaging input. Is it an evil repressive tool? >Maybe perl has the capabilities for all the filters you need now - if >so, great. You *do* know that Perl is a complete programming language, right? Powerful enough that Larry Wall is supposedly writing the next version of RN in it? (I've never had the guts to ask him about this one, myself; I'd really rather not know) -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
tneff@bfmny0.UU.NET (Tom Neff) (11/22/89)
The issue we're struggling with is whether Perl deserves to become a great UNIX lingua franca. It's certainly powerful, but it's still somewhat in flux. As perl-script author postings attest, it has that "addictive" quality that makes some people total converts. I do think it's annoying at this stage to hear "here's the perl script, that's all anyone with a functioning brain pan needs, wise up you contemptible fools!" types of sentiments in postings. Perl needs a softer sell. It's too early for it to become a religious issue. Distributing perl scripts for which Bourne would have done in roughly the same space doesn't help either. But we should keep an open mind and remember it's more important to try new things than to suppress them. That's why the net exists. -- Hey, where'd the Colombian Coffee ads go all of %8 Tom Neff a sudden! Is Juan Valdez hiding in Panama? 8% tneff@bfmny0.UU.NET
jgreely@oz.cis.ohio-state.edu (J Greely) (11/22/89)
In article <14946@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >I do think it's annoying at this stage to hear "here's the perl script, >that's all anyone with a functioning brain pan needs, wise up you >contemptible fools!" types of sentiments in postings. Perl needs a >softer sell. It's too early for it to become a religious issue. (Two years after its first net release is too early?) A lot of the current publicity is probably due to the fact that comp.lang.perl is being voted on now (when *does* that vote end?). I don't mind, since lots of Perl hackers are coming out of the closet, both on the net and the Perl mailing list, resulting in the appearance of a fair number of useful Perl scripts that might otherwise never have seen the light of day. And yes, it *is* a religious issue. It cuts to the heart of the Unix philosophy, performs a triple bypass, and gets some useful work done while sh is still in the first set of backquotes. Ever seen a disk usage accounting system written in sh? It's not a pretty sight. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
tneff@bfmny0.UU.NET (Tom Neff) (11/22/89)
In article <JGREELY.89Nov21190844@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >> It's too early for [perl] to become a religious issue. > >(Two years after its first net release is too early?) Oh yes absolutely. Two years is nothing, or why are we at 3.0. > ... And yes, it *is* a religious issue. It cuts to the heart of the >Unix philosophy, performs a triple bypass, and gets some useful work >done while sh is still in the first set of backquotes. Ever seen a >disk usage accounting system written in sh? It's not a pretty sight. More to the point, ever seen one in awk? Probably not, because although people may write 'em they don't get around. Swiss Army Interpreters occupy a peculiar middle zone between the pure shell -- dumb and function-poor but, in Madge's immortal words, "you're soaking in it" -- and compiled C, which takes work up front but which can do anything conceivable and will run maximally fast. Depending on your "religion," awk/perl either combine the best of these worlds or the worst. Perl attempts to win converts like Crocodile Dundee (naaooww, THAT's not a Swiss Army knife, THIS <swish> is a Swiss Army knife...) at the expense of compactness. It's a worthy idea, but there are drawbacks. On System V/386, for instance, with all debugging #undef'd and with -O turned on, the latest perl executable *after* both 'strip' and 'mcs -d' subtends 229K, and takes ~5 seconds to load, compile and interpret an in-line script consisting of 'exit 0;'. For overnight batch reports this is irrelevant, but there's little hope of using perl as a quickie tool to get something fun done in, say, a hacked Pnews as one might with sed. The perl answer, unfortunately, is "so what, just rewrite Pnews in perl" but this illustrates the "hump" of acceptance. "Switch over completely or suffer inconvenience" does *not* cut to the heart of the UNIX philosophy. It is closer to the religious passions that retard UNIX than it is to UNIX strengths. So while I like and admire Perl and feel it's the best batched report writer invented, I think its limitations preclude basic tool status. Perhaps one solution would be to stop writing '?2p' translators for a bit and write 'p2c' so that cherished perl tools can be C-compiled for lasting freshness. Then perl becomes a superb prototyper capable of dashing off a fast tool for intensive use in other environments. -- To have a horror of the bourgeois (\( Tom Neff is bourgeois. -- Jules Renard )\) tneff@bfmny0.UU.NET
jgreely@oz.cis.ohio-state.edu (J Greely) (11/22/89)
In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >In article <JGREELY.89Nov21190844@oz.cis.ohio-state.edu> J Greely > <jgreely@cis.ohio-state.edu> writes: >> ... And yes, it *is* a religious issue. It cuts to the heart of the >>Unix philosophy, performs a triple bypass, and gets some useful work >>done while sh is still in the first set of backquotes. Ever seen a >>disk usage accounting system written in sh? It's not a pretty sight. >More to the point, ever seen one in awk? Probably not, because although >people may write 'em they don't get around. Actually, I've seen several, only one of which was written here. All written in that peculiar combination of awk, sed, grep, join, sort, and <insert shell here>, which is the approach you seem to imply is better than using Perl. Whatever for? You can implement Life in a spreadsheet, but do you really want to? >Perl attempts to win converts like Crocodile Dundee (naaooww, THAT's not >a Swiss Army knife, THIS <swish> is a Swiss Army knife...) at the >expense of compactness. Huh? I'll overlook the personification of the enemy for the moment, and say that some Perl *users* do that. Not at all important to me, however. I use Perl because it has the right combination of fast programming time and good runtime performance. Yes, I can write filters in C, and even entire programs, but I can't write, compile, [debug, compile, repeat] a C program faster. For many tasks, fast completion is more important than optimal runtime. >It's a worthy idea, but there are drawbacks. On System V/386, for >instance, with all debugging #undef'd and with -O turned on, the >latest perl executable *after* both 'strip' and 'mcs -d' subtends >229K, and takes ~5 seconds to load, compile and interpret an in-line >script consisting of 'exit 0;'. ...and my "hello world" program in C takes two minutes to compile, and takes up 48K. BFD. >"Switch over completely or suffer inconvenience" does *not* cut to the >heart of the UNIX philosophy. It is closer to the religious passions >that retard UNIX than it is to UNIX strengths. Am I right in suspecting that you didn't read my sentence the way I wrote it? I never said it epitomized the Unix philosophy, I said it *ignored* it. "I know it's not Unix, but it's *convenient*" >So while I like and admire Perl and feel it's the best batched report >writer invented, I think its limitations preclude basic tool status. "basic tool status"? So it shouldn't be sold at Sears? If I have to go to a hardware store to pick it up, that's fine with me. If hobbyists don't need it, they don't even need to know it's there. How many normal users know how to use "join" (or, for that matter, "find")? >Perhaps one solution would be to stop writing '?2p' translators for a >bit and write 'p2c' so that cherished perl tools can be C-compiled >for lasting freshness. Then perl becomes a superb prototyper capable >of dashing off a fast tool for intensive use in other environments. ...let me know when you finish sh2c, too :-) As for prototyping, I do that already, and p2c wouldn't do me much good, since the Perl idioms I use for ease of implementation would make ugly C. The resulting code probably wouldn't run on both HPUX and SunOS anyway. My next project will be prototyped in Perl, and the protoype will probably be relied on for at least six weeks in our user environment (can 3500 users break the account administration system?). Parts of it will be rewritten in C as needed, to improve performance or robustness. Large parts of it may remain in Perl forever, to make sure it works on all of our architectures (Pyramid 98, HP 9000 300 & 800, Sun 3 & 4, NeXT, IBM RT, BBN Butterfly, Encore Multimax, and whatever else we get soon). If it works out as well as I expect it too, I won't hesitate do distribute the Perl with the C. (side note: p2c *is* in Larry's wishlist for future additions) -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
tneff@bfmny0.UU.NET (Tom Neff) (11/23/89)
I'm going to try and pick out the constructive dialog here, although I usually prefer to let postings like this one speak for themselves... In article <JGREELY.89Nov22100225@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >[me:] >>More to the point, ever seen one in awk? Probably not, because although >>people may write 'em they don't get around. > >Actually, I've seen several, only one of which was written here. All >written in that peculiar combination of awk, sed, grep, join, sort, >and <insert shell here>, It's not a peculiar combination, it's using tools under shell, which is how UNIX works. That's what they're there for. Vertical shells like Perl just internalize more of the functionality. My point is that while Perl does this as well as anyone, the resulting behemoth is less well suited for use AS A TOOL ITSELF than the more familiar ones. The same thing goes for comparable projects like Mush. It's like Bloomingdale's -- a truly magnificent department store where you can spend a whole day shopping and find anything imaginable, but just try and dash in to get a quick pair of socks!! :-) > which is the approach you seem to imply is ^^^ >better than using Perl. Whatever for? You can implement Life in a >spreadsheet, but do you really want to? Meta-peeve!: why don't posters address the argument rather than aiming the second person at some individual arguer? News is not mail... sigh [me:] >>Perl attempts to win converts like Crocodile Dundee (naaooww, THAT's not >>a Swiss Army knife, THIS <swish> is a Swiss Army knife...) at the >>expense of compactness. > >Huh? I'll overlook the personification of the enemy for the moment, ^^^^^ >and say that some Perl *users* do that. There is no 'enemy' here. (re-sigh!) Perl's own documentation says it "is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal)." This is a clear cut and well achieved design goal; it is simply not consequence-free. >> On System V/386, for >>instance, with all debugging #undef'd and with -O turned on, the >>latest perl executable *after* both 'strip' and 'mcs -d' subtends >>229K, and takes ~5 seconds to load, compile and interpret an in-line >>script consisting of 'exit 0;'. > >...and my "hello world" program in C takes two minutes to compile, and >takes up 48K. BFD. For purposes of comparison, "hello world" on V/386 takes 10 seconds (once) to make and purge, occupies 13k after stripping, and runs in 1/10th second. (The above quoted poster either didn't strip his object or has a more space hungry compiler in general.) For quick tools the huge Perl latency (like the huge Mush latency and others') is a drawback. >>"Switch over completely or suffer inconvenience" does *not* cut to the >>heart of the UNIX philosophy. It is closer to the religious passions >>that retard UNIX than it is to UNIX strengths. > >Am I right in suspecting that you didn't read my sentence the way I ^^^ >wrote it? I never said it epitomized the Unix philosophy, I said it >*ignored* it. Since this is mail :-), no *I* didn't understand the way ***->YOU<-*** phrased +--==<<YOUR>>==--+ sentence, which didn't say 'ignore'. Fortunately Larry's program does not really ignore the UNIX philosophy as ///(-y-o-u-)\\\ imply -- it just exploits some UNIX concepts with specialized rewards and risks. [ childishness deleted ] >>Perhaps one solution would be to stop writing '?2p' translators for a >>bit and write 'p2c' ... >...let me know when you finish sh2c, too :-) These are sold commercially I believe. The basic idea is sound. >(side note: p2c *is* in Larry's wishlist for future additions) -- "How can a man of integrity get along /// Tom Neff in Washington?" -- Richard Feynman /// tneff@bfmny0.UU.NET
jgreely@oz.cis.ohio-state.edu (J Greely) (11/23/89)
In article <14949@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >I'm going to try and pick out the constructive dialog here, although I >usually prefer to let postings like this one speak for themselves... ...pass the hair shirt, I've been chastised. I don't use third person, I lapse into childishness (what was it that you deleted, anyway?), and I don't agree with Tom (Neff, that is; at least one other Tom out there liked it). >In article <JGREELY.89Nov22100225@oz.cis.ohio-state.edu> J Greely > <jgreely@cis.ohio-state.edu> writes: >>Actually, I've seen several, only one of which was written here. All >>written in that peculiar combination of awk, sed, grep, join, sort, >>and <insert shell here>, >It's not a peculiar combination, it's using tools under shell, which is >how UNIX works. That's what they're there for. Uh, when a line contains two awk's (one in backquotes), a grep, a join, two sorts, and a "uniq -c" (piped into more), I call it peculiar. It may also be creative and elegant, but it *is* peculiar. Yes, I *know* that's what they're for; I'm just not sold on the idea that you should always use them. >My point is that while Perl does this as well as anyone, the resulting >behemoth is less well suited for use AS A TOOL ITSELF than the more >familiar ones. If your point (and I'll discuss the use of second person in a bit) is that Perl is not optimized for existing in the middle of a pipeline (if that's suitable as an operational definition of "tool" in this context), my response is a quiet "so what?". I've already mentioned that I still use standard Unix tools for small tasks. *I've* never said that Perl replaces them for all uses. > It's like Bloomingdale's -- a truly magnificent department store >where you can spend a whole day shopping and find anything imaginable, >but just try and dash in to get a quick pair of socks!! :-) (how come my digressions are childish, and his are funny?) >Meta-peeve!: why don't posters address the argument rather than aiming >the second person at some individual arguer? News is not mail... sigh Tom (direct address), the use of third person in a follow-up article does not jump out as more correct. Mail is talking to you on the phone; news is talking to you on a party line. In both cases, I am addressing my responses to your statements. The fact that others are listening in (and possibly commenting) does not change the fact that I'm talking to you. Why not in mail? You're raising points in public that I'm trying to address. Taking it to mail doesn't do anything for others who may be interested in the arguments on both sides. >>Huh? I'll overlook the personification of the enemy for the moment, > ^^^^^ >There is no 'enemy' here. Clarification for the humor impaired: :-) >The above quoted poster either didn't strip his object >or has a more space hungry compiler in general. You're quite right. Running strip brings it down to 32K. My mistake. >Since this is mail :-), no *I* didn't understand the way ***->YOU<-*** >phrased +--==<<YOUR>>==--+ sentence, which didn't say 'ignore'. "cut to the heart...perform a triple bypass". Seemed fairly straightforward to me. Perhaps whimsy isn't universal, after all. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
magill@operations.upenn.edu (PENNnet Oper/Planning) (11/23/89)
> I don't think Tom is advocating Perl as a complete replacement for the > Unix Way(TM), but as a complement to it. There is a type of > programming task that's too clumsy or slow (or both) when written the > "old-fashioned" way, but not easily implemented in C (or just not > worth the time). This is what Perl is for. By some strange > coincidence, tasks of this type are extremely common in system > administration. I suspect a straw poll of Perl users would turn up a > large number of sysadmins. > Coming from the environment of managing multiple systems of various dialects and operating systems "universal" solutions are a godsend. My "login.com", ".login", ".profile" files all create an environment based upon my needs and desires. Based in things like GNU and PERL I can monitor and maintain multiple systems with multiple operating systems (I don't consider Ultrix, BSD, H-UX, SystemV, 386 SystemV, to be the same operating system - because from a system adiminstrators point of view - they don't all act quite the same and we all know that even though VMS claims to be POSIX compliant, it sure doesn't look like Unix(tm)). -- William H. Magill Manager, PENNnet Operations Planning Data Communications and Computing Services (DCCS) University of Pennsylvania Internet: magill@dccs.upenn.edu magill@eniac.seas.upenn.edu magill@upenn.edu
emv@math.lsa.umich.edu (Edward Vielmetti) (11/23/89)
We really need comp.lang.perl to get this discussion in the right perspective. Did the person (at a uucp-only site) collecting votes fall off the earth? --Ed
tchrist@convex.COM (Tom Christiansen) (11/23/89)
In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: |On System V/386, for instance, with all debugging #undef'd and with -O |turned on, the latest perl executable *after* both 'strip' and 'mcs -d' |subtends 229K, and takes ~5 seconds to load, compile and interpret an |in-line script consisting of 'exit 0;'. |So while I like and admire Perl and feel it's the best batched report |writer invented, I think its limitations preclude basic tool status. Which limitations, load time? Somewhere it does say that perl probably isn't good for tiny machines. My idea of a tiny machine is my diskless Sun 3/50 with 4 megabytes. Here are three successive timings: sun% /bin/time perl -e 'exit 0;' 4.5 real 0.0 user 0.4 sys 1.2 real 0.0 user 0.2 sys 1.3 real 0.0 user 0.1 sys So yes, that first load (across the net) took nearly 5 seconds, after which a lot went resident. but then, i don't try to get real work done on a system of that size anymore. Here are some other timings. First a vax750 with 8 megabytes of memory. It sure helps to actually have a local disk. This is my idea of a low-end machine: vax750% /bin/time perl -e 'exit 0;' 1.4 real 0.0 user 0.4 sys 1.4 real 0.0 user 0.4 sys 0.9 real 0.0 user 0.3 sys Here is a low-end Convex, a 120 with just 32megabytes, my idea of a medium-end machine. The -e gets me extended (microsecond) precision on real time on a C1, and also on user and sys on a c2. C120% /bin/time -e perl -e 'exit 0;' 0.292628 real 0.010000 user 0.190000 sys 0.274396 real 0.010000 user 0.170000 sys 0.255572 real 0.000000 user 0.150000 sys And here are timings for a C220 with 256 meg, which is definitely getting on the high end. Halving or doubling the number of processors or memory doesn't make for significantly different timings: C220% /bin/time -e perl -e 'exit 0;' 0.125862 real 0.004936 user 0.054461 sys 0.114496 real 0.005027 user 0.050926 sys 0.107741 real 0.004883 user 0.041306 sys So I would say that for the initial load on very tiny machines, perl is somewhat large. But on your mid-range and larger machines, it's quick enough for use as a command line filter. I don't think that the statement that "it's too slow for general work" is valid except on the very tiniest of machines. Actually, the exact quote is that "its limitations preclude basic tool status." I wonder which limitations Tom Neff was thinking of. |Perhaps one solution would be to stop writing '?2p' translators for a |bit and write 'p2c' so that cherished perl tools can be C-compiled |for lasting freshness. Then perl becomes a superb prototyper capable |of dashing off a fast tool for intensive use in other environments. That's an idea, although the task of translating for as many different machines as perl runs on would not be pleasant. Furthermore, because of the 'eval' capability, it would be like writing a lisp compiler; you'd have to embed the whole interpreter in each program. If you really want to do that, you can use 'dump LABEL' if you have undump in order to checkpoint after initializations. There are plenty of things perl is NOT good for. These including (to my mind) debuggers and windowing applications. But for many other things it fits better than the previously existing tools, sometimes even better than C itself because of built-ins, optimized regex handling, and the fact it's an interpreter. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
lwall@jato.Jpl.Nasa.Gov (Larry Wall) (11/23/89)
In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
: Perl attempts to win converts like Crocodile Dundee (naaooww, THAT's not
: a Swiss Army knife, THIS <swish> is a Swiss Army knife...) at the
: expense of compactness. It's a worthy idea, but there are drawbacks.
Heh, heh. In Unix World they just called it a Swiss Army Chainsaw.
I kinda like that.
: On System V/386, for instance, with all debugging #undef'd and with -O
: turned on, the latest perl executable *after* both 'strip' and 'mcs -d'
: subtends 229K, and takes ~5 seconds to load, compile and interpret an
: in-line script consisting of 'exit 0;'.
This says more about the OS than perl, I fear. On a measly 68020 here
with a load average of over 2, the same program takes 0.0 user, 0.1 system
and 0:00 elapsed time (rounded to the nearest second). I suspect that
as soon as most everyone gets System V.4 and demand paging, this argument
will not be so potent.
In general, however, I agree with you that religious zealotry does little
good. Enthusiasm is one thing--I'm a wee bit enthusiastic about perl
myself, for some reason--but I don't like to see people picking fights.
It makes people think either/or when they should be thinking both/and.
: For overnight batch reports
: this is irrelevant, but there's little hope of using perl as a quickie
: tool to get something fun done in, say, a hacked Pnews as one might with
: sed. The perl answer, unfortunately, is "so what, just rewrite Pnews
: in perl" but this illustrates the "hump" of acceptance. "Switch over
: completely or suffer inconvenience" does *not* cut to the heart of the
: UNIX philosophy. It is closer to the religious passions that retard
: UNIX than it is to UNIX strengths.
<enter quibble mode>
s/The perl answer/Some people's answer/ || warn "Larry is unhappy.\n";
If perl is saying "so what, just rewrite Pnews in perl" and "Switch over
completely or suffer inconvenience", then it's not the perl I know.
The perl I know reads from stdin and writes to stdout just like any
other filter, and it encourages you to write incoming and outgoing
pipelines of other unix tools. It even lets you feed multiple pipelines
simultaneously and close them down in any order. Not even the C library's
popen() lets you do that.
<exit quibble mode>
Anyway, folks, just because something CAN be done in perl doesn't mean it
SHOULD be done in perl. Likewise for shell, awk, C, etc.
Perl is just one more option. Use when reasonable. Your definition of
reasonable is probably different from the next guy's. My definition of
reasonable says you should at least make it available on your system
sometime within the next two years. Your mileage may vary.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govjim@eda.com (Jim Budler) (11/23/89)
emv@math.lsa.umich.edu (Edward Vielmetti) writes: } We really need comp.lang.perl to get this discussion in } the right perspective. } Did the person (at a uucp-only site) collecting votes fall } off the earth? } --Ed No he has collected several hundred, and reported on it in the perl mailing list. He has also mentioned that he is following the rules absolutely, and I think you'll hear from him when the thirty days has completed. Probably the results posting will be made within seconds of the voting period expiration 8^) People have objected to mid-period tallies and mid-period reminders, so I think he's passing on that. This vote is kinda boring after some of the recent ones, isn't it? 8^) jim -- Jim Budler jim@eda.com ...!{decwrl,uunet}!eda!jim compuserve: 72415,1200 applelink: D4619 voice: +1 408 986-9585 fax: +1 408 748-1032
jv@mh.nl (Johan Vromans) (11/23/89)
In article <3301@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: In article <222@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes: |(BTW, our "xferstats" is in /usr/spool/uucp/LOG, not /usr/spool/.Admin.) I'll bet Johan will make it a switch or dynamically determined thing if you ask him to. (To be honest: I couldn't find the file format anymore. That's why I concentrated to HDB-UUCP). (Okay, I'll revise it...) And while we're on the subject: my initial goal was to change the uutraf.c program to the output format of uutraf.pl. While considering this, I decided that a rewrite in perl was much easier, given its powerful form handling. The rest was -as Paul O'Neill mentioned- just fun. Johan -- Johan Vromans jv@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 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
cpcahil@virtech.uucp (Conor P. Cahill) (11/23/89)
In article <3374@convex.UUCP>, tchrist@convex.COM (Tom Christiansen) writes: > In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > |On System V/386, for instance, with all debugging #undef'd and with -O > |turned on, the latest perl executable *after* both 'strip' and 'mcs -d' > |subtends 229K, and takes ~5 seconds to load, compile and interpret an > |in-line script consisting of 'exit 0;'. > Which limitations, load time? Somewhere it does say that perl probably > isn't good for tiny machines. My idea of a tiny machine is my diskless > Sun 3/50 with 4 megabytes. Here are three successive timings: > > sun% /bin/time perl -e 'exit 0;' > 4.5 real 0.0 user 0.4 sys > 1.2 real 0.0 user 0.2 sys > 1.3 real 0.0 user 0.1 sys On my high end 386 the timings for a untouched perl (non-stripped, no changes to source) are as follows: /bin/time perl -e 'exit 0;' 1.4 real 0.0 user 0.1 sys 0.1 real 0.0 user 0.0 sys 0.1 real 0.0 user 0.0 sys /bin/time uutraf # stuff that started this discussion 0.9 real 0.3 user 0.2 sys -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
sean@ms.uky.edu (Sean Casey) (11/23/89)
tchrist@convex.COM (Tom Christiansen) writes: |There are plenty of things perl is NOT good for. These including |(to my mind) debuggers and windowing applications. ^^^^^^^^^ ^^^^^^^^^^^^ Oh no! Don't tell Larry! Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** "If you'll go to Joe B's, I'll buy. How's that sound?" "Sounds free!"
allbery@NCoast.ORG (Brandon S. Allbery) (11/24/89)
A lot of people seem to be missing the point again. Perl is a tool for constructing complex tools. I spent yesterday at work writing a Perl script which converts data from a database into an "lp" configuration -- which requires a fairly complex manipulation of various entities (files, output of programs, etc.) The script is about 150 lines long and would *not* be fun to write as a shell script using e.g. sed or (n)awk. On the other hand, I do write little filters fairly often -- and rarely use Perl for them, preferring sed or awk. Perl is extremely useful, but using it for everything is ridiculous. Do you use a screwdriver to hammer nails? Don't get carried away with it, but use it *when it's the appropriate tool* and you'll be rewarded by your task becoming easier. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
pete@tcom.stc.co.uk (Peter Kendell) (11/24/89)
From article <25696FB9.7258@ateng.com>, by chip@ateng.com (Chip Salzenberg): > According to lemke@radius.UUCP (Steve Lemke): >>OK, but what about those of us who don't have perl? > > You may not know it, but you need Perl. Get it. I did. My machine (SVR2, 80286) can't build it. Now what? -- ---------------------------------------------------------------------------- | Peter Kendell <pete@tcom.stc.co.uk> | | ...{uunet!}mcvax!ukc!stc!pete | ----------------------------------------------------------------------------
csu@alembic.acs.com (Dave Mack) (11/25/89)
In article <1989Nov23.042958.2531@eda.com> jim@eda.com (Jim Budler) writes: >emv@math.lsa.umich.edu (Edward Vielmetti) writes: > > >} We really need comp.lang.perl to get this discussion in >} the right perspective. > >} Did the person (at a uucp-only site) collecting votes fall >} off the earth? > >} --Ed > > >No he has collected several hundred, and reported on it in the perl >mailing list. He has also mentioned that he is following the rules >absolutely, and I think you'll hear from him when the thirty days has >completed. Probably the results posting will be made within seconds of >the voting period expiration 8^) > >People have objected to mid-period tallies and mid-period reminders, >so I think he's passing on that. Perhaps someone should mention to this well-meaning but deluded soul that the current version of the guidelines calls for a 21-day, not a 30-day, voting period? :-) From the Nov. 6, 1989 posting of the New Newsgroup Creation Guidelines: 2) The voting period should last for at least 21 days, no matter what the preliminary results of the vote are. The exact date that the voting period will end should be stated in the call for votes. Only votes that arrive on the vote-taker's machine prior to this date may be counted. [...] The Result 1) At the completion of the 21 day voting period, the vote taker must post the vote tally and the E-mail addresses and (if available) names of the votes received to news.announce.newgroups and any other groups or mailing lists to which the original call for votes was posted. I, for one, see no urgent need to wait thirty days. -- Dave Mack
chip@ateng.com (Chip Salzenberg) (11/28/89)
According to pete@tcom.stc.co.uk (Peter Kendell): >From article <25696FB9.7258@ateng.com>, by chip@ateng.com (Chip Salzenberg): >> You may not know it, but you need Perl. Get it. > I did. My machine (SVR2, 80286) can't build it. Now what? Well, I've built Perl on a Xenix/286 system. It compiled in large model, with the compiler flag that forces big data items out of the main data segment. (The option "-Mt32" means that 32 bytes or more is "big".) If you don't have a compiler with -Mt#, then you've got a problem with more than Perl. Get a Real Compiler[tm]. Switch to Xenix/286. Or something. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "The Usenet, in a very real sense, does not exist."