6 ms·

Why Perl over Python though? Most Unix distros come with Python bundled and Python has a bigger ecosystem of libraries etc available. And it's generally easier

Why Perl over Python though? Most Unix distros come with Python bundled and Python has a bigger ecosystem of libraries etc available. And it's generally easier to read/write.

thesuperbigfrog 6y ago
>> Python has a bigger ecosystem of libraries etc available. CPAN (http://www.cpan.org/index.html http://www.cpan.org/index.html) is quite large and has libraries to do almost everything you can imagine. I am not sure if CPAN or pip has more libraries though. >> And it's generally easier to read/write. Python looks nicer, but not everyone likes significant whitespace. The Python 2 to 3 change has also caused some adoption issues. The Perl 4 to 5 happened quite a while ago. Perl 5 has been integral to Unix-like systems since the web went mainstream.
- aryonoco 6y ago
  Yeah and the Perl 5 to Perl 6 move... oh wait...
  - tankenmate 6y ago
    And Larry & Co realised that it was sufficient different that now it is no longer called Perl 6.
    - pram 6y ago
      and yet kept the logo that literally has P6 embedded in it
  - thesuperbigfrog 6y ago
    Exactly. Widely-used programming languages continue to be used even when the authors move to a new version. Perl 5 lives on and is still developed and maintained: https://www.perl.org/get.html https://www.perl.org/get.html Perl 6 became Raku: https://www.raku.org/ https://www.raku.org/ Python 2 is still in use, but officially deprecated: https://www.python.org/doc/sunset-python-2/ https://www.python.org/doc/sunset-python-2/ You could probably start a business maintaining a Python 2 distribution and selling support to businesses and organizations that rely on Python 2 and are not in a position to upgrade: https://www.activestate.com/blog/python-2-eol-report-card-is-the-industry-ready/ https://www.activestate.com/blog/python-2-eol-report-card-is...
    - jhoechtl 6y ago
      Uh, raku looks interesting, the web site is also quite accessible. Sad that it took so long, maybe Perl6 would have regained some territory otherwise.
      - lizmat 6y ago
        Writing this while looking at CrewDragon docking at the ISS. Which took SpaceX 18 years, and many people thinking they would never make it. If anything, an inspiration to the people currently working on and using Raku!
  - mirchibajji 6y ago
    Perl5 is not EOLed, so no one is forced to "move". I haven't heard of any real business actually moving from Perl5 -> Perl6 (Raku, to be precise) for support/legacy reasons.
- toast0 6y ago
  Perl 4 to 5 was before my time, but I read it wasn't really a major change, just to sell books. Perl 5.6 to 5.8 was the big moment where strings became (optionally) arrays of characters instead of arrays of bytes. This caused some amount of breakage, but was a long time ago now; anything else broken since then has been pretty minor.
mfontani 6y ago
/usr/bin/perl scripts written more than twenty years ago continue to work. So do /bin/sh and /bin/bash scripts. /usr/bin/python scripts IME depend on what /usr/bin/python points to; some break/broke due to the python 2 to python 3 switching, which hasn't been as backwards-compatible as previous examples have.
- dorfsmay 6y ago
  But! If you write modern bash, it won't run everywhere, definitely won't run on mac!
- xyproto 6y ago
  Bash may be installed in /usr/bin (Arch Linux + symlink in /bin), /usr/local/bin (OpenBSD) or not at all, though. "#!/usr/bin/env bash" or "#!/usr/bin/env python" are the recommended ways to run both, AFAIK.
  - mekster 6y ago
    Where is bash not installed?
    - asveikau 6y ago
      Bash is not installed by default on any *BSD I have used (FreeBSD, OpenBSD, NetBSD, etc.). You need to install it from the ports tree or package repo. Most (all?) commercial Unix I have used also don't have bash, but those systems are pretty dead these days. OpenBSD's fork of ksh is actually really good so I typically feel no reason to ever install bash on there. On others, the default shell kinda sucks and I tend to install bash. In particular the old /bin/sh on older Unix tends to be worse at interactive use and not support some constructs like {a,b}
      - freemint 6y ago
        Except Ubuntu where they ship dash by default which is not really bash compatible.
qalmakka 6y ago
Because Python is sometimes too "formal" for dirty glue scripts that consist in invoking other commands and parsing their output. Perl blows pretty much every other language out of the water when you need to process text fast and without too much cruft.
- tzs 6y ago
  Perl's being more relaxed about creation and manipulation of data structures helps a lot, too those kinds of scripts. Consider this: my %h = (); # an empty hash $h{'foo'}[3]{'bar'} = 'bletch'; Now my hash contains one entry with key 'foo'. That entry is a reference to an array of 4 elements. The first 3 elements of that array are undef, and the 4th is a reference to another hash. That hash contains one entry with key 'bar' and value 'bletch'. In a lot of other languages you would need to explicitly allocate an array of at least 4 elements for $h{'foo'}, and then explicitly allocate a hash for $h{'foo'}[3]. With Perl they just come into existence when you try to store something in them. Is this always good? No. There are many problems where this automatic reification would just hide bugs. If you are, for example, processing data that is supposed to be clean and well specified then parsing it into explicitly allocated data structures that match what you expect and will throw errors if you try to put something in out of range is great. But when you are dealing with data that is not clean and not well specified, being able to get it all in your data structures easily even when there is something wrong or inconsistent in the data can be great. Get it all in, and then you can run cleanup code on it looking for unexpected things, and fixing them or alerting you that you need to add more cases to the fixing code. There's a similar thing on the reading side of Perl data structures. Try to access a hash via a key that does not exist, or an array by an index past the end? You simply get back undef. Is this always good. Like automatic reification, the answer is no. There are many problems where it would be a grave error if the code tried to access an element of a hash or array that it had not previously but in there. For problems where your logic would include a lot of places where you check if an element exists and if it does you add to a total or if it is a non-empty string you include it in something else, the code can be cleaner in a language with Perl's approach. Adding undef to a number is like adding 0, and undef compares as equal to an empty string.
  - deleted 6y ago
soraminazuki 6y ago
I feel that's an apples vs oranges comparison. I'd prefer to write complex scripts in python, but for simple scripts, I find a mix of bash and perl to be useful. If you want to make a comparison though, I think perl vs sed is a more meaningful one. You can do things that's possible in sed with perl one-liners in a more portable way. It's installed by default on major Linux distributions, and even works on macOS without the GNU vs BSD incompatibilities.
- microtherion 6y ago
  > I'd prefer to write complex scripts in python, but for simple scripts, I find a mix of bash and perl to be useful. Unfortunately, simple scripts that are found to be useful often grow into complex scripts. A few weeks ago, I wanted to write some functionality that seemed "simple" enough to be a good fit for make+bash. A week later, I ended up tossing the whole thing and rewriting it in python.
  - soraminazuki 6y ago
    Not all scripts needs to be complex, though. There would always be demand for quick and easy scripting languages fit for handling simple cases. Yes, some scripts are bound to grow complex, but that doesn't really justify writing every single script in Python. It's just better to make the switch once the benefits exceed the costs.
    - microtherion 6y ago
      In principle, I agree, but in practice, I often find that it's common to make the switch too late, so I'm leaning towards making the switch early.
asveikau 6y ago
I find Perl easier to write, mostly because my personal experience has a lot of C and shell scripting, and perl borrows a lot from both. It is useful and not difficult to be productive in, but does manage to feel more unnatural than both of those though.

Why Perl over Python though? Most Unix distros come with Python bundled and Python has a bigger ecosystem of libraries etc available. And it's generally easier to read/write.

thesuperbigfrog 6y ago

>> Python has a bigger ecosystem of libraries etc available. CPAN (http://www.cpan.org/index.html http://www.cpan.org/index.html) is quite large and has libraries to do almost everything you can imagine. I am not sure if CPAN or pip has more libraries though. >> And it's generally easier to read/write. Python looks nicer, but not everyone likes significant whitespace. The Python 2 to 3 change has also caused some adoption issues. The Perl 4 to 5 happened quite a while ago. Perl 5 has been integral to Unix-like systems since the web went mainstream.

aryonoco 6y ago
Yeah and the Perl 5 to Perl 6 move... oh wait...
- tankenmate 6y ago
  And Larry & Co realised that it was sufficient different that now it is no longer called Perl 6.
  - pram 6y ago
    and yet kept the logo that literally has P6 embedded in it
- thesuperbigfrog 6y ago
  Exactly. Widely-used programming languages continue to be used even when the authors move to a new version. Perl 5 lives on and is still developed and maintained: https://www.perl.org/get.html https://www.perl.org/get.html Perl 6 became Raku: https://www.raku.org/ https://www.raku.org/ Python 2 is still in use, but officially deprecated: https://www.python.org/doc/sunset-python-2/ https://www.python.org/doc/sunset-python-2/ You could probably start a business maintaining a Python 2 distribution and selling support to businesses and organizations that rely on Python 2 and are not in a position to upgrade: https://www.activestate.com/blog/python-2-eol-report-card-is-the-industry-ready/ https://www.activestate.com/blog/python-2-eol-report-card-is...
  - jhoechtl 6y ago
    Uh, raku looks interesting, the web site is also quite accessible. Sad that it took so long, maybe Perl6 would have regained some territory otherwise.
    - lizmat 6y ago
      Writing this while looking at CrewDragon docking at the ISS. Which took SpaceX 18 years, and many people thinking they would never make it. If anything, an inspiration to the people currently working on and using Raku!
- mirchibajji 6y ago
  Perl5 is not EOLed, so no one is forced to "move". I haven't heard of any real business actually moving from Perl5 -> Perl6 (Raku, to be precise) for support/legacy reasons.
toast0 6y ago
Perl 4 to 5 was before my time, but I read it wasn't really a major change, just to sell books. Perl 5.6 to 5.8 was the big moment where strings became (optionally) arrays of characters instead of arrays of bytes. This caused some amount of breakage, but was a long time ago now; anything else broken since then has been pretty minor.

mfontani 6y ago

/usr/bin/perl scripts written more than twenty years ago continue to work. So do /bin/sh and /bin/bash scripts. /usr/bin/python scripts IME depend on what /usr/bin/python points to; some break/broke due to the python 2 to python 3 switching, which hasn't been as backwards-compatible as previous examples have.

dorfsmay 6y ago
But! If you write modern bash, it won't run everywhere, definitely won't run on mac!
xyproto 6y ago
Bash may be installed in /usr/bin (Arch Linux + symlink in /bin), /usr/local/bin (OpenBSD) or not at all, though. "#!/usr/bin/env bash" or "#!/usr/bin/env python" are the recommended ways to run both, AFAIK.
- mekster 6y ago
  Where is bash not installed?
  - asveikau 6y ago
    Bash is not installed by default on any *BSD I have used (FreeBSD, OpenBSD, NetBSD, etc.). You need to install it from the ports tree or package repo. Most (all?) commercial Unix I have used also don't have bash, but those systems are pretty dead these days. OpenBSD's fork of ksh is actually really good so I typically feel no reason to ever install bash on there. On others, the default shell kinda sucks and I tend to install bash. In particular the old /bin/sh on older Unix tends to be worse at interactive use and not support some constructs like {a,b}
    - freemint 6y ago
      Except Ubuntu where they ship dash by default which is not really bash compatible.

qalmakka 6y ago

Because Python is sometimes too "formal" for dirty glue scripts that consist in invoking other commands and parsing their output. Perl blows pretty much every other language out of the water when you need to process text fast and without too much cruft.

tzs 6y ago
Perl's being more relaxed about creation and manipulation of data structures helps a lot, too those kinds of scripts. Consider this: my %h = (); # an empty hash $h{'foo'}[3]{'bar'} = 'bletch'; Now my hash contains one entry with key 'foo'. That entry is a reference to an array of 4 elements. The first 3 elements of that array are undef, and the 4th is a reference to another hash. That hash contains one entry with key 'bar' and value 'bletch'. In a lot of other languages you would need to explicitly allocate an array of at least 4 elements for $h{'foo'}, and then explicitly allocate a hash for $h{'foo'}[3]. With Perl they just come into existence when you try to store something in them. Is this always good? No. There are many problems where this automatic reification would just hide bugs. If you are, for example, processing data that is supposed to be clean and well specified then parsing it into explicitly allocated data structures that match what you expect and will throw errors if you try to put something in out of range is great. But when you are dealing with data that is not clean and not well specified, being able to get it all in your data structures easily even when there is something wrong or inconsistent in the data can be great. Get it all in, and then you can run cleanup code on it looking for unexpected things, and fixing them or alerting you that you need to add more cases to the fixing code. There's a similar thing on the reading side of Perl data structures. Try to access a hash via a key that does not exist, or an array by an index past the end? You simply get back undef. Is this always good. Like automatic reification, the answer is no. There are many problems where it would be a grave error if the code tried to access an element of a hash or array that it had not previously but in there. For problems where your logic would include a lot of places where you check if an element exists and if it does you add to a total or if it is a non-empty string you include it in something else, the code can be cleaner in a language with Perl's approach. Adding undef to a number is like adding 0, and undef compares as equal to an empty string.
- deleted 6y ago

soraminazuki 6y ago

I feel that's an apples vs oranges comparison. I'd prefer to write complex scripts in python, but for simple scripts, I find a mix of bash and perl to be useful. If you want to make a comparison though, I think perl vs sed is a more meaningful one. You can do things that's possible in sed with perl one-liners in a more portable way. It's installed by default on major Linux distributions, and even works on macOS without the GNU vs BSD incompatibilities.

microtherion 6y ago
> I'd prefer to write complex scripts in python, but for simple scripts, I find a mix of bash and perl to be useful. Unfortunately, simple scripts that are found to be useful often grow into complex scripts. A few weeks ago, I wanted to write some functionality that seemed "simple" enough to be a good fit for make+bash. A week later, I ended up tossing the whole thing and rewriting it in python.
- soraminazuki 6y ago
  Not all scripts needs to be complex, though. There would always be demand for quick and easy scripting languages fit for handling simple cases. Yes, some scripts are bound to grow complex, but that doesn't really justify writing every single script in Python. It's just better to make the switch once the benefits exceed the costs.
  - microtherion 6y ago
    In principle, I agree, but in practice, I often find that it's common to make the switch too late, so I'm leaning towards making the switch early.

asveikau 6y ago

I find Perl easier to write, mostly because my personal experience has a lot of C and shell scripting, and perl borrows a lot from both. It is useful and not difficult to be productive in, but does manage to feel more unnatural than both of those though.