On Thu, Mar 27, 2008 at 2:22 PM, Rob Dixon <[EMAIL PROTECTED]> wrote: > > Yes I understood your intention, but efficiency isn't everything by any > means. I believe very firmly that programs should be coded in the > clearest and most obvious way possible, then tested and optimised if the > performance is inadequate.
In general, I agree with you; but I maintain that "clear" and "obvious" are subject to interpretation. I also maintain that using grep to feed input to a for loop isn't obvious, whereas using grep to optimize out a loop is. There is nothing that grep does that can't be done in a loop, and we normally use grep when, for whatever reason, we want to avoid a loop. > The most natural way to print a list of data > is simply to print each item, and to code it differently from that is to > start on the road of efficiency at the cost of intelligibility. Again, I don't entirely disagree. But this thread isn't about the most natural way to print lists. It's about grep. > In any > case, if someone offered me a way of making my program run in 20ms > instead of 25ms I wouldn't be overly impressed, and certainly don't see > it as a case of grep 'shining'. > I think you missed my point. I may not have been clear. No, shaving a few ms off runtime isn't shining. But it's an *example* of the *type* of thing grep shines at. That is, taking loops and tunring them into blocks, and cutting out, in this case, 999 system calls. Are the savings anything to write home about? No, of course not. But the *idea* is fantastic, and in a more complicated situation often leads to not just faster execution, but saved programmer time, increased clarity, and simplified control structures. Again, it's not about a few prints in this particular made-up case. It's about the types of things grep really does well. > My guess is that optimising out print calls would be less, not more > effective than with most subroutines: all it does is to append the > passed-in data to the output buffer, and the system call is performed > only when that buffer is filled. > Well, that depends entirely on what file handle you're printing to. If you're printing to STDOUT, as all these examples so far have, each newline--and therefore each pass though the loop that matches the condition--flushes the buffer. > > > This doesn't really have anything to do with Perl; it's true in any > > language. > > Yes, but now you mention it I would be surprised to see this technique > used in C: That's because C doesn't have grep. The extra variable assignments and sprintfs you need to make the "equivalent" C code eat up any potential gains. The situation of he two languages isn't at all comparable. > > > > TIMTOWTDI isn't what gives Perl a bad name; it's what makes it the > > wonderful, flexible tool that it is, and crates passionate groups of > > users like this one. > > My concern is that Perl has a reputation for appearing to be an > unintelligible string of symbols, and I am wary of anything that even > leans in that direction. > Point well taken. But this is a thread about grep; and grep's raison d'etre is optimizing out loops. I don't think giving an example that shows grep cutting a loop is out of order. I certainly hope it wasn't unintelligible. It's also the little optimizations (like grep and map) that are built into the language that set Perl apart from the crowd. Best, -- jay -------------------------------------------------- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org values of β will give rise to dom!
