Re: when to c, when to perl

Rule of thumb: code it in Perl. If it's fast enough, job done. If it's too slow, profile then either fix the algorithm, or push the slow bits into C using XS.

Perl is very fast for prototyping, and if the result is fast enough then you can spend the time you saved tossing back beers or whatever. Very often you can stick with Perl for the vast majority of the code and concentrate on speeding up the bottle neck chunks in C and still have time to swill a few beers at the end of the day. Even if you end up rewriting most or all of the code in C, at least you have a good tested prototype to work from.

Perl is environmentally friendly - it saves trees

Comment on Re: when to c, when to perl

Replies are listed 'Best First'.
Re^2: when to c, when to perl by massa (Hermit) on Jul 25, 2008 at 11:40 UTC
I would correct a little bit on your rule of thumb: before coding in Perl, search CPAN for solutions that you can integrate. More often than not IME there will be a nice, optimized, XSed module that does the slow. YMMV, of course :-) []s, HTH, Massa (κς,πμ,πλ)	[reply]
Re^3: when to c, when to perl by GrandFather (Saint) on Jul 25, 2008 at 19:13 UTC
That is simply part of "Code it in Perl" is it not? In like fashion one might long ago have said "Code it in FORTRAN" then optimise in assembly language, or "Code it in C" (which is almost assembly language anyway). (I've written in machine code, assembly language, FORTRAN and C, among other languages btw.) Perl reduces RSI - it saves typing	[reply]