7 ms·

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control st

by R0b0t1 6y ago

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was literally made for this type of workload.

FreshFries 6y ago
There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live. I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers. /rant.
- johnisgood 6y ago
  I hate everything there is to hate about CPAN. I also hate how Perl libraries are handled. I have to have like 5 lines of code related to it in ~/.bashrc or ~/.bash_profile. Bleh. Perl libraries are always a problem when I want my program to run on other machines. No thank you.
  - esaym 6y ago
    I find this to be a weird statement. I've never really fought with "cpan" but have had huge fights with node and python packages. The old school "cpan" command has not been recommended to be used for nearly a decade now. Maybe that is your issue? Everyone just uses cpan-minus: http://cpanmin.us/ http://cpanmin.us/ or "cpanm". It will install anything, if you have write access to the installed perl location, it will install globally, otherwise it installs packages into "~/perl5" then just do something like "export PERL5LIB=~/perl5/lib/perl5/" in your bashrc. Or maybe you are talking about having to compile code in certain packages? Alot of stuff using ssl has C code which links against openssl which is always a pain. Not sure what other issues you might be alluding to... There are some "packaging" tools to try to bundle and pin libraries, kind of like venv for python. I've never messed with them though. We just compile the latest perl binary and install all our needed cpan modules globally. Never worry about pinning since nothing is ever updated on cpan anymore...
    - johnisgood 6y ago
      > The old school "cpan" command has not been recommended to be used for nearly a decade now. Maybe that is your issue? I did not know that it was not supposed to be used, so that might explain my issues, but at the same time it did work for me on my machine, but had a hard time running my Perl script on a VPS, because I had to set everything up again and for some reason I ran into some errors. I often ran into packages that failed to compile, too, yeah. > Never worry about pinning since nothing is ever updated on cpan anymore... Nothing makes it kind of sad. :/
- threeqhan 6y ago
  Sheer as in "unmitigated" and shear as in sheep But I agree with this, except for python
- esaym 6y ago
  I think the OP is mostly talking about "perl one liners" on the shell like this: https://catonmat.net/ftp/perl1line.txt https://catonmat.net/ftp/perl1line.txt It is not that hard either (unless perl is completely foreign to you). Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files only to have 5 extra opus files... I beat my head really good trying to glue a bunch of bash stuff together but I could not find where the 5 extra opus files were coming from. I defected back to perl. All I needed was an alphabetical list of all the files (there were many sub-directories), perfect for a little perl oneliner: find /podcasts/ -iname "* \.ogg" | perl -nle 'if( $_ =~ /\/([\w-]+.\w\w\w)$/) { print "$1"}' | sort >ogg.txt I did the same thing for * .mp3 files and then diffed the two files. I quickly noticed the extra 5 opus files were from me doing test encodes a couple of weeks ago that I forgot about. Sure it looks hideous, but the explanation is easy: for 'perl -nle', the 'l' means process each line from stdin individually, the 'n' means no auto printing of the line, and the 'e' is basically the perl 'one liner' mode. Either way, each line comes in and is stored in '$_', I use a capturing regex to grab the file name without parent directory names, basically everything after the last '/' in a path that ends with a three letter extension (\w\w\w). The "captured" part of the regex ends up in '$1'. Also see 'perldoc run' for all the runtime one liner options.
  - high_priest 6y ago
    Why am I not surprised that the PERL part could be solved with bash in the same space. Why are you so eager to use lang on top of lang, in such simple cases?
    - esaym 6y ago
      Feel free to demonstrate. Take a long path with nasty characters and give me the ending file name. I want "track1.mp3" returned from: /podcast/with/nasty'--c h a r$/and/stuff/track1.mp3
      - AareyBaba 6y ago
- tingletech 6y ago
  I have 20 year old Perl code I run in production. I had to re-install it our move to Amazon Linux 2. My 10 year old install process for the cpanm setup still worked. My 10 year old Python had to be moved to python 3; but the 20 year old Perl still runs
  - edgyquant 6y ago
    I’m a big time python fan (80% of the code I write is python) but growing up I loved Perl (after starting out as a PHP dev) as a scripting language and I hate how much flak people give it. Though I do understand since there’s a million ways to do everything in Perl if you aren’t familiar with the language it can look daunting. But I’d argue the same can be said about JavaScript and I still love that language as well.
- bmn__ 6y ago
  I notice you did not provide any details, depriving us of the ability to determine whether the shit show is PEBCAK or genuine.
