If you've discovered something amazing about Perl that you just need to share with everyone, this is the right place.

This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)

Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").

User Meditations
Saving HTTP::Cookies into Netscape format using bless/re-bless
2 direct replies — Read more / Contribute
by bliako
on May 11, 2021 at 07:54

    I needed to save the cookies in HTTP::Cookies into Netscape format (aka 'cookies.txt'). Unfortunately I discovered that this functionality is offered by HTTP::Cookies::Netscape alone, which is a subclass of HTTP::Cookies overriding parent-class's load() and save() methods.

    However, if one has no control over the creation of the cookie jar (that is, someone has created it and passed it on to us) then it's a bit of a puzzle on how to do that, easily. Actually I did not find a way apart from doing it manually myself by copy-pasting the contents of HTTP::Cookies::Netscape::save() into my own "static" sub which takes in a HTTP::Cookies and saves it in "Netscape" format. But that's a round-about way which also suffers from missing on any patches on the original code.

    What I eventually did was to bless the original HTTP::Cookies object into a HTTP::Cookies::Netscape. Call the save() method, which is now different. And when that's done, bless-back to HTTP::Cookies. I just hope this method is as clean as it looks like without side-effects, provided that nobody touches the object in-between its many blessings.

    Here is code demostrating the bless/re-bless:

    use HTTP::Cookies; use HTTP::Cookies::Netscape; use LWP::UserAgent; my $cookie_jar = HTTP::Cookies->new(); my $browser = LWP::UserAgent->new( ); $browser->cookie_jar( $cookie_jar ); # hit some pages # now re-bless the cookie jar to obtain ::Netscape functionality bless $cookie_jar => 'HTTP::Cookies::Netscape'; $cookie_jar->save("mycookies.txt"); # and now re-bless back to original bless $cookie_jar => 'HTTP::Cookies';

    bw, bliako

A "Moral License"/"Fairness Pledge" for Perl - what does one look like?
3 direct replies — Read more / Contribute
by perlfan
on May 09, 2021 at 22:34
    Poul-Henning Kamp is probably more well know to you people for his "bikeshed" analogy, a term many love to invoke often (for good reason). But I ran into this recently, and it was interesting. Here's a blag entry from 2019, referring to the VML he proposed in 2010: A patently good idea.

    It may be interesting to you for reasons other than the one that it's interesting to me; but here's what struck me:

    Nothing can rip apart an Open Source project faster than competing commercial interests playing dirty, and since Varnish has started to cause serious amounts of money to shift around, it is time to take this issue a bit more seriously.

    Further on is this, which I really liked:

    Fairness pledge: - ---------------- As the de-facto leader of the Varnish community, I believe that the success or failure of open source rises and falls with the community which backs it up. In general, there is a tacit assumption, that you take something from the pot and you try put something back in the pot, each to his own means and abilities. And the pot has plenty that needs filling: From answers to newbies questions, bug-reports, patches, documentation, advocacy, VML funding, hosting VUG meetings, writing articles for magazines, HOW-TO's for blogs and so on, so this is no onerous demand for anybody. But the BSD license allows you to not participate in or contribute to the community, and there are special times and circumstances where that is the right thing, or even the only thing you can do, and I recognize that. Therefore: I will treat everybody, who do not contribute negatively to the Varnish community, equally and fairly, and try to foster cooperation and justly resolve conflicts to the best of my abilities.

    I have no idea if perl can benefit from such a license or pledge (certainly doesn't apply to the scourge of "cancel culture"). And it doesn't find immediate application to the bazaar (and non-BSD) style development, but it's a good read, nonetheless.

    Ultimately, what this means to me - and I think to anyone reading this - is that Perl is in desperate need of strong, fair, and righteous leadership. Until this exists, it will continue to be an absolute shitshow and continue to degenerate from within. Those who have been stepping up, thank you. Be fair, just, good, and kind. But most of all, be courageous. You will get the support you need if you decide to exhibit the courageous leadership Perl/perl needs.

    The following was also interesting to me:

    Today (20190517) Arturs Fastly, company went public on the New York Stock Exchange, and went up from $16 to $24 in a matter of hours. So-called “financial analysts” write that as a consequence Fastly is now worth 2+ Billion Dollars. I can say with 100% certainty and honesty that there is no way I could ever have done that, that is entirely Arturs doing and I know and admire how hard he worked to make it happen. Congratulations to Artur and the Fastly Crew! But I will steal some of Arturs thunder, and point to Fastlys IPO as proof that at least once in my career, I had a unique idea worth a billion dollars :-)
