laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
<pedantic> Four of the seven things you cited (if, else, for, while) aren't really functions, per se, but are flow-control
You may have noticed, in the full perlfunc man page, how the functions can be grouped into categories, and some of those categories are quite specialized -- some are even OS-specific (check the section about "Portability"). To the extent that your normal coding tasks don't take you through some of those categories, you never happen to need those functions. So what? It's good enough to have a vague sense about the categories that are out there, and then you just learn the functions as you need them (i.e. if you don't need them, don't bother and don't worry about it). As for PHP's 3000 functions, I suppose that probably relates to having a different perspective on "modularizing" code, and having a different threshold for the trade-off between creating a uniform run-time environment (bloated with functions that will only be used by 5% of PHP programmers), vs. managing a site-specific module library (where processes only load the functions they use, but there's somewhat more care needed for maintenance). If you counted up everything provided via supplemental CPAN modules, the total number of functions available in Perl is surely an order of magnitude greater than 3000. Thankfully, you really only need to learn about the ones that are relevant to your task. (But then, sometimes you have to figure out which of several alternative sets of functions would be best -- not a simple or linear task.) In reply to Re: functional functions
by graff
|
|