in reply to Re^3: How to capture compile errors from child program?
in thread How to capture compile errors from child program?

Thanks for the tip about benchmark. But I don't agree one should abandon Perl just because one measures some snippet execution in milliseconds. What you are most missing here is that one of the main reasons to use Perl is to avoid shelling out (or in) at all, in the first place. So those milliseconds can and will be optimised away with Perl! Conversely it is much more of a challenge (if even remotely possible) to do so with scripting languages that are not based on C, especially re Perl access to C libraries.

One world, one people

  • Comment on Re^4: How to capture compile errors from child program?

Replies are listed 'Best First'.
Re^5: How to capture compile errors from child program?
by kennethk (Abbot) on Aug 04, 2015 at 15:03 UTC

    Optimization is highly use-case dependent. If a particular use case dictates that the difference between the invocation weight of backticks, open, IPC::Open3, pipe/fork/exec or any other flavor of external call will be problematic, then it's reasonably likely Perl is a bad choice of context. Perl is a great choice of language for optimizing programmer vs. computer times, and generally timing doesn't really matter as long as global execution time is less than a second. But even the most diehard adherent should be willing to question whether they've chosen the right tool for the job at hand.


    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.