>>>> I've programmed in Perl but I'm no Perl-programmer notwithstanding.
>>>> Some more or less obvious reasons I see...
>>>> Abstraction of diverse Unix utilities' interfaces.
>>>
>>> no other language comes close in conciseness when it comes to
>>> text processing and interacting with the OS (filesystem, pipes,..)
>>
>> .. i could imagine e.g. a library for a language getting there.
>
> Especially a language that is particularly versatile and adaptable to
> defining DSLs.

Ruby is a good example of that. It mixes Lisp (useful for making DSLs)
and the good parts of Perl (regexps, text processing).
But Ruby only filled (partially) the niche of programming web frameworks.
And I say partially because perl-based cpanel is still being used nowadays.

But for system automation tasks in a Posix OS, when you want to
go above the level of a simple shell script and use complex data
structures, Perl is the only language that fills that gap, any other
language is oververbose (lacks conciseness).

And for whatever reason no other language has filled that gap.
Nobody has even attemped to create another language for the task.
So 37 years after its creation, learning Perl it's still useful.

--
Brevity is the best recommendation of speech, whether in a senator or an orator.
Marcus Tullius Cicero

On Tue, 16 Apr 2024 20:47:47 +0000, Javier wrote:

> But for system automation tasks in a Posix OS, when you want to go above
> the level of a simple shell script and use complex data structures, Perl
> is the only language that fills that gap, any other language is
> oververbose (lacks conciseness).

Still some limitations in its data structures, though. I see Perl 5.38 has
added an “experimental” class feature, but it doesn’t do multiple
inheritance or metaclasses. Also I’m not sure if classes are first-class
objects or not.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 16 Apr 2024 20:47:47 +0000, Javier wrote:
>
>> But for system automation tasks in a Posix OS, when you want to go above
>> the level of a simple shell script and use complex data structures, Perl
>> is the only language that fills that gap, any other language is
>> oververbose (lacks conciseness).
>
> Still some limitations in its data structures, though.

Such as? (I'm not disagreeing -- every languages have "limitations" --
I'm just trying to find out what you mean by a limitation in Perl's data
structures.)

> I see Perl 5.38 has
> added an “experimental” class feature, but it doesn’t do multiple
> inheritance or metaclasses.

Perl has had support for object-oriented programming (with multiple
inheritance) for many years -- too many for me to remember.

> Also I’m not sure if classes are first-class
> objects or not.

--
Ben.

On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:

> Perl has had support for object-oriented programming (with multiple
> inheritance) for many years -- too many for me to remember.

Then why this new “class” thing in 5.38?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>> Perl has had support for object-oriented programming (with multiple
>> inheritance) for many years -- too many for me to remember.
>
> Then why this new “class” thing in 5.38?

It's explained reasonably well at the top of the "perldoc perlclass"
documentation in Perl 5.38:

History
Since Perl 5, support for objects revolved around the concept of
*blessing* references with a package name. Such reference could then be
used to call subroutines from the package it was blessed with (or any of
its parents). This system, while bare-bones, was flexible enough to
allow creation of multiple more advanced, community-driven systems for
object orientation.

Class feature is a core implementation of class syntax which is familiar
to what one would find in other programming languages. It isn't a
"bless" wrapper, but a completely new system built right into the perl
interpreter.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Wed, 17 Apr 2024 16:59:06 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>>>
>>> Perl has had support for object-oriented programming (with multiple
>>> inheritance) for many years -- too many for me to remember.
>>
>> Then why this new “class” thing in 5.38?
>
> It's explained reasonably well at the top of the "perldoc perlclass"
> documentation in Perl 5.38:

It says there is already supposed to be a mechanism for this, it doesn’t
explain why that isn’t good enough.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Apr 2024 16:59:06 -0700, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>>>>
>>>> Perl has had support for object-oriented programming (with multiple
>>>> inheritance) for many years -- too many for me to remember.
>>>
>>> Then why this new “class” thing in 5.38?
>>
>> It's explained reasonably well at the top of the "perldoc perlclass"
>> documentation in Perl 5.38:
>
> It says there is already supposed to be a mechanism for this, it doesn’t
> explain why that isn’t good enough.

There's a mechanism for method dispatch in class hierarcies. There's no
builtin support whatsoever for handling class instance data (or class
data, for that matter). This has certain advantages (everything a
reference refers to can be used as object, eg, file handles) and is
reasonably easy to provide for cases without multiple inheritance and
doable otherwise. OTOH, that absolutely not what people familiar with
other programming languages expect and also beyond what many of them can
wisely handle. Hence, a more dictatorial approach is probably expected
to improve things¹.

¹ Somewhat questionable when looking at another newer feature, namely,
subroutine signatures. It would be absolutely great if perl support real
function prototypes including checking function invocations for
correctness at compile time *and* *not* at runtime everytime a
function is called.