It doesn't mean "no developers or support" because that's at least as true of newly invented languages that HN loves to get excited about. CPAN is a thing and has been for decades.
It doesn't mean "doesn't work, not delivered yet" because there it is.
It doesn't mean "no exciting features" because that's not true either.
It seems to be more of a condemnation than a description. I suspect it's really just a synonym for "passé, uncool, brings back memories of the 1990s I was trying to forget".
It's usually more indicative of a language that's found in existing codebases, but is no longer used to start new ones. If you join a team and someone in that team actually knows Perl, that's highly unusual these days.
It's the same kind of "dead" as Latin: lots of folks actively use it, but meeting someone that does is pretty dang unusual unless you work for the Catholic church, in which case "everyone still uses it, what's dead about it?"
I am not a developer, but a sysadmin, and I don't know much about perl since I haven't used it much in the last 15 years. But I do know that if you have to run commands for CPAN to install some packages your developer says are required, your in for a bad day.
I agree, but part of the problem is that CPAN is old, i.e. it's been around for years, so you can find very out-of-date documentation and advice on the web about how to install packages.
For example, if you find a page suggesting you run 'perl -MCPAN -e shell', and you try using that, you'll probably have a very bad time. Watch out for it trying to upgrade perl itself! There are newer, saner and nicer ways to access CPAN and install packages.
There's also possible conflicts between CPAN and your distribution's own packaged perl modules, but that's a common problem with any software you install yourself rather than through the distro's packaging scheme.
Look into cpanm, local::lib, the Cpanfile, perlbrew, and carton. There are multiple angles of attacking this issue that are better than the old CPAN shell.
Most likely, but as a Hail Mary last-ditch effort, it seems reasonable and probably better than nothing. "Raku" sounds at least 1% more interesting for a dev to look into trying than "Perl 6".
It's not the last version.
There are two latest versions of Perl, the perl5 variant, currently at 5.30.0, and the Perl 6 variant, but they use the Microsoft convention of years in the name.
Both have huge problems, perl5 being effectively dead and the most hated language amongst devs. (I'm still trying to save it via cperl though).
And Perl 6 interesting (I was the parrot backend maintainer, until they ditched it), but with no significant future.
Someone else suggested renaming Perl 5 to Perl 7, and that has some merits so long as it is 100% backwards compatible (no Python 3 improvements).
Maybe add a few default warnings for using "ugly" features - maybe just in a linter - perhaps not affecting the runtime at all?
One of TypeScript's strengths is that it is JavaScript, but you can configure tslint to help detect certain "bad" JavaScript. Or you can switch on stricter checks (and TypeScript could be just a name for a default list of strict error checks, depending on how you use it!).
Perl5 has linters (Perl::Critic, Perl::Lint). And warnings to keep you from using ugly features (if you assert compatibility with the 2010 release 5.12, strict mode is automatically turned on).
JavaScript actually copied its `‘use strict’` syntax from Perl's `use strict;` which in Perl is using a pragma, not a magical string literal that reconfigures the compiler.
You want types? Several systems exist, but the leading implementation is Type::Tiny.
A big part of Perl culture in the late 2000s and early 2010s was focused around rooting out horrible old practices and tutorials, defining good practices, and getting tooling to help. Perl Best Practices came out of in 2005. Some effort to describe these tools and techniques as “modern Perl” followed—check out the inaugural entry of the Modern Perl Books blog from 2009. http://www.modernperlbooks.com/mt/2009/01/
Since Perl5 did what you’re asking for, maybe you should check it out and see what Perl 5 looks like in 2019.
perl 7 would be a major bump beyond perl 6, but perl 5 has not even caught to 10% of Perl 6 yet. This a non goal for them.
For me it's the top goal, but I'm still only at 20%.
Calling this perl7 would have been a huge joke. Renaming the thing also doesn't help with the personnel who is doing the desastrous decisions they did in the last decade. Management need to change, not the name.
"Raku is an interesting new language with some neat features..." will be met with "Oh, you mean Perl 6? lol."
If Perl is dead, renaming the last version isn't going to change anything.