Earlier quoted context omitted.
> In 2013 nearly every problem has a language more appropriate than Perl. Citation needed. Seriously, please stop making such broad statements based on your feelings and opinions and instead please make an earnest effort to separate objective facts from your subjective perception. And just to address another point: Perl has multiple real object systems that are inter-compatible (with one small exception), and are con…
I'd say the onus is on Perl to be the best language for a niche, rather than on me to provide a list of niches with languages better than Perl. Besides that, language appropriateness is necessarily subjective. I love Prolog and Haskell and use them all the time. My passion for them makes their thorns seem small and easily avoided, but the reality is that those thorns are sufficient to keep out a lot of curious people…
Also, no, i did not take it as an insult, just as a false statement from someone with little knowledge of the subject matter.
> I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. One doesn't "choose" an "object system" for Python--what benefit would one hope to gain?
That question is actually understandable and easily answered. Two benefits:
1. More expressive power for example. Perl has Roles that function in a way unmatched by most other languages (i say most because i don't know all languages, i honestly don't know one that has roles as good as perl). They make it possible to share methods among classes without needing to resort to base classes and diamond inheritance issues, while still retaining full introspection capabilities. Another system implements most of the sugar, but leaves out some really complicated features in order to make it much faster. Yet another provides the most speed by implementing the core in C. This makes it a bit harder to debug, and less portable, but if you need massive speed, there you go.
2. The ability to try out different things and work out in real life situations which features are needed and which ones are dead ends. This ability is amplified by the ability to simply extend your object system by writing more Perl. In comparison, Ruby has an ubiquitous one, but when they desire to change it, they cannot easily test the changes large-scale in real situations, and even if a change is undoubtably positive, they still have to convince Matz first, and then implement it in C.
> indisputably more work for everyone than just having one.
Actually that is disputable. In the past it was the case, yes. But nowadays they have converged on the same syntax and present themselves identically to consumers. That means porting between different systems is trivial, and people using a class don't even notice changes. And that is not just fluff. The perl community has been doing this actively, for example here:
https://github.com/rjbs/Email-Sender/compare/52fcbbb9b6a1c4a...
I'm not going to comment on your last paragraph because you wrote it while having decided that what you wrote before is actual fact and it is thus very flawed. Please stop doing that and use more question marks.