3 ms·

Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?

by goto11 6y ago

forgotmypw17 6y ago
I started a new project in Perl a couple of years ago precisely because it has remained stable and without breaking changes for all this time. It's a feature, not a bug, that the language has remained stable and backwards compatible all this time. I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded. I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself. I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
- tannhaeuser 6y ago
  TBH, Perl being frozen in time isn't by design but rather a result of the extremely long (15+ years?) cycle of releasing Perl 6/Raku. In its heyday, Perl used to introduce new features and sigills all the time in dot versions. Also, I don't think Perl can claim the moral high ground on stability when the languages Perl was supposed to replace, such as awk, are POSIX-standardized and have multiple interworking implementations, and Perl even shipped an aggressive awk-to-Perl converter (a2p). As a legacy of Perl, PCREs with capture groups and above-regular language features invading environments and especially web frameworks and JavaScript also are of dubious value because of the attack vectors they bring.
  - forgotmypw17 6y ago
    Fair points... But that's what has happened, and whatever the reasons, I am grateful for the blessings. Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
    - tannhaeuser 6y ago
      Yeah on a second reading I didn't want to come down on Perl too harshly even though I still have memories of that moment where I had to listen to someone telling me "What, awk? We're doing Perl these days!" plus 3 not-so-pleasant projects over the years where we had to re-implement Perl systems. OTOH there are a couple of Perl tools that I still use (or whish I'd still be able to use), and I'm grateful those exist and Perl 5 is being maintained: Norman Walsh's SGML DTD documentation generator, the old citeseer code base (infinitely more useful than it's today), Debian's apache a2enmod/a2ensite management tools (that I've partly rewritten in shell) and apt tools. I even wouldn't hesitate to use RequestTracker tools (ticket management over mail) today even though it might not scale all that well.
  - raiph 6y ago
    My view: The first version of PCRE was released in 1997, first Perl that supported PCRE in 2009. Claiming PCRE is "a legacy of Perl" is like saying C is a legacy of C#. Calling a2p "aggressive" because it did a surprisingly good job converting awk to perl is like saying useful technology is aggressive. Perl wasn't supposed to replace awk. It was designed to integrate features of C, shell, sed, and awk into one tool. That was spectacularly useful. Perl is a high point in PL stability, still correctly running most Perl 4 scripts from the last century, with active community support for versions of Perl from 15 years ago. This is despite continuous evolution, eg adding Unicode support, in contrast to POSIX ("printable ASCII characters, space, BEL, backspace, tab, carriage return, newline, vertical tab, form feed, and null"). "Perl used to introduce ... sigills all the time in dot versions." Perl has never introduced a new sigil. Perl maintains backwards compatibility despite also evolving because it's maintained by smart and conscientious professionals. The OP discussion of the future is a continuation of that same philosophy.
