The following are comments I solicited from a veteran Perl user who has held positions at the "director of technology" level, spoken at Perl conferences and contributed to major CPAN projects. I do not necessarily agree with these comments but believe they are worthy of consideration at the 2017 Perl 5 Core Hackathon and in other contexts. -- jkeenan
I spend a lot of time thinking about this and in the end it comes down to two general categories of things. The first one is obvious stuff about how we communicate the worth of Perl to technology consumers, and support our existing user base. The second (and in my mind the most important one) has to do with the culture of Perl leadership and the decision making process our institutions and culture has. So I'll start with that one.
People have been talking about 'removing obstacles' and in general trying to cope with the problem of what to do about Perl's decline since I've been using Perl (20+ years). Its a topic that just comes up over and over. But when it comes down to it I really wonder if the community leadership really cares about this issue enough to actually look hard at themselves to see the cultural gut reactions and processes that in many ways are the true root cause of this decades long problem. There's no point in even starting a conversation about this topic if leadership is not willing to hear stuff that is outside their comfort zone. Because if the question really is 'what can we do to remove barriers to Perl adoption without really changing anything we are uncomfortable with" then the answer is "no" and that the end of the discuss.
Every time I've spoken with people in the leadership circle about these issues all I've ever gotten is argument and lack of care. I doubt very much that decisions are truly rooted in listening to what day in and day out Perl programmers are having trouble with. Leadership is a meritocracy but is it extremely self selecting; people involved are scratching their own itches for the most part and tend to exclude people that are saying things nobody wants to hear. It is a group that is excessively conservative and dominated by long term members that have vested interest in coasting rather than driving. Or at least from where I stand, a Perl programmer that is on the outskirts of leadership, that is what I see.
Here's a list of stuff that is clear to me is causing barriers to adoption but that leadership is very unwilling to her (and will just argue with me instead of listening as good leaders should).
Perl5 / Perl6 debacle: [# snip: Out of scope for Core Hackathon ]
Evolution of the language: Nothing useful have changed about core Perl5 syntax in decades. CPAN tries to step up but its a total mess and confusion around things that most programmer think of are stuff that is in core (Moo/Moose/Mojo::Base, etc, Promises/Futures/Mojo::Loop, etc.) If you do a survey of the features of languages that most programmers think of as vital for today, Perl is missing a lot of things. We have no clear architectural vision or goal (at least that is public). Again when I say this what I will get is 'anyone can contribute to porters' but if you look at Perl porters I really don't see a community that is very accepting of difference, or that shows understanding that we can't never update the language and at the same time 'remove barriers to adoption'. The two are antithetical.
Excessive conservatism: We emphasis back compatibility to the point that it stops us from evolving. That's fine but its not compatible with future growth. You can't have future growth if you are not willing to change stuff that suits the needs of today. Programmers in the wild are obviously willing to cope with a certain amount of breakage if its buying them real improvements. So if the question is 'how can we remove the barriers to adoption while maintaining 100% compatibility with all code written in Perl4 25 years ago' the answer is "we can't". Its a choice to make one way or another.
Unwillingness to forge connections to industry: Lots of companies use Perl, but we don't regularly invite CTOs to come sit on the board at the Perl Foundation and help us make decisions. We are reluctant to expend the decision making base and process. The last time anyone asked the Perl world "What do you want to see in Perl" was when Larry was polling the community for what should be in Perl6. I've never attended a YAPC event where there was a lot of executive types from companies using Perl.
These are significant leadership / cultural issues that in my mind are the core barriers to the type of change necessary for Perl5 growth. If leadership doesn't want to hear it, to rationally engage with it (instead of just argue with it) then we need to stop asked ourselves the question 'How to Grow Perl5' and be content with the the slow fade away we are currently on.
Well I guess that's a bit of a rant ;) I promised a more technical list that might not rankle the feathers, so here that is. These are items that I've not seen already covered, so its my additions. However I would say working on this stuff is pointless if nothing about what I've already said is going to be seriously thought over.
Web Service SDKs: Perl got its original fame as being the glue of the internet. Yet nowadays glue increasingly is web services. I know that Perl is pretty good at cooking up a quick home grown API to a web service but when I go to the home page of pretty much any new *.io startup they never have a Perl SDK or Perl examples. This lack gives the impression that nobody cares about Perl and is a significant barrier. When I tell my boss I gotta write the web service interfaces because the new web service we are using doesn't have a Perl SDK out of the box I pretty much always get told to use Python or something else. I'd suggest we need a serious outreach to all these web service companies to make sure they have a good Perl SDKs and for them to advertise it right next to the ones written in Python, Go, etc. We need to do that even if it means writing it for them.
Community Project Support: [#snip: mostly out of scope for core Hackathon]
Infrastructure as a service support: Perl is nearly always a second class citizen on all of the key IaaS projects. For example can you use Perl to write AWS Lambda or Azure Functions (answer is no)? We need to help those companies do what it takes to support us.
In general we need to do better at pulling in people outside the community into the leadership circle so that they have enough skin in the game to care about Perl. We are not going to grow at all without that.
Thanks, let me know if I can clarify anything. Feel free to share this as widely and publicly as you want.