> Are there actually people that are still deploying new things in Perl?
My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this.
Yes, you can call them open core now. But still many companies are using the community edition and are served well by it.
I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!
I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...
Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!
Modern perl5 is ok. But the ecosystem is slowly deteriorating.
What I'm hoping for is that Perl 7 will enforce those "proper code conventions" and mitigate that deterioration. Making a lot of common pragmas the default is a good start there.
Nice, thanks for the link and for your contributions to OTRS, it has improved workflows tremendously on both companies I've set it up on. I've messed around on some of the source and template files for some dirty hacks over the years and did get the impression of it being very well structured and with pretty clear separation of concerns even though I'm not a Perl coder.
My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
[0] - https://github.com/OTRS/otrs
[1] - https://otrs.com/