petre 6y ago
Ruby is a more logical choice, or Elixir, depending on your usage domain. Or maybe Python or Julia if using PDL? Raku is nice but still slow and not there yet. No nice http framework like Mojolicious for one, not enough libraries to get stuff done. Pdf support is still quite lacking in Perl for instance. Good luck churning out a nice looking report for a client.
- raiph 6y ago
  > Raku is nice but still slow and not there yet. I agree with that general sentiment in some respects, but: > No nice http framework like Mojolicious for one Cro is still in beta but it's nice and popularly used as an equivalent to Mojolicious.[1] > not enough libraries to get stuff done. One can write: use Library::Foo:from<Perl5>; in Raku to use Perl libraries via Raku's Perl Inline. That is to say, Raku can use tens of thousands of mature libraries from CPAN. Stefan Seifert, creator of many of the Inlines, is using Catalyst in Raku in a production setting as part of his "battle hardening" work for the Perl Inline.[2] (If Cro didn't exist, I daresay some folk would be using Mojolicious in Raku as well.) > Pdf support is still quite lacking in Perl for instance. I don't use Perl much these days but I'm surprised you're saying support is lacking. Metacpan lists over 700 PDF packages, so presumably something like a few thousand PDF modules. Are you saying they aren't up to the task of churning out a nice looking report? In the meantime, David Warring's suite of PDF modules for Raku are highly capable.[3] And the ability to use modules from other PLs in Raku isn't limited to Perl, even if it's currently smoothest for using Perl libraries, so one can use PDF libraries from, say, Python. [1] https://cro.services/ https://cro.services/ [2] https://raku.land/?q=Inline https://raku.land/?q=Inline [3] https://raku.land/?q=pdf https://raku.land/?q=pdf
- moonchild 6y ago
  > slow Raku performance is decent enough where it has to be, and continues, slowly, to improve. I would be seriously surprised if cpython outperformed it, and python gets used quite a lot in the same domains.
iso1210 6y ago
Perl 5, although I try to write new stuff in python now to help the rest of the team. Still write the occasional webpage in perl -- it ususaly starts off as a one liner with grep, sed, etc, but I refactor into perl if it gets complex, been burnt too many times with simple bash scripts becomes more complicated as times goes on Wrote a poller last year for a bunch of baudion devices to tell me the current configuration of them, outputting as a csv (for version control) or webpage (for nice formatting). It's basically configure an array (qw//) of IPs and snmp strings, run some snmpwalks (not gets as the oids can change depending) - if it fails try the second IP, pull out the useful data, mangle it a bit, then output code like my $locM = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip sysName`; my $locR = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $resip sysName`; and if ($ver =~ /SR1/) { $eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.2.0`; $eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.3.0`; } else { $eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.0`; $eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.1`; } and my $cmd = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip 1.3.6.1.4.1.22425.10.5.3.5.1.$oid_rxip`; foreach (split(/\n/, $cmd)) { next unless (/.../); next if (/0.0.0.0/); s/[" ]*//g; $srcs->{$_} = 1; } and if ($mainip eq $resip) { $alert .= "NO SECOND IP"; } if ($locM ne $locR) { $alert .= "Sysname Mismatch"; } It does the job, it doesn't rely on external language-specific libraries like Net::SNMP which complicates portability. There no doubt far nicer ways to do it, but my process involves * Prod device to get original information using things like nmap, curl, snmpwalk, etc * Mangle retrieved information to infer extra information * Present information Perl allows me to get from my prodding to useful output in minimal time, going from initial results from prodduing, to functioning output, in well under an hour. Python could probably do something similar, but things like /([0-9]*)kbit.*([0-9]*)kbit/; my $inBit = 1000*$1; my $outBit = 1000*$2; Is lovely and quick to type up for me compared with something like inBit = 0 outBit = 0 matches = re.match(".*([0-9]*)kbit.*([0-9]*)kbit/, line); if (matches): inBit = 1000*(int(matches.groups()[0])) outBit = 1000*(int(matches.groups()[1])) Ultimatly I don't care about elegant resuable code, I care about the results (a page telling me the bitrate on the stream, or that a destination IP has been changed or whatever)

Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?

by goto11 6y ago

Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?

I started a new project in Perl a couple of years ago precisely because it has remained stable and without breaking changes for all this time. It's a feature, not a bug, that the language has remained stable and backwards compatible all this time. I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded. I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself. I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.

tannhaeuser 6y ago
TBH, Perl being frozen in time isn't by design but rather a result of the extremely long (15+ years?) cycle of releasing Perl 6/Raku. In its heyday, Perl used to introduce new features and sigills all the time in dot versions. Also, I don't think Perl can claim the moral high ground on stability when the languages Perl was supposed to replace, such as awk, are POSIX-standardized and have multiple interworking implementations, and Perl even shipped an aggressive awk-to-Perl converter (a2p). As a legacy of Perl, PCREs with capture groups and above-regular language features invading environments and especially web frameworks and JavaScript also are of dubious value because of the attack vectors they bring.
- forgotmypw17 6y ago
  Fair points... But that's what has happened, and whatever the reasons, I am grateful for the blessings. Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
  - tannhaeuser 6y ago
    Yeah on a second reading I didn't want to come down on Perl too harshly even though I still have memories of that moment where I had to listen to someone telling me "What, awk? We're doing Perl these days!" plus 3 not-so-pleasant projects over the years where we had to re-implement Perl systems. OTOH there are a couple of Perl tools that I still use (or whish I'd still be able to use), and I'm grateful those exist and Perl 5 is being maintained: Norman Walsh's SGML DTD documentation generator, the old citeseer code base (infinitely more useful than it's today), Debian's apache a2enmod/a2ensite management tools (that I've partly rewritten in shell) and apt tools. I even wouldn't hesitate to use RequestTracker tools (ticket management over mail) today even though it might not scale all that well.
- raiph 6y ago
  My view: The first version of PCRE was released in 1997, first Perl that supported PCRE in 2009. Claiming PCRE is "a legacy of Perl" is like saying C is a legacy of C#. Calling a2p "aggressive" because it did a surprisingly good job converting awk to perl is like saying useful technology is aggressive. Perl wasn't supposed to replace awk. It was designed to integrate features of C, shell, sed, and awk into one tool. That was spectacularly useful. Perl is a high point in PL stability, still correctly running most Perl 4 scripts from the last century, with active community support for versions of Perl from 15 years ago. This is despite continuous evolution, eg adding Unicode support, in contrast to POSIX ("printable ASCII characters, space, BEL, backspace, tab, carriage return, newline, vertical tab, form feed, and null"). "Perl used to introduce ... sigills all the time in dot versions." Perl has never introduced a new sigil. Perl maintains backwards compatibility despite also evolving because it's maintained by smart and conscientious professionals. The OP discussion of the future is a continuation of that same philosophy.

petre 6y ago

Ruby is a more logical choice, or Elixir, depending on your usage domain. Or maybe Python or Julia if using PDL? Raku is nice but still slow and not there yet. No nice http framework like Mojolicious for one, not enough libraries to get stuff done. Pdf support is still quite lacking in Perl for instance. Good luck churning out a nice looking report for a client.

raiph 6y ago
> Raku is nice but still slow and not there yet. I agree with that general sentiment in some respects, but: > No nice http framework like Mojolicious for one Cro is still in beta but it's nice and popularly used as an equivalent to Mojolicious.[1] > not enough libraries to get stuff done. One can write: use Library::Foo:from<Perl5>; in Raku to use Perl libraries via Raku's Perl Inline. That is to say, Raku can use tens of thousands of mature libraries from CPAN. Stefan Seifert, creator of many of the Inlines, is using Catalyst in Raku in a production setting as part of his "battle hardening" work for the Perl Inline.[2] (If Cro didn't exist, I daresay some folk would be using Mojolicious in Raku as well.) > Pdf support is still quite lacking in Perl for instance. I don't use Perl much these days but I'm surprised you're saying support is lacking. Metacpan lists over 700 PDF packages, so presumably something like a few thousand PDF modules. Are you saying they aren't up to the task of churning out a nice looking report? In the meantime, David Warring's suite of PDF modules for Raku are highly capable.[3] And the ability to use modules from other PLs in Raku isn't limited to Perl, even if it's currently smoothest for using Perl libraries, so one can use PDF libraries from, say, Python. [1] https://cro.services/ https://cro.services/ [2] https://raku.land/?q=Inline https://raku.land/?q=Inline [3] https://raku.land/?q=pdf https://raku.land/?q=pdf
moonchild 6y ago
> slow Raku performance is decent enough where it has to be, and continues, slowly, to improve. I would be seriously surprised if cpython outperformed it, and python gets used quite a lot in the same domains.

iso1210 6y ago

Perl 5, although I try to write new stuff in python now to help the rest of the team. Still write the occasional webpage in perl -- it ususaly starts off as a one liner with grep, sed, etc, but I refactor into perl if it gets complex, been burnt too many times with simple bash scripts becomes more complicated as times goes on Wrote a poller last year for a bunch of baudion devices to tell me the current configuration of them, outputting as a csv (for version control) or webpage (for nice formatting). It's basically configure an array (qw//) of IPs and snmp strings, run some snmpwalks (not gets as the oids can change depending) - if it fails try the second IP, pull out the useful data, mangle it a bit, then output code like my $locM = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip sysName`; my $locR = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $resip sysName`; and if ($ver =~ /SR1/) { $eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.2.0`; $eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.3.0`; } else { $eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.0`; $eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.1`; } and my $cmd = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip 1.3.6.1.4.1.22425.10.5.3.5.1.$oid_rxip`; foreach (split(/\n/, $cmd)) { next unless (/.../); next if (/0.0.0.0/); s/[" ]*//g; $srcs->{$_} = 1; } and if ($mainip eq $resip) { $alert .= "NO SECOND IP"; } if ($locM ne $locR) { $alert .= "Sysname Mismatch"; } It does the job, it doesn't rely on external language-specific libraries like Net::SNMP which complicates portability. There no doubt far nicer ways to do it, but my process involves * Prod device to get original information using things like nmap, curl, snmpwalk, etc * Mangle retrieved information to infer extra information * Present information Perl allows me to get from my prodding to useful output in minimal time, going from initial results from prodduing, to functioning output, in well under an hour. Python could probably do something similar, but things like /([0-9]*)kbit.*([0-9]*)kbit/; my $inBit = 1000*$1; my $outBit = 1000*$2; Is lovely and quick to type up for me compared with something like inBit = 0 outBit = 0 matches = re.match(".*([0-9]*)kbit.*([0-9]*)kbit/, line); if (matches): inBit = 1000*(int(matches.groups()[0])) outBit = 1000*(int(matches.groups()[1])) Ultimatly I don't care about elegant resuable code, I care about the results (a page telling me the bitrate on the stream, or that a destination IP has been changed or whatever)