Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!oz.cis.ohio-state.edu!jgreely From: jgreely@oz.cis.ohio-state.edu (J Greely) Newsgroups: alt.sources.d Subject: Re: uutraffic report (in perl) Message-ID: Date: 22 Nov 89 15:02:25 GMT References: <4025@mhres.mh.nl> <1194@radius.UUCP> <3273@convex.UUCP> <14946@bfmny0.UU.NET> <14947@bfmny0.UU.NET> Sender: news@tut.cis.ohio-state.edu Reply-To: J Greely Organization: Ohio State University Computer and Information Science Lines: 82 In-reply-to: tneff@bfmny0.UU.NET's message of 22 Nov 89 04:24:11 GMT In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >In article J Greely > 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 , 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 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)