Re^2: Perl vs. Compilable Language

Unless you are making a production system, application, or library that will be run many, many times, programmer productivity is probably more important than code efficiency.

The fact that it will run many times doesn't mean efficiency is the biggest of concerns.

I've seen a guy who did that kind of systems saying that efficiency didn't matter for him; what mattered was that things worked.

If your system running is going to slow down others, or delay something, *then* you have to worry about efficiency.

That, of course, for certain values of efficiency :-)

YMMV, of course :-)

Comment on Re^2: Perl vs. Compilable Language

Replies are listed 'Best First'.
Re^3: Perl vs. Compilable Language by samizdat (Vicar) on May 02, 2005 at 13:09 UTC
And then, of course, we have to look at what kind of efficiency... cpu cycles, latency, memory usage, etc. You're absolutely correct in that raw cpu cycles are rarely the best optimization. In fact, on a multiuser system, a background task run through cron is often better implemented in samll chunks, i.e. shell script or Perl w/ system calls, just so the scheduler gets more chances to take back control to give to another user process. Woefully "inefficient" but far better for the health of the system.	[reply]

Replies are listed 'Best First'.

Re^3: Perl vs. Compilable Language
by samizdat (Vicar) on May 02, 2005 at 13:09 UTC

And then, of course, we have to look at what kind of efficiency... cpu cycles, latency, memory usage, etc. You're absolutely correct in that raw cpu cycles are rarely the best optimization. In fact, on a multiuser system, a background task run through cron is often better implemented in samll chunks, i.e. shell script or Perl w/ system calls, just so the scheduler gets more chances to take back control to give to another user process. Woefully "inefficient" but far better for the health of the system.

[reply]