theonemind 6y ago
A lot of people have a knee-jerk negative reaction to the name perl without understanding that perl chewed up and spit out this particular problem space. You probably don't want to develop your next webapp with a team of perl coders, but the language has its niche.
- cmrdporcupine 6y ago
  I mean, I worked in the .com era with perl coders who made some pretty compelling products out of Perl, for the time, with some discipline, and TBH... it wasn't terrible, and when they "Did the right thing" and rewrote the whole thing in the new hotness (J2EE) it _was_ terrible. Perl will let you hang yourself, and I hated it at the time, but it also got the job done.
- stevekemp 6y ago
  I've switched most of my projects to golang these days, but even as recently as a couple of years ago I was writing pretty big sites with Perl. Using https://metacpan.org/pod/CGI::Application https://metacpan.org/pod/CGI::Application to provide the framework, along with similar small frameworks - e.g. a perl version of sinatra. Golang managed to persuade people to write tests, by making it easy and self-contained. I'd suggest with Test::More that Perl did something similar. Almost all the modules you'd find on CPAN are full of test-cases. There might well be thinks we can argue about with Perl, but it is definitely true that it has/had one of the biggest and most consistent set of extensions out there. CPAN has held up pretty well, compared to some of the later alternatives (such as node modules, ruby gems, etc). One reason that I was able to work with Perl so easily was because I could find Stripe integrations, and similar with ease.
zem 6y ago
i find that ruby combines the best features of perl and python in that respect. makes shell-like scripts really convenient and easy while still providing the means to add structure.
- pmoriarty 6y ago
  Both Ruby and Python are too slow for me, and neither is Lispy enough.
  - TylerE 6y ago
    nim! It has full macros, even! and it's super, super, fast
    - pmoriarty 6y ago
      Nim's not Lispy either, and macros alone are not enough. To make macro use feel natural because they're not much different than using the core language, the language needs to be homoiconic, which to my knowledge Nim is not. In any case, macros are not what draw me to Lisp, but its unparalleled combination of ease of use, readability, and power... along with 70 years of development and tooling. So I could just use a Lisp or Scheme, which I do. They can be plenty fast too (see Chicken, for instance, which -- like Nim -- compiles down to C).
      - TylerE 6y ago
        It's lispy in what it can do, not in having a rat's nest of parens, true. I'd love a concrete example of a macro you could express in lisp and not in nim. But it's macros absolutely operate on a syntax tree - refer to https://nim-lang.org/docs/tut3.html#introduction-the-syntax-tree https://nim-lang.org/docs/tut3.html#introduction-the-syntax-...
  - mplewis 6y ago
    Slow in what regard, for what use case?
  - 6y ago
chubot 6y ago
I think Perl needs a real pipeline syntax, among other things: http://www.oilshell.org/blog/2018/01/28.html#are-you-reinventing-perl http://www.oilshell.org/blog/2018/01/28.html#are-you-reinven... That said, Oil is somewhat influenced by Perl: https://www.oilshell.org/release/0.8.3/doc/language-influences.html https://www.oilshell.org/release/0.8.3/doc/language-influenc... Also note this part of the original blog post, Python/JS/Ruby vs Perl/PHP: http://www.oilshell.org/blog/2020/10/osh-features.html#oil-language-updates http://www.oilshell.org/blog/2020/10/osh-features.html#oil-l... I recently bought a copy of the Camel book and noticed the exact same thing that Steve Yegge pointed out here: Perl's references are basically pointers. As in, C-style pointers. You know. Addresses. Machine addresses. What in the flip-flop are machine addresses doing in a "very high-level language (VHLL)", might you ask? Well, gosh, what they're doing is taking up about 30% of the space in all Perl documentation worldwide. https://sites.google.com/site/steveyegge2/ancient-languages-perl https://sites.google.com/site/steveyegge2/ancient-languages-... This is really a huge, unnecessary wart in the language. The other wart I pointed out in the post is that Perl 5 does dynamic parsing of its own code (parsing that depends on the value of variables), despite the book complaining about the same issue in shell. In contrast, Raku and Oil are statically parsed. ---- I have a lot of respect for Perl, but there's a reason that Raku exists (and again from the FAQ: Raku and Python 3 are both worse shell-like languages than their predecessors.)
- ryl00 6y ago
  > Perl's references are basically pointers. ... This is really a huge, unnecessary wart in the language. Call me crazy :), but I count this as a pro for perl! It makes thinking about data structures in perl very "regular" for me.. there's a few rules to learn, but then I find it simple to construct (or de-construct) nested data structures while applying those rules. As opposed to other scripting languages, where the difference between "value" and "reference" frequently seems to be more hidden from sight...
- lizmat 6y ago
  > In contrast, Raku and Oil are statically parsed. I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword. But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, can be as simple as: sub postfix:<!>(\value) { [*] 1 .. value } say 5! # 120

