> Now now, don't blame Perl for your ugly Perl code; it's your own fault if you irresponsibly
> overuse all the shortcuts and extra features Perl has built in to make your life easier.
Lol. Well, my biggest problem with Perl is that when I have a clusterfuck of nested hashes and arrays, I end up finding which combination of sigils work by trial and error. Also, I don't like modularity and classes in Perl. So my scripts end up messy despite my efforts to clean them up. I can see how this is because of my ignorance, but I don't have these kinds of problems in C, C++ and C#.
> If there's an element at 9, there must be one at 8, 7, 6, etc.
Well, technically you can allocate an array of size 10 and don't even use elements 8, 7 and 6, but this has several problems, such as wasting memory and needing another bit array to know which elements to skip in for loops.
Also, lists of comparable types (ones for which you can tell if a < b) can be implemented as balanced trees or skip lists for much faster access (but still slower than arrays), but are usually just lists.
Anyway, as far as speed goes, my rule of thumb is that these operations are slow and should be minimised:
* Talking to a server over web.
* Talking to a Database.
* Disk reads and writes and some other syscalls.
* O(n*n) or slower operations (Includes calling O(n) operations in a loop).
Everything else is usually blazing fast and memory is plentiful, so it's OK not to try and be clever about optimization. This approach is sloppy and lazy, but works.