I have begun learning Perl. Shouldn’t be difficult for someone with several years experience in PHP, Java, Python and Bash, right? While the concepts are not that foreign (at least in terms of functional programming) it seems that the Perl philosophy of ‘TIMTOWDI’ (There is more than one way to do it) does more to hamper the language than help it.
I am sure that there are plenty of Perl lovers out there who will disagree with me on this, but it seems to create more confusion, more work, and less in the way of readable documentation. I am using a combination of the O’Reilly book Programming Perl – Third Edition and various web sources including the documentation at CPAN. However, finding a repeatable, consistent way of doing a thing (which I prefer in most cases) is out of the question. I do have a feeling, however, that as I go I will find the ways of doing things that I am most comfortable with and probably stick with those (unless there is a very good reason not to, as in performance issues.)
I think that perhaps the biggest hurdle I am currently trying to overcome is the way in which Perl handles Object Oriented programming (or rather, doesn’t). The disconnect is (in my opinion) caused by a combination of pseudo-OO concepts bolted on to a functional language, TIMTOWDI (even for inheritance) and the differences in use and require – where require will let you select a Perl file to include by location (for example require '/var/development/perl/MyPerl.pl') but use can only call modules in the @INC path. Further, when modules are called by use they are evaluated at compile time, while modules called with require and then import are evaluated at run time. So if you have a piece you wish to be initialized and evaluated at compile time (i.e. when the script calling it is first loaded) then you either need to install the module to your standard path, or you need to add the module’s directory to @INC in order to find it.
Personally, I think I actually prefer the second method (adding a module’s directory to @INC) since it allows for picking up whole applications, dropping them into a system and having the primary controlling script find it’s cwd and add it and any module-containing sub-directories to @INC. Again, however, I can see the reasoning behind run-time evaluation in situations where there is no guarantee that a module will be needed, unless certain conditions arise. (Like choosing which version of a subclass to include based on configuration or program conditions.)
So, while I can understand the need for more than one way to do a thing, there does seem to be a point where you need to say we have enough ways to do it, stop adding more! One thing I have not decided yet, however, is whether I will be porting SPDO to Perl any time soon. My initial feeling is not likely, but I may end up doing it as a learning excercise anyway.