3 ms·
I used to use Perl. Then I followed Yegge's advice of "I will only use Perl if there's no other option, and there's always another option." https://sites.goog
by danielweber 13y ago
I used to use Perl. Then I followed Yegge's advice of "I will only use Perl if there's no other option, and there's always another option." https://sites.google.com/site/steveyegge2/ancient-languages-perl https://sites.google.com/site/steveyegge2/ancient-languages-...
I'm not trying to dump on perl. I love C and C++ and those get dumped on all the time and I hate it. But anything I could do in Perl I instead do in Ruby. It's not as fast, but if fast matters I'm not supposed to use a scripting language.
- DougWebb 13y agoBut anything I could do in Perl I instead do in Ruby. It's not as fast, but if fast matters I'm not supposed to use a scripting language. Perl can actually be very fast; it depends on what you're doing and how you write it. A lot of developers don't realize that Perl isn't really a scripting language; it's a compiled language that has a compiler that's so fast it can be run every time you run the program. The compiler produces bytecode, and the bytecode runs on a virtual machine, just like Java and C#. The key to writing fast Perl code is to use programming constructs that compile down to single bytecode operations, because those operations are implemented in the VM using well-tuned C code. For example, using grep and map with array variables is much faster than using a for loop and explicitly indexing through the array. With the former, the enumeration is handled in C code, while in the latter it's handled in Perl code. Note: that's probably not 100% accurate, but it's the general idea. You can actually have perl output the bytecode it generates so you can take a look at it, and figure out places where changing how your code is structured will produce more efficient bytecode.