Well, you can write very obfuscated code if you're lazy in a bad way. Badly written Perl code is a maintainers nightmare. Perl was not designed for OO, that is, it is not pure OO-language and thus lacks some of stuff pure OO languages have.
Also, Perl's performance in some cases does not meet, for example, C performance in heavy calculations, like encrypting/decrypting (although this can be avoided by using perlxs and writing the performance sensitive parts in another language, C being the model example).
--
seek $her, $from, $everywhere if exists $true{love};
| [reply]
[d/l] |
This sort of thing all depends on the audience you are presenting to, the fact you are focusing on the weak points later on in the thread indicates to me you are trying to convince people the negatives are not bad or are looking for something else. If you are presenting this, and its balanced, you don't need depth of the negatives, if you are proposing this as a solution you need to focus more on the positives and what this is going to gain this group who is going to have to learn it. Of course, if you think they will be resistant to Perl, then you want more positives to get them on board, negatives and weaknesses will only give them outs to not get on board and deny you the use of Perl.
Of course it all depends on what you intend to be using this for, to me Perl was a good fit for what we wanted to do because most of our work was in manipulation of text files and directory tree creation. Perl did what we needed, in a way that worked well for the product we were using. I think you have a good overview of what Perl can and can't do here, but you had better be sure that what you are presenting is the best solution and why it is so otherwise no presentation and/or set of slides is going to compensate for a lack of enthusiasm. | [reply] |