I Found Out When I Started Learning Perl
1 direct reply — Read more / Contribute
by rje
on May 08, 2021 at 20:55

    I found my old status reports from work, many moons ago, and I found some gems there, but by far this is the most significant one.

    From the 1994 Week 24 status report:

    Last week's achievements ======================== - MCPS - attended Tiger meeting. - attended M.Carlock's Ofc Parm meeting. - did LTCINV Table Tiger Team Timings. - began learning PERL. ^^^^^^^^^^^^^^^^^^^ This week's goals ================= - MCPS - think about the MFA pre-development meeting issues & questions... - rewrite my old tools in PERL (for practice). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - harass M.Gyger re Vacation Request.
History of PerlMonks' Perl News
No replies — Read more | Post response
by jdporter
on May 04, 2021 at 16:37

    History of PerlMonks' Perl News

    Originally, the Perl News section of the site was not a place where ordinary monks could post. Rather, it was designed to be a local "feed" of Perl-related news extracted from another site. That other site was called Perl News, at news.perl.org.

    Posts to the section were created in the name of a 'bot' account, perlnewsbot. (Presumably, perlnewsbot was the actual name of the automated background process. In all likelihood, it was vroom who created and ran the perlnewsbot.

    vroom announced New Perl News Section on 2000-07-21, and perlnewsbot made its first post that same day.

    news.perl.org was, of course, already in operation by then. the earliest snapshot in the Wayback Machine is dated 2000-01-05.

    *Confusingly, the perlnewsbot user account has a creation date of 2000-07-26 — several days after its first few posts. One possible explanation is as follows: Initially, posts were being inserted in the Perl News section by a different bot user or by some process outside of the perlmonks user-level framework. After the perlnewsbot user was created, the ownership of the prior existing posts was transferred to him. However, this is conjectural.

    perlnewsbot's run only lasted a few months, however.

    Its last post was on 2001-02-16, apparently having been halted even before news.perl.org went dark.

    The last post on news.perl.org was on 2001-03-18, with the following item:

    See use Perl;

    Perl News is going away soon (one might argue it already has :). use Perl is this site's sister site, having all the same news, plus reviews, articles, discussions, and more. The coincidence of the technical difficulties of this site and the imminent migration of use Perl to its new home makes now a good time to finalize the closing of Perl News.
    Indeed, barely a month later news.perl.org was gone.

    Even though use.perl.org - the site called use Perl; - was the ostensible replacement for news.perl.org, at least as a source of news, the perlnewsbot was never updated to pull news from use.perl.org.

    (Interestingly, use.perl.org met a similar fate a few years later. The last post there, announcing its imminent shutdown, was on 2010-09-08.)

    vroom opened up the Perl News section for posting by ordinary users in late May of 2002. Prior to that time, only perlnewsbot was able to post there. (vroom posted there himself once or twice before that, using his godly powers. The couple other posts you now see in that section prior to that date were originally posted in other sections and later moved to Perl News.)

    A noteworthy figure in all of this is Chris "pudge" Nandor. He was the man behind news.perl.org and use.perl.org. He was one of the lead developers of Slash, the perl-based engine which powered both Slashdot and use.perl.org. Of course, Slash was also the predecessor of the Everything Engine, upon which PerlMonks is built. Both are products of the tiny outfit called Blockstackers Intergalactic (BSI). Sound familiar? That is where vroom, nate, and other early creators of PerlMonks were working at the time. However, pudge says that he didn't really know those guys, even though he was in the same place at about the same time. Different projects. Here's what he told me in a private correspondence:

    I wasn’t involved in perlmonks much, but I did news.perl and use.perl. IIRC perlmonks was based on Everything, which was a separate project from Blockstackers, which also created Slash, from which Slashdot and use Perl resulted.

    Relevant chronology:

    • 2000-07-21 - New Perl News Section - vroom creates the perlnews nodetype and dbtable. He posts an announcement, saying that perlnewsbot "just sucks news from the RDF from news.perl.org".
    • 2000-07-26 - Perl News Going Away? - perlnewsbot posts here the article from news.perl.org about that site's impending demise.
    • 2001-01-09 - Perl News Credits - KM alludes to a discussion he had with pudge about it.
    • 2001-02-16 - YAPC::Europe Set for Amsterdam in August - perlnewsbot's final post.
    • 2001-04-13 - The PerlNewsBot - A user notices that perlnewsbot is no longer posting to Perl News. A commenter suggests that the bot could be redirected to use.perl.org.
    • 2001-06-04 - Is brother perlnewsbot ill? - Another exchange almost identical to the preceding.
    • 2001-06-23 - News section not being kept current? - A user notes that the section is inactive and suggests opening it up to general users, with possibly a level requirement.
    • 2001-07-28 - Why no new news? - A user notes that the section is inactive. In a comment, the OP says" "if there's no automatic news gathering (ok fine), then why doesn't vroom (or whoever) open up the news area to manual posted news?"
    • 2001-08-06 - Member Submitted News - A user suggests opening up the Perl News section to posting by general users.
    • 2001-10-21 - randomnode - (patch) - vroom creates the first patch to mention perlnews (node type) by name in its code.
    • 2001-11-03 - New use for old news - A user suggests opening up the Perl News section to posting by general users.
    • 2002-02-11 - What's happening with Perl News? - "Since it appears to be dead, Perl News should either be killed or opened up to general postings." A commenter again suggests that the bot could pull news from use.perl.org.
    • 2002-02-22 - Make (Perl News == Use.Perl.Org) Or Is This Heresy? - A user suggests that the Perl News section link directly to use.perl.org, vs reposting content here.
    • 2002-04-26 - "Perl News" is old - A user notes that "the most recent news in the Perl News node date back to one year ago."
    • 2002-05-07 - Posting Unrelated News Items - A user suggests reactivating Perl News as a "normal" section (rather than mirroring off-site news stories) where monks can post links to relevant stories." This sparked a surprising amount of debate.
    • 2002-05-24 - tye notes in the editors' wiki:
      I fixed several problems with the (apparently rather hastilly) reopened Perl News section. There is one potentially ugly problem remaining...

      Since the work to set up the (unduely complicated) "approval link type" and related baggage has not been done, you can't "approve" Perl News nodes. This means that the approval nodelet won't show. Which means that some ppl can move a node to Perl News after which only editors will be able to move it anywhere else. The best solution is probably to create all of the baggage and make Perl News items require approval.

      You have been warned. Also, if this becomes a point of abuse before an enterprising god gets around to adding "approval" for Perl News, then the ability to move to/from Perl News can very quickly be taken away by deleting one line from writeupmover.
      At the same time, in the pm-port wiki:
      I fixed several things wrong with Perl News, which included changes to: perlnews (the node type), Perl News, perlnews display page, preview settings, vote settings, writeupmover, and perhaps a few others.

      The first problem was that adding new Perl News actually added new poetry. Of course, I noticed this because someone added news so I wanted to move it into the proper section. However, the node type of perlnews uses the dbtable of perlnews in order to add a linklocation field which makes it impossible to simply "move" to/from that node type. But search internal code shows that this extra field is not used currently so I changed the node type to not use that dbtable and then made "Perl News" one of the available move-to types. And I made it so you can vote on "Perl News" nodes.

      Since the work to set up the (unduely complicated) "approval link type" and related baggage has not been done, you can't "approve" Perl News nodes. This means that the approval nodelet won't show. Which means that some ppl can move a node to Perl News after which only editors will be able to move it anywhere else. The best solution is probably to create all of the baggage and make Perl News items require approval.
      Oddly, I don't see any patches from tye (nor tye&) in that timeframe, nor any patches to any of the nodes he mentioned. I believe he must have mucked with all those codes directly, using godly powers. (He became a god on 2002-02-01.)
    • 2002-05-24 - Dr. Damian Conway to speak at Dallas/Ft. Worth Perl Mongers meeting in June - This post by atcroft in the Perl News section was probably originally in Meditations and then moved. I think so because there are records in the db showing that it was at one point "approved", yet perlnews never needed approval (at that time).
    • 2002-05-26 - Perl News reopened - vroom's announcement: "I've reopened Perl News. You can now post Perl News stories there. Currently approval isn't necessary." Unfortunately, modifications to a nodetype definition (e.g. its authorized creators & writers) are not tracked and do not use the patch system. maintenances are; but unfortunately perlnews did not get its sole maintenance - perlnews maintenance create - until three months later (2002-08-23).
    • 2002-05-26 - Boston Perl Classes - uri posts what is likely the first human-user submission directly to the newly opened Perl News section. Its records in the db show no evidence of having been approved.
    • 2002-05-26 - Voting in Perl News - A user thanks vroom for reviving the Perl News section, and offers this insight:
      "One of the reasons it was originally taken out of commission was that many people thought http://use.perl.org did a better job of providing Perl-related news. While use.perl.org is an excellent site, it focuses on larger stories and probably wouldn't publish most module releases and other small events. I think Perl News would be an excellent place to announce these smaller events."
    • 2002-05-31 - Perl Monks User Search - (patch) - VSarkiss submits a patch to Perl Monks User Search "so nodes in the newly re-opened Perl News will show up"; he notes it in the pmdev wiki. Interestingly, this patch was never applied; and also interestingly predates any other patches to Perl Monks User Search! Even so, the code was updated to include perlnews at some point before the first applied patch.
    • 2002-08-23 - perlnews maintenance create - (patch) - the first patch to mention "news" in its reason.
    • 2010-10-13 - What exactly counts as "Perl News"? - Interesting commentary, especially by tye.
Perl Contempt in My Workplace
15 direct replies — Read more / Contribute
by rje
on Apr 26, 2021 at 19:32

    The attitude around work is strongly "don't use Perl", in an informal way. It's not an official position, and there's been no talk that I know of about not allowing Perl in the workplace. There are a couple of key scripts that can't be replaced until we move completely into a container-based deployment model. So Perl is officially supported, for now.

    That doesn't stop people from putting up style guides for various tools and toolsets in the company, and having a page for Perl that simply says:

    Don't use it. If you have to use it, use strict and use warnings. But seriously, don't use it. Use Python.

    It's hard for me to rise above this attitude problem. They've gotten it stuck in their heads that Perl is just a spaghetti has-been language and that Python is "all that".

    I do what I can... but we all know that story. I write good Perl, I instruct and inform people of good Perl that I've written that does useful things.

    But I have a problem: I identify with Perl. I care about it, because it not only was part of my career identity for 20 years; I LIKE Perl and think it does many things better than other languages.

    I'm biased. And it offends me that others are so openly contemptuous.

    I need thicker skin. What's the best way to get thicker skin about Perl's unpopularity?

    I was having an okay day until I saw this blatant display of contempt and smugness.

The rookie drama
4 direct replies — Read more / Contribute
by hrcerq
on Apr 24, 2021 at 21:18

    The rookie drama

    At some point in time, everyone's been a beginner. There's no shame in being one. By contrast, I'd say there's shame in pretending not to be one. These days I was thinking about a matter related not just to learning Perl, but actually related to learning many things.

    And just to be clear, I still consider myself a Perl beginner, as even though I started my learning path about 2 years ago, I've only used perl for trivial tasks and for many months didn't touch a single line of Perl code, until last month.

    Actually, I'd say I'm proud of being one. The beginning is one of the most enjoyable stages of the learning path (as it should be), if you really take your time to appreciate it. It lessens the burden of having to know some complex details, though it's not to say you don't have the obligation to read docs and do some researching before you ask for help.

    I believe the newness of a subject to be motivating (note that I'm referring to newness as "something new to someone", not as "new on itself"). Exploring on something new, that might be helpful (and in the case of Perl, it certainly will) should be enough to get you into learning something.

    Why do people hurry?

    I must confess that many times I found myself in a hurry to leave this awesome (beginning) stage behind, as I've seen many people doing the same thing. I now believe that to be a mistake. If you don't take your time to enjoy each step in a learning path, then it's like getting to the top of a cards pyramid. Just a wind blow and everything falls apart.

    But then I thought to myself: "Why do people do that? Why do people hurry?" Well, I believe I can figure out some of these motivations, as they have crossed my mind many times. I'll be a bit Perl-specific here, but much of these considerations apply to other subjects too.

    Fear of being discredited

    When you're learning a complex subject such as a programming language, you might feel like much of what you're doing is wrong, simply because you've never had the time to learn how to do proper. That could lead you into thinking: "if someone experienced sees this, I'll become a joke".

    You may also feel discouraged to contribute and say things about Perl because then something might be wrong or imprecise and someone could say something like "just stay quiet, you're nothing but a stupid newbie". Though not with these words (and not Perl-related), I've seen people act like that.

    Being subject to this is not cool, and that certainly makes you wanna hurry to learn. And that's a bad motivation, because then your primary goal is not to learn, but not being bullied. When learning is secondary, you skip important stuff.

    Just a hunch: bullies are probably newbies too. They're just so afraid to admit it, that they act like this. But even when they know what they're talking about, if they're using knowledge to embarass you, then it's shame on them, not you. They're driven by vanity alone and not the desire to help.

    You, on the other hand, can always avoid vanity and not let that be an obstacle. If you know upfront that people might mock you (even when you're right) and yet you put your learning or contributing before that, then you'll be fine.

    Let's just not confuse bullying with pointing the right direction, as some bad practices should be carefully and helpfully described, so they're not repeated.

    Job related considerations

    Perl-related jobs still exist, of course, but they've had more popularity in the past. For those who enjoy Perl programming, it may seem like a good idea to convince your boss that you know a lot about it, so that it's incorporated in your workflow.

    And that is probably going to fail (miserably). If you want Perl to get some credit where you work, I believe your best chances are showing that it can help getting things done, and yet you don't depend on it.

    And please, don't take that last part as an afterthought. The idea of depending on something like Perl is probably terrifying to your boss. Like nightmares-grade terrifying. Saying you're an expert doesn't help, as it may seem like you need to be an expert to get things done.

    Now, if your company already uses perl, you might feel tempted to pretend you know more than you do. That's also a mistake, as you might be convincing, in which case you'll be put to face tasks you're not prepared for, or you might not, in which case you could face some (deserved) discredit, or even be fired, so don't do that.

    So many nice docs and tutorials

    One of the great virtues of Perl is the amount of high-quality documentation available, as well as books, tutorials and specialized blogs. There's so much to read, you may feel like you'll never finish your reading.

    And in fact you probably won't. But that souldn't make you hurry. Reading just for the sake of reading is a complete waste of time. You won't learn anything by doing that, so either take your time to read properly, or don't read at all. In other words, hurrying just doesn't work.

    Of course, you'll need to be selective. As time is a scarce resource, you need to prioritize what's best and most needed. This is where a community shines. A community (such as PerlMonks) may help curate material that's more appropriate for a beginner. As your learning goes, you'll be more proficient in choosing what's worth your time.

    It may seem like shorter tutorials or explanations should be taken first. That's not necessarily so. Often times, taking your time to read a more comprehensive document or book might pay off and help you absorb with more ease the further documentation you come across.

    Shorter articles/books might be good if they are concise, but not if they are simplistic, in which case you should just ignore them. Again, with the help of a community it might be easier to choose what's worth your time.

    In that regard, I can say the tutorials here in PerlMonks greatly helped me. For instance, I've been doing some review on context and scoping rules, and found great articles on that. These are foundational concepts in Perl and having a good explanation on them has been very helpful. The same goes for many other concepts.

    Now, even avoiding useless stuff, you'll most likely miss a lot of good reading too. It's just too much for not so much time. Not being able to read today something you really want to is frustrating, but there's always tomorrow. Here's where you exercise your patience.

    The power of a community

    As I've mentioned, a community helps a lot in curating your studying materials, but not only that. A community also may encourage you to keep improving yourself, giving feedback, proposing new challenges, and actually merely talking about a subject helps you keep motivated.

    So, this is what brought me to PerlMonks. Much is said about CPAN being one of the greatest features of Perl, and certainly I agree, but I also believe PerlMonks is a feature many other languages lack.

    In fact, CPAN itself is a community effort, and I believe that's one of the reasons it's so much appreciated by perl users. Of course, it wouldn't do much good if it didn't help us get things done, but the community thing is core to CPAN's existence.

    Getting help from a community may be rewarding, but, at least for me, giving back is even more rewarding. Even when it's a very small contribution. We have limitations after all, but we can always do something.

    Some things just take time

    No matter how hard you try, some things take time. Accepting this fact may be liberating. Again, each step in a learning path should be properly appreciated. The beginning should be the most exciting part of the process, and here's good news: each step is a new beginning.

    There's too much hype on being an expert on anything. Becoming an expert should be considered a good thing, of course. But what happens when it's so much desired and beginning is so underappreciated? You try to hurry (and gets frustrated, as it doesn't work).

    Aside from that, there are too many "fake experts" out there. People who, as I said, are driven by vanity (and lazyness too). When you act like that you may fool some unwary people sometimes, but don't fall for it, you'll be unmasked sooner or later.

    You shouldn't hurry, but if you do, make sure that learning is your primary goal, and not something else. In fact, I believe some other languages are far more popular than Perl just because they have much more immediate pressing concerns involved, that have nothing to do with learning.

    And remember, this piece of advice comes from a beginner. As such, I know there's people out there who could say a lot more on this subject. Yet, that didn't prevent me from trying to contribute. For me, that's the spirit in a community. And you don't have to take my word for it, but if you came to the end of this post, then I believe you're at least willing to try.

File lock demo
6 direct replies — Read more / Contribute
by LanX
on Apr 21, 2021 at 12:25

    I needed to use flock and found the docs confusing and the demo code slightly dangerous ( lock is another builtin for threading)

    So I hacked a demo script, where only one instance will count from 1 to 10 when simultaneously running.

    On windows you can start 4 simultanous instances from CMD with

    > start perl demo_lock.pl & start perl demo_lock.pl & start perl demo_ +lock.pl & perl demo_lock.pl

    The first three scripts will pop up in separate windows which you could/should arrange to be visible.

    Have fun! :)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[RFC] Module code and POD for CPAN
6 direct replies — Read more / Contribute
by Bod
on Apr 13, 2021 at 17:27

    Having needed to implement a simple workflow for taking card payments by Stripe and knowing that I need to do the same again soon for a different product set, I have created a module that I think will be useful to other people. Existing modules to connect with Stripe either do not cater for the latest security measures of 3D card payments in Europe or are a wrapper for the Stripe API. Both of which are, of course useful. But I wanted to create something easy to use that can be used for the typical simple workflow required by many small businesses.

    This gives a simple workflow of adding products to a 'Trolley' and then sending the user directly to the Stripe hosted checkout. From there, Stripe returns to either a success URL if payment was taken successfully or a cancel URL if, for any reason, the transaction failed.

    Could you please provide me with some feedback regarding both the code and the POD ahead of uploading it to CPAN?

    I was thinking Business::Stripe::Simple as the module name - is that sensible?

    Note - at the moment, the examples in the documentation have not been tested. They will be before uploading!

    Thank you to the Monks who have helped me develop the skills to get the module this far and to the ones who will give useful feedback.
    It is very much appreciated.

    I have run the code through Perl::Critic and it passes at 'stern' but generates warnings at 'harsh'. One thing it has found are tab characters instead of spaces despite changing my editor to use spaces after this discussion. I will take out the tabs that have crept in from copying and pasting a few bits of code.

    On the suggestion of Critic, I have moved the declaration of $VERSION to after use strict;. Although I thought that had to be first for the CPAN toolchain?

How Perl revolve
5 direct replies — Read more / Contribute
by xiaoyafeng
on Apr 11, 2021 at 02:00

    Recently, P5P is arguing about the future development of Perl. As a long-term user of Perl (but not a core developer), I also have some ideas of my own.

    The first and most important question is, what are Perl's real capabilities / advantages? sigil? Regexp? On some degree, yes, but not exactly. Perl's real power lies in its expressiv power and self-evolvement. Language is language, and computer language is also a kind of language (although many people don't realize it now). The purpose of language is to communicate and express what they want to express. At the beginning of Perl language, Larry learned from many excellent functions of the language, so it can let people express what they want quickly accurently, which is the real reason why Perl stands on the river. So I conclude below by learning history of other languages(including human languages):

    1. When the language can't deliver what it wants to deliver quickly, there will be fewer and fewer users stay there, such as COBOL, lisp, Latin (human language), even if they have many bright spots.
    2. Without users, the language will die. In history, many languages have died out, they may have many advantages and characteristics, but now these characteristics may exist in other languages, but they themselves have died out.
    3. The language needs to quickly implement the features it needs, not whether it is elegant or not. Think about Japanese, Chinese, and even English. In the long history, they constantly learn from other languages to implement some new concepts. These implementation may conflict with their own, but it doesn't matter. As long as they can quickly accurately deliver these new concepts to achieve the purpose of communication, the language will not die. Languages that have been slow to implement new functions for the sake of elegant implementation (or because of lack of manpower) have all died out.

    Let's go back and see how Perl should do? In recent years, Perl supporters have said that the advantage of Perl is CPAN (stand on the shoulder of cpan). what does it really mean? It means that Perl also has all the functions and libraries which other languages have(though there is maybe not in Perl itself)

    Unfortunately, I personally feel that the core developers of Perl seem to have lost the direction of Perl(perhaps because of the stepdown of Larry?). They are addicted to deprecate the old functions instead of adding new functions and facilitating cpan developers. This leads to several severe problems to perl:
    1. More and more modules on cpan are not available, and even many authors give up their own modules because they want to adapt to new changes
    2. Because XS and its toolchain are too specific to C language and Perl, it is difficult for people who are not familiar with Perl to develop interface libraries. Think about UV, such a popular library needs people like peavans to maintain.
    3. Due to the lack of new functions or new libraries, Perl has fewer new users, such as GUI and parallel programming. This is a vicious cycle. Due to the lack of language functions and the complexity of language level, fewer and fewer people use Perl. Therefore, there are fewer and fewer heavyweight modules in cpan, resulting in fewer and fewer people using Perl. It should be understood that the difficulty of learning the language itself is never the first thing for users, but the function is. As long as you have the features users want, no matter how difficult, they will learn.
    I admit that due to the lack of core developers, it is more and more difficult for Perl to implement new functions. Thus, I think the short goal of core developers should be how to make it convenient for cpan authors, especially some tools for quickly borrowing features/libraries from other languages. Imagine the real language, there are many words in English, which are borrowed directly from French, Japanese and many more. Some words have never been officially deprecateded. But the real function is used naturally, the bad function is put there, the user slowly becomes 0!

    To sum up, I suggest that the core developers of Perl should be able to focus on (of course, this is only my personal wish) redesigning and implementing a language layer for communication with other languages. The current XS and its toolchain are too limited to C and obscure which makes it difficult for the user to develop such an interface.

    In addition, the layer between languages should not be limited to compiled languages, but also include virtual machine languages and other specifications(consider how many ppl on windows use Win32::OlE). Because we are short of developers, when a new popular application or library appears in other languages, it may be difficult for us to have the corresponding Perl version very quickly. If there is a convenient way to establish a conversion layer at this time, so that Perl users can stay in the Perl world happily, I think it is great incentive for the use of Perl! FFI:: platypus does very well. I hope it can enter the official package when it's mature. but I also want it could be more ambitious. to introduce more virtual machine languages, including C sharp, node.js , GO, etc. Inline:: XX may also be a direction, but it seems too dulicate to write its parsers for each language.

    Of course, in the long run, of course, P5P can slowly polish the Perl language itself, maybe including type system, object system, better regexp, concurrency programming, etc. but it should be noted that language and its new features need to be learned by users. First of all, users should stay in Perl, without users, language and its features can not prove whether they are useful or not.

    I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

"Magic tools" that take the fun away
6 direct replies — Read more / Contribute
by hrcerq
on Apr 08, 2021 at 16:18

    Hi, folks.

    Recently I've found (here in PerlMonks) a link to one of Donald Knuth's great talks: Computer Programming as an Art. Knowing it was Knuth's sutff, I knew it would be worth my time.

    One of the (often overlooked) benefits of computer programming is that it can be fun. But Knuth goes beyond that stating that it should be fun and that a program should be beautiful. Fun and beauty add a lot of value to the program and to programming.

    Now, at the same time, observing the IT industry as whole, we can see how much the fun and beauty of programming are being overlooked. More and more "magic tools" are making way to sysadmin jobs, and they're focused on people who don't want to program. IT managers often see them as a means "not to depend too much on programmers". It's laughable, but I've seen it a lot.

    One example of such tools are the configuration management tools, such as Ansible, Puppet, Chef and similar tools, which take a more declarative approach to systems management. I'm not saying these tools aren't useful (or even that they are necessarily bad), but I feel like they've taken a lot of the fun away from systems management.

    This is not to mention GUI-only tools, which are mostly closed-source. Fortunately I've been far from them. But currently at my job, I help maintain some Ansible routines, and sometimes it's a daunting task. I can't remember how many times I had to grep a repository to find out when some variable was being set. If a declarative approach should be friendly, then I must say it has failed in my case, because the repository I work with has grown into a messy beast (I'm sure my co-workers agree).

    Yet, I remember once I've put a perl one-line command in a playbook and was critized precisely for this action. I was told it would bring complexity and that other people would have difficulty maintaining perl code. Can you believe it? A one-line! I'd say it's a joke if someone else told me.

    Of course, I wouldn't give up on Perl because of that. But it makes me wonder why must we always prove something that exists for decades is worthy a try, while something created a few years ago is promptly accepted. Of course, it's just my point of view, which not necessarily happens everywhere. Other points of view would be much appreciated.

How old is too old?
4 direct replies — Read more / Contribute
by Bod
on Apr 08, 2021 at 16:01

    Over on Re: How Xerces validation access http schemas ?, hippo wrote "It's worth noting that the most recent versions of XML::Validate and XML::Xerces are from 15 years ago and may not play so well with modern systems". This immediately reminded me of a recent search for modules to connect with PayPal where I found Business::PayPal::IPN but didn't look any further than the date which is AUG 19, 2003.

    Clearly for things that connect to frequently evolving APIs, being quite up to date is pretty important unless the API allows use of a particular past version. But for things that don't change much, like XML, the need for recent updates is less apparent. As hippo puts it, they need to "play well with modern systems".

    So, when deciding whether to use a module, or anything else for that matter, how old is too old?

[RFC] What is [pP]erl to you, and how has this changed for you over the years (if it has)?
3 direct replies — Read more / Contribute
by perlfan
on Mar 31, 2021 at 18:22
    I'm just as curious about the value of this exercise as I am the answers, but I wanted to request something. Originally, I wanted to as, is perl a unix utility or is it a language?. Then I realized, this has many dimensions and I'd rather not beg the continuum of answers upfront; but it's worth at least sharing this point. Anyway, this seems especially timely given the recent discussions on p5p and elsewhere about a whole lot of things related to [pP]erl.

    Some politely requested ground rules:

    • refrain from replying to anyone else (except OP)
    • please don't ++ OP, I'm not doing this for XP (-- if you must, that's not the ask)
    • upvote replies, this provides information/consensus
    • refrain from downvoting sincere replies, even trolls/rants (for real)
    • focus on your own perspective (this is not currently a debate or zero sum game)
    • feel free to post anonymously
    • post only once, feel free to edit/update your node as much as you want

    Okay, so why am I doing this? For the children. (Seriously, I have a follow up about "the future"; but be patient). I'll probably give that in a few weeks. TIA

[RFC] Review of module code and POD
6 direct replies — Read more / Contribute
by Bod
on Mar 31, 2021 at 15:45

    Esteemed Monks,

    For all past time we have connected directly to our CRM from the scripts that need to read or write the data. It has been my intention for a very long time to create some standard subroutines in a require file to do all the things we regularly need to do. Thanks to The Monastery, I now know I need to use a module to do this. So I have set about creating a suitable module. I also thought this would be a good opportunity to do it properly and include some POD. This module will never be used outside of our use case but it seems like good practice to include documentation.

    Could you please look over the code and documentation and for me before I go too much further and advise if I am making any horrible mistakes, what I can improve and how clear the documentation is...

    I have pulled out anything that could pose a security threat to Bod::Variables. Not just database username and password but also schema name and table names.

    The documentation as generated by pod2html is here.

I just had to share this (Quora comment on Python)
2 direct replies — Read more / Contribute
by ait
on Mar 29, 2021 at 13:49

    As I was reading some random old thread on "Why is Python so bad?" I came across this comment which I think reflects why I love Perl so much:

    Sudhir Sudhir
    July 29, 2019
    Python is considered bad because it suffocates you to death while being deaf to the prey’s death cries. It falls on you unexpected from the top of a tree and before it swallows you it has to crush your bones and make you a sack of pulp for easier consumption. Very painful. Won’t recommend at all. It’s not venomous, so you have no option of getting hallucinations through the painful experience before death either.

New RFC for CSV in the pipeline
1 direct reply — Read more / Contribute
by Tux
on Mar 16, 2021 at 09:07

    I wonder how much code would break if all of what RFC 4180bis proposes would be blindly implemented by parsers.

    I bet there are tons of CSV files out there that are not UTF-8 and/or do not follow BOM correctly or are real binary to start with.

    And what about point 8:

    A hash sign MAY be used to mark lines that are meant to be commented lines. A commented line can contain any whitespace or visible character until it is terminated by a line break (CR, LF or CRLF). A comment line MAY appear in any line of the file (before or after an OPTIONAL header) but MUST NOT be mistaken with a subsequent line of a multi-line field. Subsequent lines of multi-line fields can start with a hash sign and MUST NOT interpreted as comments. For example: #commentCRLF aaa,bbb,cccCRLF #comment 2CRLF "aaa","this is CRLF

    This would require new options in all parsers to reject lines that start with a #.

    As Text::CSV_XS already implements/supports all other options, I wonder if there would be enough motivation to add attributes to recognize/skip comments (which would also require a new config variable that contains the comment lead-in (#, // sprint to mind) and if a leading comment string would only be valid if followed by whitespace (probably more things to consider). This would also mean impact on strict as comments (and empty lines) will, per definition, nog have the same number of fields as the rest of the data.

    Ideas welcome as usual.

    Enjoy, Have FUN! H.Merijn

Add your Meditation
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":