in reply to Re^2: Program Not Printing Help
in thread Program Not Printing Help
Of course, the other aspect is that a C or C++ program will usually run faster (although not always), often slightly faster and more rarely much faster. But code speed is rarely that important. I am saying this although I am working daily with very large data sets (typically gigabytes or tens of GB, sometimes even more) and I need efficiency. But Perl is just efficient enough for my needs: if I have a program taking an hour to run in Perl, I don't really care if a program might take 50 minutes (this is the type of ratio we experience for our data- and IO-intensive processes, it would be different for computation-intensive processes). And quite often, a good use of Perl built-in efficient data structures will actually lead to Perl actually performing better.
A typical example of coding efficiency in Perl: last week a colleague of mine rewrote a C program in Perl. The 4,000-line C program (including .h files, etc.) was replaced by a less than 400-line Program. And this colleague is a good developer but only started Perl less than 2 months ago (OK, he took advantage of a program I had written doing something relatively similar, and I helped him a bit on a few fine points, but really not that much).
I am pretty sure that if I had done the porting (or should it be called translation? well, in this case, maybe it should really be called a rewrite) to Perl, the resulting program would have been even shorter (perhaps only about 300 lines), without sacrificing readability the slightest bit.
On a much shorter program like here, you will probably not see such high code-volume reduction ratios, but it can be still very significant.
All this to say that if you should start to use Perl, you might try to build on its much more powerful expressive capacities.
|
|---|