Recent searches
Search options
Hello #perl community, how do you actually do that? For example, if you want to use the really new Perl features (e.g. classes) in your libraries and want to publish them on CPAN. Do you then not use such features? Or can I publish code for different Perl versions? It would be cool if there was something like a Perl transpiler (similar to the JS/typescript world) where you can transpile modern Perl to low level Perl. e.g. when you install a package for a specific #perl version.
@leobm@norden.socialIn some packages on #metacpan you can see what the minimum Perl version must be. Is this binding? Looks to me like most packages often support very low Perl versions. Understandable, if you want the package to work with very old
Perl versions, but surely this prevents new #perl features from spreading very slowly?
@leobm MetaCPAN shows what the distribution self-describe about its minimum perl version, to be checked during build/install time. The code inside may use a different version.
It’s the author’s choice which versions they support, and then ensure correctness of metadata and code they publish.
Some choose to support back to perl-5.8 or 5.10. Others prefer using modern features. The Perl toolchain itself supports at least the last 10 years.
Related good read from @rjbs: https://rjbs.cloud/blog/2023/01/leaving-perl-v5.8-behind/
@ferki @rjbs Ok, thank you. But I'm thinking, it would be nice if you could somehow support different versions. I mean in the Scala community there is also a mechanism in the maven packages to support different Scala versions (or different bytecode). But maybe you rather need a mechanism (transpiler) where you can downgrade Perl code when you install it. But that's just a thought.
@leobm Right, too short space to react to every bit in a single reply 
While I find the transpiler idea intriguing, I also find that installing newer Perl versions (even separate ones for each use case) feels next to zero effort compared to writing, maintaining, and supporting a transpiler.
Using newer Perl versions, even without using its new features also brings bugfixes, including security ones.
I wonder, what (business? community?) problem would such transpiler effort solve exactly? 
@ferki That new Perl features are disseminated more quickly in development. Why should I use a new feature if I can't use it in practice? Or that you could theoretically realize backwards compatibility with it. A transpiler could be relatively intelligent or even deliver polyfills, for example.
I can only see that my company also uses Perl versions that are almost 10 years old. Simply because, for example, the operating system often lags far behind in the standard distribution.
@ferki This can be criticized
, but it is a reality in many companies that use Perl every day.
@leobm Interesting! My impression was that in general the system Perl is left alone for OS-related code, and custom/local solutions use their own Perl environment via perlbrew, plenv, containers, or similar. Including for newer-than-OS Perl versions to allow using modern features.
I once also read about an idea to fork CPAN along Perl versions, or have a mechanism to choose different CPAN sources based on the Perl version requested. IIRC it did not progress much beyond discussion, though.
It is possible to selectively use new features when available and fall back to the universal form when not, but it's tricky.
use Feature::Compat::Class;
is an example, it provides 5.38.0 (or 5.40.0)'s core feature 'class' Classes to Perl 5.38+, and provides Object::Pad non-core equivalent to older perls 5.14.0 ... 5.36.x .
@leobm I prefer backward compatibility over new language features. If I or a dependency use new features I set the minimum Perl version in the cpanfile of my distributions.