by R0b0t1 6y ago

FreshFries 6y ago

There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live. I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers. /rant.

johnisgood 6y ago
I hate everything there is to hate about CPAN. I also hate how Perl libraries are handled. I have to have like 5 lines of code related to it in ~/.bashrc or ~/.bash_profile. Bleh. Perl libraries are always a problem when I want my program to run on other machines. No thank you.
- esaym 6y ago
  I find this to be a weird statement. I've never really fought with "cpan" but have had huge fights with node and python packages. The old school "cpan" command has not been recommended to be used for nearly a decade now. Maybe that is your issue? Everyone just uses cpan-minus: http://cpanmin.us/ http://cpanmin.us/ or "cpanm". It will install anything, if you have write access to the installed perl location, it will install globally, otherwise it installs packages into "~/perl5" then just do something like "export PERL5LIB=~/perl5/lib/perl5/" in your bashrc. Or maybe you are talking about having to compile code in certain packages? Alot of stuff using ssl has C code which links against openssl which is always a pain. Not sure what other issues you might be alluding to... There are some "packaging" tools to try to bundle and pin libraries, kind of like venv for python. I've never messed with them though. We just compile the latest perl binary and install all our needed cpan modules globally. Never worry about pinning since nothing is ever updated on cpan anymore...
  - johnisgood 6y ago
    > The old school "cpan" command has not been recommended to be used for nearly a decade now. Maybe that is your issue? I did not know that it was not supposed to be used, so that might explain my issues, but at the same time it did work for me on my machine, but had a hard time running my Perl script on a VPS, because I had to set everything up again and for some reason I ran into some errors. I often ran into packages that failed to compile, too, yeah. > Never worry about pinning since nothing is ever updated on cpan anymore... Nothing makes it kind of sad. :/
threeqhan 6y ago
Sheer as in "unmitigated" and shear as in sheep But I agree with this, except for python
esaym 6y ago
I think the OP is mostly talking about "perl one liners" on the shell like this: https://catonmat.net/ftp/perl1line.txt https://catonmat.net/ftp/perl1line.txt It is not that hard either (unless perl is completely foreign to you). Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files only to have 5 extra opus files... I beat my head really good trying to glue a bunch of bash stuff together but I could not find where the 5 extra opus files were coming from. I defected back to perl. All I needed was an alphabetical list of all the files (there were many sub-directories), perfect for a little perl oneliner: find /podcasts/ -iname "* \.ogg" | perl -nle 'if( $_ =~ /\/([\w-]+.\w\w\w)$/) { print "$1"}' | sort >ogg.txt I did the same thing for * .mp3 files and then diffed the two files. I quickly noticed the extra 5 opus files were from me doing test encodes a couple of weeks ago that I forgot about. Sure it looks hideous, but the explanation is easy: for 'perl -nle', the 'l' means process each line from stdin individually, the 'n' means no auto printing of the line, and the 'e' is basically the perl 'one liner' mode. Either way, each line comes in and is stored in '$_', I use a capturing regex to grab the file name without parent directory names, basically everything after the last '/' in a path that ends with a three letter extension (\w\w\w). The "captured" part of the regex ends up in '$1'. Also see 'perldoc run' for all the runtime one liner options.
- high_priest 6y ago
  Why am I not surprised that the PERL part could be solved with bash in the same space. Why are you so eager to use lang on top of lang, in such simple cases?
  - esaym 6y ago
    Feel free to demonstrate. Take a long path with nasty characters and give me the ending file name. I want "track1.mp3" returned from: /podcast/with/nasty'--c h a r$/and/stuff/track1.mp3
    - AareyBaba 6y ago
tingletech 6y ago
I have 20 year old Perl code I run in production. I had to re-install it our move to Amazon Linux 2. My 10 year old install process for the cpanm setup still worked. My 10 year old Python had to be moved to python 3; but the 20 year old Perl still runs
- edgyquant 6y ago
  I’m a big time python fan (80% of the code I write is python) but growing up I loved Perl (after starting out as a PHP dev) as a scripting language and I hate how much flak people give it. Though I do understand since there’s a million ways to do everything in Perl if you aren’t familiar with the language it can look daunting. But I’d argue the same can be said about JavaScript and I still love that language as well.
bmn__ 6y ago
I notice you did not provide any details, depriving us of the ability to determine whether the shit show is PEBCAK or genuine.

theonemind 6y ago

A lot of people have a knee-jerk negative reaction to the name perl without understanding that perl chewed up and spit out this particular problem space. You probably don't want to develop your next webapp with a team of perl coders, but the language has its niche.

