http://qs1969.pair.com?node_id=11131765


in reply to Perl Contempt in My Workplace

«...contempt...»

This was an issue in any company I was with until I retired. What this Wisenheimers forget or don’t know (!) is that most of their systems rely less or more on Perl: Cron jobs, Backup, Databases, Monitoring, Ticketing, Mail, Firewalls etc. See also

«The Crux of the Biscuit is the Apostrophe»

Replies are listed 'Best First'.
Re^2: Perl Contempt in My Workplace
by erix (Prior) on Apr 28, 2021 at 05:04 UTC

    ..., Databases, ...

    PostgreSQL, which is mainly a C project, has in recent years (!) adopted tap + perl for testing, and total perl files (*.p[lm]) have grown to several percent of the total lines of code in the tree.

      And there is PL/Perl

      Update: Linked to current version of PL/Perl

      «The Crux of the Biscuit is the Apostrophe»

        thanks karlgoethebier! I was not aware of this. PL/Perl can return hashrefs and arrayrefs too! This removes a lot of boilerplate from scripts and puts it exactly where it belongs to: in the guts and out of sight.

        Update: the following caveat does not apply to the recent versions of PL/Python. See nodes below.

        On the other hand, it offers something similar for python but with this caveat:

        As of PostgreSQL 7.4, PL/Python is only available as an "untrusted" language, meaning it does not offer any way of restricting what users can do in it. It has therefore been renamed to plpythonu. The trusted variant plpython might become available again in future, if a new secure execution mechanism is developed in Python. The writer of a function in untrusted PL/Python must take care that the function cannot be used to do anything unwanted, since it will be able to do anything that could be done by a user logged in as the database administrator. Only superusers can create functions in untrusted languages such as plpythonu.

        bw, bliako