[Chicago-talk] What's happening with Perl these days

Chris Hamilton cjhamil at gmail.com
Fri Apr 5 13:31:31 PDT 2024


As little more than a consumer of information on this list, I feel like I
wanted to chime in for once in support of this view. I agree strongly with
the notion that my role in a company is to take the business needs that
company has and translate that into technology-driven deliverables that I
believe best serve those business needs. Choosing the "best" tool for a job
isn't always a purely objective decision, and there are often plenty of
tools you can use to accomplish that same purpose. It is not the decision
of people who consume the outputs of my work to determine for me mechanisms
that drive those outputs. Their job is to sufficiently define the needs of
the deliverable (often needing assistance to even do that well, in most
cases), my job is to deliver on that. Part of that deliverable (as it
should also be part of the underlying requirements) is for that solution to
be reasonably maintainable and sufficiently long lasting (and only on this
very small area might the choice of Perl vs. Non-Perl be a consideration,
based solely upon available resources -- though even this common sentiment
is something I don't particularly agree on).

I love Perl. I'm unashamedly an advocate for Perl whenever the topic is
discussed. I've been building large scale web applications in Perl for
nearly 20 years. I've also been hearing how Perl is a "dead language" since
the first time I was exposed to it on the job and was told the application
I'd be working on was written in Perl. Strangely enough, I'm still building
greenfield products in Perl to this day and will likely continue to do so
until something massively changes that makes doing so a less optimal
approach for me.

Anytime this topic comes arises out and about with non-Perl folks (and even
a lot of the time with Perl folks) I will continually hear more about why
using Perl is a terrible choice these days (seemingly regardless of
whenever "these days" are at the time). Meanwhile, every time I begin
building something of even moderate complexity with something that *isn't *Perl
I find myself facing situations that would have been so much more readily
available to accomplish in Perl. For the sake of this discussion, I'm not
even going to bother coming up with various anecdotal examples (because
even if I did, that would carry no tangible weight in this argument, as
they would be purely anecdotal and also possibly even the result of my own
ignorance in a given specific scenario). The reality is this, from my
perspective: Perl makes easy things easy to do, but more importantly it
turns a lot of things that are seemingly *impossible *to do into things
that can at least be accomplished.

I can find plenty of things in Perl to complain about, but I can also find
plenty of things about *any* language to complain about.

Do I wish Perl 6 didn't exist (or at least had picked a different name at
the outset)? Yes. I didn't ring that bell and we (seemingly) can't unring
that bell. This will go down in history as one of the stupidest marketing
blunders of all time, imo.

Do I wish Perl was perfect? Sure, stupid question.

Do I think Perl is better than any reasonably comparable language? Hell yes
I do... and at the very least, it's certainly no worse than any of them.

Python is *fine*. Perl is better.

-Chris

On Fri, Apr 5, 2024 at 11:17 AM J L <joel.limardo at forwardphase.com> wrote:

> "I'm only lightly technical these days, having moved into a sales role a
> decade ago. I haven't really done any programming for years."
>
> Here's my two cents:  If the entities you serve do not want Perl who
> cares? What do YOU want? When I work with a company they give me an
> assignment-- give us X. How I model X, support X until I hand it over to
> their own internal support department, etc. is *my* business. How I handle
> contact management (Perl), documentation (wiki written in Perl), and even
> software testing (system I wrote in Perl) is MY business. They get the
> cake; I keep the pan, spoons, cling wrap, and the ovens. Now I can make
> more cakes elsewhere. I can even give them away.
>
> Perl's strength is that it gives you an actual tool to help you think for
> yourself. You don't need a company to tell you what software problems to
> think about. Just as the writer *must* write the programmer *must* program.
> To the devil with what companies want and what some nondescript IT
> management fool is telling you. What do YOU want to do with the wonderful
> grey matter residing atop thine head? Solve problems, explore.
>
> On Thu, Apr 4, 2024, 9:56 PM Jay S <me at heyjay.com> wrote:
>
>> Hi Perl Mongers,
>> I hope all is well.
>>
>> I'm only lightly technical these days, having moved into a sales role a
>> decade ago. I haven't really done any programming for years.
>>
>> It seems like Perl6 was too big an effort, leaderless, and sort of
>> fizzled out while Python ascended. Technical folks I sell to all have
>> Python people (and scala ruby Java(script)) - I never hear anyone mention
>> Perl.
>>
>> Is my perspective right, wrong?
>>
>> Jay
>>
>> _______________________________________________
>> Chicago-talk mailing list
>> Chicago-talk at pm.org
>> https://mail.pm.org/mailman/listinfo/chicago-talk
>>
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> https://mail.pm.org/mailman/listinfo/chicago-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/chicago-talk/attachments/20240405/a35ee076/attachment-0001.html>


More information about the Chicago-talk mailing list