That would be quite a waste of a good thing. It’s a really fun and powerful language.
I don’t use it anymore because of the culture of hating on it from non-users, who have just hounded users so much that they have succeeded in dampening the fun a lot. I mean you can’t even talk about it in HN without encountering some serious negativity, usually uninformed. It’s unpleasant.
On the good side, there are other great languages that don’t have this problem.
Sunken costs fallacy would apply if someone said "well, I spent so much time learning it, I might as well keep using it even though the environment is so hostile."
So, that's exactly the path I'm not taking. I'm disregarding any sunken costs. The sunken costs fallacy applies to those who would cling on to a path, not those who leave it.
But maybe you're using it from a different perspective.
If it’s going to die anyway then what’s wrong in trying to modernise it and seeing if that does renew interest? Worst case scenario is people don’t migrate and that outcome is no different to if you hadn’t tried. So it feels like the only bad move is not to try at all.
If modernising it splits the community and doesn't suceed, you've redone the Perl6 fiasco, but probably killed both 5 and 7.
Is that better than driving Perl 5 to a stable end? I don't really think so. But I'm not involved in the development of Perl, I'll just keep writing Perl scripts until it gets hard to install.
Perl is going to die if they don’t do anything anyway. So absolute it’s better to risk fragmenting the ecosystem.
If your result for inaction is eventual death anyway, then the sensible thing is to go out swinging. At least that way you have a half chance of reviving the language — which is better than the zero chance you have if you do nothing.
Why would you hang your career on the fate of a single language? Most of the knowledge transfers just fine between languages. Over a career you can become an expert in several of them.
You shouldn't hang your career on any one language.
But languages themselves are almost trivial.
Knowledge of libraries, and community expectations around them, doesn't translate well between languages.
And personal libraries, laden with solutions for the domains you've tended to specialise in, don't translate at all. You basically have to start from scratch, which is a huge loss if they are genuinely useful and took years to develop and accumulate.
You can't just rewrite those quickly, and you're unlikely to find a third party library in any language that solves the same problems.
I can see how this may be meaningless to someone whose career consists of moving from company to company, never carrying anything forward other than what's in their head. But some people carry forward substantial personal libraries which they use.
The loss of those can easily be a 10x loss in productivity, so switching to a new language and its entire ecosystem can be a big and expensive step, compared with not doing so.
Yes, over a career you can become expert in several. I would even say quite a lot. And yes, you can always learn new things.
But there will be times when you lose a lot of your advantages due to starting from scratch with something new. That's a big cost, it shouldn't be ignored.
When it's necessary, such as learning an ML framework, say, it's a justified cost, and everyone pays it.
But when it's just due to changing fashions it's a bit galling, and difficult to justify when is the right time. So much is lost.
> Most of the knowledge transfers just fine between languages.
A rather low-level example (nothing like understanding good abstraction/design), but useful because it's apparently not obvious - co-workers didn't believe it until I demonstrated with short example programs: Reference semantics are identical between javascript, python, and java.
(The first two being the primary languages we use, I don't remember how java came up that day - I know others are also the same)
You can certainly know multiple languages, but if you are involved deeper in the runtime and language design there is specific investment. I myself did a lot of PHP, went deep into the engine, nowadays do more with other languages where I can transfer some knowledge, but I guess even 5 years after writing my last relevant amounts of PHP I could jump in a consulting gig easily, while for other environments I have to spend more time preparing.
Blub languages are all alike; every powerful language is powerful in its own way. It's hard to reuse what I learned about Lisp macros or Python decorators or Scala implicits in other languages that don't have anything like that. The result tends to be reams of cringeworthy boilerplate because that's the only thing that works in every language.
there won't be new developers if they don't move the language past its present state. there's no reason for anyone to learn perl except for a job maintaining legacy software at this point, but that could change if they manage to refashion it to attract new interest
that said I don't know what kind of "special training" you need to pick up a new language. I got hired for a perl job despite never having written it. the conversation went something like "can you write c?" "yep." "can you write shell scripts?" "yep." "ok, you can write perl." read what the sigils meant and could write it with minimal competence same day. expertise and nuance can come as you go
