I agree to disagree with you
Having advocacy spoken in your cause is good, until you realise that the advocate may express similar opinions, but use different arguments, some of them contradicting your own, to a point of dispute.
So finally to the conclusion. If you are like me, most programming you do is about gluing things together with libraries. Perl may not be the prettiest language, but we have so many libraries that you won’t have much time to see the ugliness. This is the reason why people stick with Perl, even though other languages have prettier syntax. It is so easy to get stuff done, and contribute your “stuff” back to the community, that we never even worry about the ugly syntax. It just goes away, and all we think about are solving our problems
I mean, thanks. “Yes, Perl is ugly, and Yes, I would’ve dumped it if I only could, and Yes, I feel like gorging my eyes out every time I use it but, those damn Perl Hackers just filled CPAN with so much stuff, that I can’t.” This isn’t “Perl is good”, but “Perl is bad, but CPAN makes it worth your while”. I’ve only skimmed the comments, but the names “Java” and “python” have already been spotted a couple of times.
try searching for your favorite programming topic on search.cpan. You will probably find that your problem has been solved in an easily-digestible library form. Clicking a few links just saved you from a week of coding
For some, the huge monolith that is CPAN is more a curse than a bless. Suppose you want to work with XML, how do you know whether you want XML::Parser, XML::Twig, XML::LibXML, or any of their derivatives? Suppose you finally settle on XML::Simple, and after a while, encounter some issues, you’ll then hit some newsgroup/forum/mailing list only to find out that you should “not use XML::Simple”. The rule of thumb when it comes to using CPAN is “familiarity through usage”. The user is expected to leaf through the dozens of seemingly similar modules and select that which looks the most fitting to his problem. If said module comes short, and with the knowledge of which features he really need, the user is then returning to CPAN for a more focused search, until the golden pot is struck.
Not that there’s anything wrong here, mind you. This process is essential to good software development. Learning about your problem is crucial to finding the best solution to it, pin-pointing the important features you need from a module is another good step. After all, if you only need something to test for whether the XML is well-formed, it means that a: any basic module will suffice and b: XML parsing isn’t one of the major problems of your program.
However, this attitude can also deter people from using CPAN, and coupled with the “Perl is ugly” stereotype, one get the feeling that maybe its better not using Perl altogether. The point I’m trying to push forth is that CPAN is a blessed occurrence, and once used, can’t be underestimated, but Perl true power and, dare I say, beauty is in the syntax.
In a nutshell, Perl was designed to be a programming language that is constructed as a spoken language.
Everything about it, all the “ugliness” that you might find: the “sigils”, context-based interpolation, the integration of functions as keywords in the core language, you name it. It’s all ideas that come from spoken language, and implemented in Perl.
This way, when you speak fluent Perl, you can express yourself better, make better use of the language, and truly fit it to your way of thinking, in a way no other language can. And it got an amazing modules library.