That's the new headline that sums up Perl: an anachronistic programming language that may never recover from the perl 5->6 decade long 'freeze'. Also the language is crazy to write substantial programs in!
Making a backwards-incompatible change to a programming language == making and launching a new language, with all its difficulties.
I would not want to write anything big in Perl 5. But for small-ish scripts (say, less than a thousand lines) it is pretty hard to beat.
This is not so much a problem with the language as it is with programmers not learning to agree on a set of idioms that they will use for a project. They are not reading each others code and having discussions about what they want to see.
Languages that impose "the one true way" cut down on the apparent problems, but you are still going to have massive issues down the road if you build large projects because nobody is paying attention to what the other people are doing. Especially on large projects, it is vital that people read and comment usefully about design issues. In such large projects, removing the choice of idioms available though language design is a bit like deciding not to carry a canary down the mine with you because it keeps getting killed by poisonous gas.
The expressiveness of Perl allows you to choose the idioms that will work best for your team/project. It is true that it requires more discipline and communication, but these are the things that are necessary for success on a big project anyway.
I haven't written any Perl code for years now, but I have always been fond of it. I find that I can write better code in Perl than in many of the more restrictive languages that I've used.
This isn't even remotely true. No static types, no thank you. Runtime errors due to misspelled methods? Missing hash keys? Hilarious.
Boy, I hope this scalar isn't undefined!
As for missing hash keys... It sounds like you are using a hash when you really want an object. There are cases where that's preferable, but part of that trade-off is that you need to make sure the data is as you expect it. Perl 6 supports tightly packed (C struct equivalent) objects if you choose.
I can write a web application in some homebrew <insert language> and it can grow to 40 developers, 1000 db tables and thousands of files. But it would be terrible to work on (I know I've seen it). Or i can write the same thing with a framework, and have it much more manageable.
Realistically, when was the last time you say down and wrote a big application in vanilla <insert language>?
Perl 6 needs to find a problem that it can solve well. Perhaps a great web framework?