cmrdporcupine 6y ago
I mean, I worked in the .com era with perl coders who made some pretty compelling products out of Perl, for the time, with some discipline, and TBH... it wasn't terrible, and when they "Did the right thing" and rewrote the whole thing in the new hotness (J2EE) it _was_ terrible. Perl will let you hang yourself, and I hated it at the time, but it also got the job done.
stevekemp 6y ago
I've switched most of my projects to golang these days, but even as recently as a couple of years ago I was writing pretty big sites with Perl. Using https://metacpan.org/pod/CGI::Application https://metacpan.org/pod/CGI::Application to provide the framework, along with similar small frameworks - e.g. a perl version of sinatra. Golang managed to persuade people to write tests, by making it easy and self-contained. I'd suggest with Test::More that Perl did something similar. Almost all the modules you'd find on CPAN are full of test-cases. There might well be thinks we can argue about with Perl, but it is definitely true that it has/had one of the biggest and most consistent set of extensions out there. CPAN has held up pretty well, compared to some of the later alternatives (such as node modules, ruby gems, etc). One reason that I was able to work with Perl so easily was because I could find Stripe integrations, and similar with ease.

zem 6y ago

i find that ruby combines the best features of perl and python in that respect. makes shell-like scripts really convenient and easy while still providing the means to add structure.

pmoriarty 6y ago
Both Ruby and Python are too slow for me, and neither is Lispy enough.
- TylerE 6y ago
  nim! It has full macros, even! and it's super, super, fast
  - pmoriarty 6y ago
    Nim's not Lispy either, and macros alone are not enough. To make macro use feel natural because they're not much different than using the core language, the language needs to be homoiconic, which to my knowledge Nim is not. In any case, macros are not what draw me to Lisp, but its unparalleled combination of ease of use, readability, and power... along with 70 years of development and tooling. So I could just use a Lisp or Scheme, which I do. They can be plenty fast too (see Chicken, for instance, which -- like Nim -- compiles down to C).
    - TylerE 6y ago
      It's lispy in what it can do, not in having a rat's nest of parens, true. I'd love a concrete example of a macro you could express in lisp and not in nim. But it's macros absolutely operate on a syntax tree - refer to https://nim-lang.org/docs/tut3.html#introduction-the-syntax-tree https://nim-lang.org/docs/tut3.html#introduction-the-syntax-...
- mplewis 6y ago
  Slow in what regard, for what use case?
- 6y ago

chubot 6y ago

I think Perl needs a real pipeline syntax, among other things: http://www.oilshell.org/blog/2018/01/28.html#are-you-reinventing-perl http://www.oilshell.org/blog/2018/01/28.html#are-you-reinven... That said, Oil is somewhat influenced by Perl: https://www.oilshell.org/release/0.8.3/doc/language-influences.html https://www.oilshell.org/release/0.8.3/doc/language-influenc... Also note this part of the original blog post, Python/JS/Ruby vs Perl/PHP: http://www.oilshell.org/blog/2020/10/osh-features.html#oil-language-updates http://www.oilshell.org/blog/2020/10/osh-features.html#oil-l... I recently bought a copy of the Camel book and noticed the exact same thing that Steve Yegge pointed out here: Perl's references are basically pointers. As in, C-style pointers. You know. Addresses. Machine addresses. What in the flip-flop are machine addresses doing in a "very high-level language (VHLL)", might you ask? Well, gosh, what they're doing is taking up about 30% of the space in all Perl documentation worldwide. https://sites.google.com/site/steveyegge2/ancient-languages-perl https://sites.google.com/site/steveyegge2/ancient-languages-... This is really a huge, unnecessary wart in the language. The other wart I pointed out in the post is that Perl 5 does dynamic parsing of its own code (parsing that depends on the value of variables), despite the book complaining about the same issue in shell. In contrast, Raku and Oil are statically parsed. ---- I have a lot of respect for Perl, but there's a reason that Raku exists (and again from the FAQ: Raku and Python 3 are both worse shell-like languages than their predecessors.)

ryl00 6y ago
> Perl's references are basically pointers. ... This is really a huge, unnecessary wart in the language. Call me crazy :), but I count this as a pro for perl! It makes thinking about data structures in perl very "regular" for me.. there's a few rules to learn, but then I find it simple to construct (or de-construct) nested data structures while applying those rules. As opposed to other scripting languages, where the difference between "value" and "reference" frequently seems to be more hidden from sight...
lizmat 6y ago
> In contrast, Raku and Oil are statically parsed. I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword. But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, can be as simple as: sub postfix:<!>(\value) { [*] 1 .. value } say 5! # 120