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
Rediscovering Hubris
2 direct replies — Read more / Contribute
by Leitz
on Jan 17, 2021 at 18:40

    A line from perlootut goes, "There's really no good reason to write your classes from scratch in Perl." I beg to differ. There are many reasons we come to Perl; often those reasons are unique to each individual. What brings the perlootut authors to Perl may not be the same as what brings any of us.

    Long ago, when the O'Reilly Perl book was much thinner and had a pink spine, hubris was a valued quality in a Perl programmer. Today many are shunned because they use "ancient" Perls, anything less than 5.30 is "EOL". Some of us have to live in the world that doesn't auto-upgrade Perl. We're told to get some collection of modules from CPAN, everything is already done for us. That's a wonderful idea, but it doesn't play out. Many modules depend on XS, or depends on something that depends on XS, yet not every compute node has a compiler. Or the CPAN module depends on something that requires a more recent version of Perl than what we are allowed to code for.

    I have actually been told that I should look for another job if work won't upgrade language "X" to a more "modern" version. No real reason, just "more modern". Hubris can have a negative incarnation.

    Hubris can help us move forward when the world seems against us. Outside of that one sentence, the perlootut is a wonderfully written and useful document. The perlobj page is also top of the line documentation. In hubris I try to code for Perl 5.8. Not because that version is any better than later versions, quite the contrary! The Perl maintainers do a great job of keeping the language moving forward. In hubris I create objects without Moose, Moo, or any other CPAN OOP module. My good reason is so that I better understand what is going on and how Perl objects work. In hubris, because I dislike the fragility that comes with unnecessary complexity, I seldom use CPAN modules.

    Despite my struggles with Perl, and the occasional (more than occasional) muttered curse onto whomever thought 27 layers of sigils is human readable, Perl is its own "killer feature". Solid Perl 5.8 code still works well. If you removed CPAN from the multiverse, Perl could still do more than most of us. Other (dang near all) languages are easier to learn. Some of them have much faster performance, or significantly more hits on job search boards. At the end of the day, though, if it can be done then you can probably do it in Perl.

    I currently work in Perl. To push my skills further, my personal projects (toys, really) are in Perl. Despite being a slow learner, and struggling every day, I honor my employer by doing my best. And that is my killer feature.

    Chronicler: The Domici War (domiciwar.net)

    General Ne'er-do-well (github.com/LeamHall)

For discussion: operator attributes - associativity, chainity and ability to short-circuit
1 direct reply — Read more / Contribute
by rsFalse
on Jan 13, 2021 at 15:47
    Hello.
    Perl 5.32 (year 2020) introduced a new ability of binary comparison operators. Now they can be chained! ( https://perldoc.perl.org/5.32.0/perldelta#Chained-comparisons-capability ).
    And perldoc describes this new usage in:
    * https://perldoc.perl.org/perlop#Operator-Precedence-and-Associativity
    * https://perldoc.perl.org/perlop#Relational-Operators
    * https://perldoc.perl.org/perlop#Equality-Operators

    There are some short-circuiting operators in Perl from before 5.32 version: &&, ||, //, and, or (not xor).

    What is difference between associativity and chainity?
    I suggest to distinguish these two attributes of operators as follows: associativity only sets a direction of operations; chainity sets an ability to 'communicate' between consecutive operators, in other words - a later operator can influence the behaviour of a former operator.

    Then I suggest to improve a table of Perl operators by introducing two more columns: chainity (ability to chain) and ability to short-circuit.
    This will help to newcomers and beginners! I have often used these tables of operators from perlcheat and from beginning of the perlop:https://perldoc.perl.org/perlop#Operator-Precedence-and-Associativity, because it takes time to remember precedence and direction of associativity. Two new attributes in the table will be more usable than a searching of them through the whole long perlop document.
    In the current table of attributes I find only one column, which contains values: nonassoc, left, right, chained, chain/na. Chained implies associativity, but it lefts its direction undefined, e.g. in the line: "chained     < > <= >= lt gt le ge" newcomer doesn't know direction. We know - it is left-assoc.

    Perl is difficult to memorize and it has long learning curve because of its archaity and many many rules with many exceptions, which makes a life easier, but makes learning/memorizing - difficult. So tables/cheatsheets are useful to have near a hand. E.g. operators 'or' and 'xor' seem similar by their appearance and by their category (both are logical operators), but one has an ability to short-circuit and another - hasn't. This was a surprise for me. Upd.The surprise was not about short-circuit, but about returning last evaluated value.

    I can't test a new perl 5.32 now (perlbrew isn't working, and there are no online IDEs where I could find a new version: all use older versions, including WebPerl:https://webperl.zero-g.net/democode/index.html which uses 5.28).
    But I hope that I will be correct when talking further about new abilities of comparison operators.

    So, first of all I guess that new version outputs different results for these two lines of codes:
    2 < 4 < 3 and ( 2 < 4 ) < 3. In the first example the chaining of operators occurs and in the second example - ordinary comparisons occurs. First outputs - 0/'', second - 1. Am I wrong? Here parentheses cut a chain of operators: one operator doesn't see another. If second behaves same as first then it would be backwards incompatible.

    Only some examples of chained comparisons: "1 < 3 <= 3 > 0 le 1 gt 0 ---> 1", "1 < 2 < ... < 9 ---> 1", "1 ne 2 ne 1 ---> 1".

    How can we describe a behaviour of chained comparison operators?
    I suggest the following way. If an operator "sees" another operator towards the direction of associativity (i.e. it is chained to it), then it changes it behaviour (btw. becomes overloaded) - it compares both operands and in case of TRUE returns right operand (once evaluated), and in case of FALSE - returns 0/''. This description allows the last operator to be not chained, so it will behave as usual comparison op (TRUE - 1, FALSE - 0/'').

    Chainity implies (requires) associativity, as ability to short-circuit does, but chaining does not imply an ability to short-circuit and vice versa, so I suggest to keep these two attributes separately. Maybe in a future perl such will occur.
    By the way, operators  &&, ||, //, and, or are short-circuiting, but they are not chained (i.e. we can put parentheses in left-assoc pattern to "blind" consecutive operators and result will not change).

    Also I have an idea (I don't believe that it is good, but I leave it here if someone wants to discuss). That: writer could choose by himself if he wants his operator to look to the next operator (i.e. to make a chain). One way could be to prepend '&' before an operator. So then $A &< $B &> $C < $D should work as a chain (note no '&' at the last operator).

    Once more about tables. From perlop it is unknown which 'equality' operators can be chained and which can not. This needs a clarification.


    Here I'll leave some links to older topics (by me), which can be somehow related to this one:
    Pls more operators, e.g. <&&=
    'xor' operator is not a sibling to 'or' and 'and'?
Is typeglob feature really useful?
4 direct replies — Read more / Contribute
by xiaoyafeng
on Jan 09, 2021 at 12:48

    As we all know, Perl support same name but different type, that means $foo and @foo could be both exist without any violation.

    This sounds a smart and nature feature, but from time to time, I suspect if it's useful. During my life, I've never defined 2 different type of variables with same name. Considering perl have to define a special(or maybe huge and complex ) data struct to store glob, if we discard this feature, maybe perl could be faster and simpler?

    Just a thought jump into my head, Please enlighten me. Thanks

    EDIT: modify title as LanX point out.




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

Diary of a Zydeco experiment - E04 - Renaming
No replies — Read more | Post response
by Smonff
on Jan 08, 2021 at 11:16

    This is the fourth episode, and after Diary of a Zydeco experiment - E03 - Errors for fun and success, I came back here to deliver some news. The project is not progressing much since I had to move recently and have to renovate a house. I never spent so much time away from my machine (how sad).

    Anyway I am seriously thinking about changing the namespace for the Art::World project and move it to the Acme:: namespace... This thing looks more and more like an experiment that will surely never be used by anybody except me and I see it humbly as an artwork by itself, but I guess it will be the final project. It's not like people would start to use it as a dependency. Or maybe only for showing examples of my bad coding practices.

    Since September 22nd, a small amount of tasks have been started:

    • switched the project to only one large module, trying to make it the Zydeco way,
    • moved the ideology documentation to a separate pod
    • added Underground, Space and Market roles
    • Nested playground and Place classes
    • Added Event, Opening, Sex, Collective, Magazine, Institution, Squat, Workshop, Website, Critic, Article, and Book classes
    • Applied Collector type constraints on class Artist and role Collectionable
    • Removed the Wildlife class since it is redundant with Art::World Agent
    • tobyink suggested the removal of duplicated attributes in nested classes
    • added a Fame role and moved the Agent reputation there
    • forced the Collector->collection to be composed of Artwork(s)
    • listed contributors of the project
    • created various Collector methods like sale() or acquire()
    • tried to use Type::Tiny more efficiently and upgrading to its last version that offered non quoted types constraints for attributes (see RT #133448)
    • adding a Makefile
    • introduced Conf::Tiny
    • added a minimal Meta toolkit
    • limited Perl version to > 5.24.0
    • Event is now a Role, not a Class because we do composition, not multiple inheritance
    • enabling the postderef feature everywhere because we are so MODERN
    Finally, it was quite a lot... Cant wait to rename to Acme::Art::World !

    🌸
Happy 2021
2 direct replies — Read more / Contribute
by misterperl
on Jan 06, 2021 at 11:08
    I guess this isn't strictly a question but ....
    print "thank-you Monks!\n\n"
    for all of your excellent advice in 2020. I always have a bit of apprehension that people will think me a dummy, but in this land, thankfully, kindness abounds ! Your replies were most helpful.

    I wish you all a healthy and successful 2021 and may

    THE SOURCE BE WITH YOU!

    - Mr P

cpan: Terminal does not support AddHistory.
1 direct reply — Read more / Contribute
by kcott
on Jan 04, 2021 at 23:39

    I have been seeing the following, for the past 18 months, every time I use the cpan utility:

    $ cpan Terminal does not support AddHistory. To fix that, maybe try> install Term::ReadLine::Perl cpan shell -- CPAN exploration and modules installation (v2.28) Enter 'h' for help. cpan[1]>

    I looked into that briefly (and unsuccessfully) several times; in general, whatever I wanted to install via cpan was more important than AddHistory, which I only use infrequently anyway, so it ended up on my TODO list.

    I tried with the suggested module, Term::ReadLine::Perl, as well as a variety of others including: Term::ReadLine::Perl5, Term::ReadLine::Gnu, and Term::ReadLine::Tiny. These all failed, the most common problem being the process hanging when the Term::ReadKey dependency was being installed. Actually, installation of Term::ReadLine::Tiny worked fine but it didn't provide AddHistory.

    I spent some hours this morning looking into this and eventually came up with a solution. My basic Perl setup is: Win10 - Cygwin - Perlbrew - Perl 5.32.0. If you're experiencing the same problem, this solution may work for you: I can't make any guarantees as I don't have other systems on which to test this.

    The only thing that worked was a completely manual installation.

    Download https://cpan.metacpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz then run the familiar incantation:

    $ tar zxvf TermReadKey-2.38.tar.gz $ cd TermReadKey-2.38 $ perl Makefile.PL $ make $ make test $ make install

    Download https://cpan.metacpan.org/authors/id/H/HA/HAYASHI/Term-ReadLine-Gnu-1.37.tar.gz then a very similar incantation:

    $ tar zxvf Term-ReadLine-Gnu-1.37.tar.gz $ cd Term-ReadLine-Gnu-1.37 $ perl Makefile.PL $ make $ make test $ make install

    Now I get:

    $ cpan cpan shell -- CPAN exploration and modules installation (v2.28) Enter 'h' for help. cpan[1]>

    and moving through the command history and editing is now possible.

    If you were experiencing similar problems with a different setup to me — and found this worked as is, worked after some modification, or failed abysmally — please leave a note for the next reader.

    — Ken

Requesting review of new distribution information
4 direct replies — Read more / Contribute
by stevieb
on Jan 03, 2021 at 10:11

    Hey there fellow esteemed Monks!

    I've come to the Monastery today to ask a favour. I'm just finishing up a very long desired Perl distribution that I should be ready to publish within a day or two, and would like to ask if some of you would review and provide feedback on the README file to see if A) it's easy to understand, B) explains things unambiguously and thoroughly enough, and C) whether there are any features that I may have overlooked.

    The doc should provide enough of an understanding of what I'm trying to achieve, but here's a summary:

    I have over 50 CPAN distributions published, and many of them are tools to help the developer. I've always wanted a way to automatically manage my distributions from initial creation, inclusion of other features, and an automatic way to perform a release and the subsequent bump to a new development cycle. This distribution does all of this.

    The distribution is named Dist::Mgr, and although I've already released a version to the CPAN, it does not work, and was only put there to verify POD formatting etc. The included binary script is named distmgr, which is what the README focuses on.

    The link to the README on my repo is right here.

OT: memory to share available
7 direct replies — Read more / Contribute
by shmem
on Jan 01, 2021 at 17:09

    A few years after karlgoethebier it struck me. At age 59 $company laid me off. Good riddance.

    After 8 years of not being seen really, being handed around, trying in vain to get a peer programmer at the site, mobbing, bossing, you name it, it is good to depart. There's crucial code I wrote (a pile of, er...) living there which drives part of the business, and there has been no chance for handover. Go figure.

    I still feel responsible for all my perpetrations done, and they might come back to me for something something. Meanwhile I am enjoying the quietness of being unconcerned after having lived the quietness of disinterest paired with anxiety about when I will be fired.

    Eat it, sucker! you didn't live up to the task, I'm telling myself. As did the TCO, having the psychological sensibility of a tank (not talking about technical skills, at all). Yeah, true, I says, but there's two sides. Flowers don't blossom in the dark, and hurling somebody down the cellar stairs shouting "why are you running?" isn't fair either.

    Anyways, I might retire and try to implement perl in FORTH, or else. This is still humbly me at your service, at least at PerlMonks. I might have more time to read and post. The Great Constellation at the tip of Aquarius shows that "the times, they are a'changing".

    For the "or else" part, feel free to contact me.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
My First LinkedIn Article On Perl
6 direct replies — Read more / Contribute
by pritesh_ugrankar
on Jan 01, 2021 at 09:43

    Respected Monks,

    I've come here often to glean knowledge, ask questions, get solutions and at times, just for fun to check things out. Perl and PerlMonks has always stood me in good stead and a great source of knowledge.

    However, I've been seeing a lot of negative stuff spread against Perl and could never figure out why.So, in my attempt to get back at all this negativity, I've written an article on LinkedIn Titled "Perl Myths" https://www.linkedin.com/pulse/perl-myths-pritesh-ugrankar. Humbly request you to please check it out and like/comment/share/ but most importantly, please let me know if there are any erroneous statements.

Becoming Just Another Economically Viable Perl Hacker
2 direct replies — Read more / Contribute
by Leitz
on Dec 24, 2020 at 11:39

    I get paid to code in Perl. Which has humor value, because there are many, many Perl programmers who are better coders than I am. For those who might want to move from "Perl as a hobby" to "Perl as a job", my number one recommendation is to read and implement Josh Kaufman's "The Personal MBA" (PMBA).

    If you want to program for pay, you are a business. Many of us skipped business school, and few of us can afford to take several years off of life so we can spend a few hundred thousand dollars to "learn business". In PMBA Josh explains the basic functions of business in easily digestible sections. Some of the insights seem basic; like creating an Economically Viable Product. Yet how we perceive ourselves as a producer influences how we present ourselves. For example, a person goes to a hardware store and buys a quarter inch drill bit. They don't really care about having a quarter inch drill bit, but they do care about being able to make quarter inch holes.

    Hiring managers have the same perspective. They don't need another programmer, but they want to solve business problems with software. They need the ability to turn business needs into robust and maintainable code in a cost efficient manner. As you market yourself, how can you move from saying "I'm a programmer" to "I solve business problems using computer code"? Does your resume show that? Would your current team (paid or not) recommend you for that ability? If not, spend time resolving that. Build the reputation for solving problems. Build the reputation for being someone others enjoy working with. Write code that others can test and support.

    2020 has been a rough year for many of us, and there many problems to be solved. Bring your problem-solving self to the table, the world needs you.

19 years and still visiting ..
1 direct reply — Read more / Contribute
by talexb
on Dec 12, 2020 at 10:56

    Good localtime, all.

    I'm writing on the occasion of my monk-day. Nineteen years have passed since I first joined this little community, based on a recommendation from TheDamian that I read in the pair.com monthly newsletter. At the time, I'd been using Perl for about three years, and wanted to expand my horizons from just a mailing list and the monthly Toronto Perlmongers meetings.

    I'm still a little amazed that a language I picked up to 'try a few things in' has ended up supporting me for over twenty years -- but open source can be weird like that.

    Remember -- never stop learning. And, whenever possible, be kind. :)

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

2021 is the year to drop support for Perl < 5.12?
4 direct replies — Read more / Contribute
by tobyink
on Dec 11, 2020 at 05:46

    Also posted this on reddit.

     

    So I am trying to transition from using Travis-CI for some of my Perl projects (and no CI at all for the rest) to using Github Actions for all of my Perl projects.

    And it looks like I'll also soon be switching all the issue trackers over from RT to Github Issues.

    And I'm starting to think now might also be the time to drop support for Perl 5.6, 5.8, and even 5.10.

    This doesn't mean that I'll be deliberately breaking anything on them. I'll just stop testing them.

    I would probably also include something like this in Makefile.PL:

    if ( $ENV{AUTOMATED_TESTING} and $] lt '5.012' ) { print "I really don't care.\n"; exit 0; }

    Which I believe will earn me "NA" reports from CPAN testers, but still allow regular humans to install the distribution without issues in most cases.

    So why do I want to drop support? Mostly because although I'm happy for my modules themselves to support Perl 5.8 (and even in some cases 5.6), getting a modern toolchain including cpanm, prove, etc working, cross-platform, on Perls older than 5.12 is increasingly difficult.

    So consider two scenarios:

    1. I continue to support those versions of Perl. I have to jump through hoops to do this. You, if you're still actively using those versions of Perl are probably also needing to jump through a lot of hoops to maintain them. We both have to jump through hoops.

    2. I stop supporting those versions of Perl. I don't have to jump through hoops. You, the person actively using those versions of Perl, still have to jump through hoops, but you already were. Worst case scenario, I've added maybe one extra hoop.

    Why 5.12 in particular?

    • 2021 will be the tenth anniversary of Perl 5.12.

    • If we're prepared to deliberately break older versions and use v5.12, then:

      • It gives us //.
      • It gives us state.
      • It gives us say.
      • It gives us implicit strictures.

    There are tempting reasons to choose 5.14 instead (keyword API, JSON::PP and HTTP::Tiny in core, s///r, etc) and even 5.16 (big Unicode improvements, __SUB__) or above, but for most distributions, I think 5.12 feels right, and January 2021 seems a good time to introduce that policy.

    What do other people think though?

The ActiveState Platform and Perl 5.32
3 direct replies — Read more / Contribute
by autarch
on Dec 10, 2020 at 16:22

    Note: Technically, this post qualifies as paid promotion, because I work for ActiveState. But I volunteered to write about our new Platform and promote it because I think what we're doing is really cool and might be of interest to the Perl community at large.

    This is a short excerpt of a longer post that you can read in full on my blog.

    TLDR

    • We have an entirely new system that supports Windows and Linux (macOS coming soon), providing you binary builds of the Perl core, Perl distros, and supporting C/C++ libraries.
    • When you use our State Tool, you can create any number of entirely self-contained virtual environments, one per project. This makes switching between projects trivial and these virtual environments are easily shared across a team or organization.
    • No more ActiveState Community License! The only licenses that apply are the original licenses for each open source package we build for you.
    • You don't need a Platform account to try this out. But you can play with our system and sign up at any time and keep all the work you've done so far.
    • It's usually quite fast. If we've already built a particular distro/language core for the given platform, we use a cached version, so many builds take a few seconds. Entirely new builds are slower, but still faster than doing it by hand locally in many cases, because we distribute work throughout a build farm.
    • The core features are all free. Most features are free for public projects. We also have paid features including private projects, build engineering support, support for older platforms, indemnification, and more.
    • The Platform has lots of other cool features like revisioned projects, advanced dependency resolution, and more.

    Read the rest of the post.

Why Perl in 2020
12 direct replies — Read more / Contribute
by ait
on Dec 09, 2020 at 12:06

    Dear fellow monks,

    This is an opinion piece, flames > /dev/null please.

    As this crazy year approaches itís culmination, I would like to reflect on why I still choose Perl (and C) for most, if not all, of MY work. Disclosure: I make a living with Java, Docker, AWS and a lot of tools considered ďmainstreamĒ, but I do this because companies are already biased towards whatís popular, not necessarily whatís best. And they pay good money to continue with their suffering.

    In my personal endeavours however, I rarely leave the ecosystem of Perl, C, FreeBSD, and PostgreSQL. Itís a sharp contrast to todayís virtualized and SaaS world, and I wonder how these companies are so stupidly herded into working like this. I mean, back in 2006, I was creating Web Services on mod_perl2 that were hitting 6.5K TPS on a single node and I was deploying with FreeBSD Jails, almost identical to what people are doing today with Terraform and Docker, albeit, at a micro fraction of the cost. Today, the best stuff I see with the container-micro-services-mania, is a few hundred TPS at best, and extremely costly and complex. People are probably spending 100x as much as they would have spent, using bare metal and real people.I mean real programmers and sys admins who actually knew what they were doing to fine tune a real architecture.

    Something smells really bad.

    Sure, the modern environments shiny, somewhat convenient and hip, with SaaS or GUIs for most everything. But itís costly and stupid. My guess is that companies will start to wake up one day, like from a bad hangover and say: W.T.F. are we doing? And itís not just AWS, but to me the whole toolchain is broken and just crazy. The amount of waste is just horrendous and unsustainable. Just how many layers of shit are we going to continue to pile up until we realize something smells really, really bad.

    Same thing with programming languages. The Java world is honestly laughable, nobody really knows what Java is anymore (most everything relatively useful and ďmodernĒ in Java is based on bending the language with generics!), and ďportabilityĒ is a widely disproven myth. Then you have the plethora of new and hip languages and frameworks and the young coders who think just because Google or Facebook backed it, It must be good. Guess what, most companies are not Google or FB.

    But when Netflix wakes up and rewrites their CDN on bare metal with FreeBSD it hardly makes the news.

    So back to Why Perl in 2020...

    Well first, we finally got rid of the Rakudo shadow(see Note 1 below) Raku and Perl languages were finally separated, lifting the long cast shadow of "Perl 6" on Perl, and Perl 7 is now on itís way!

    I canít believe we didnít see this textbook example on how to kill a good existing product: advertise the new one is coming, before itís even born. There are so many examples in history, of organizations shooting themselves in the foot this way, itís even stupid. And yet, we did exactly that. The way Perl 6 was managed was really destructive to our beloved language, and our community. Yet here we are. We survived, we are tired and demoralized, yes. But I truly think we can finally start to heal and oxygenate the ecosystem with the coming of Perl 7.

    Itís time for a new dawn of The Programming Republic of Perl. Yes, we have lost a few battles, but this is a long term stamina race, not a short term sprint. There is a new saying amongst investors these days: the age of the Unicorns is over, it is now the age of the Camel. I think we should take this one home.

    So why Perl in 2020, or 2050 or 3020? Simple: Perl is probably the most malleable language on the planet. I donít think people realize it, and truly understand the value of this. IMHO, itís the one thing that no other language can really come close to Perl.

    You can start Perl project as a one-off script and then refactor it all the way up to complete Object Model like Moose (contrary to the half-baked Java OM), or you can go the Functional route, or better yet, use both. You can evolve your code using different paradigms and different frameworks (all staying within the same CPAN ecosystem) to address different problems you will encounter along the way. You can hammer out performance bottlenecks over time, even refactor some portions to C, easily! You start out with a simple script and wind up refactoring portions to different frameworks such as POE, Catalyst, Mojolicious, Dancer, etc.

    Mojolicioius itself is based on the same principles (start simple, grow and refactor as you need), which is actually a unique feature of the Perl language itself.

    There is a plethora of other great tools and frameworks in the ecosystem, for every taste, and you can use the same language for your complete toolchain including operations and sys admin. I mean, how cool is that?

    The widespread rumor that that Perl is a write-once language is such bullshit, that people who spread it must have never actually done anything in Perl and probably in any other language, or in their miserable lives for that matter. This unfounded myth cannot be farther from the truth. I have taken all kinds of legacy Perl and slowly transition it to modernize it, or to change itís structure completely in incremental and iterative phases along the way. All other lagunages Iíve worked with, would require complete re-writes, but not with Perl. With Perl you can gradually transition and solve specific issues you find along the way.

    There is no such thing as unreadable Perl. Itís only unreadable if you are ignorant, and as such any language that is not ď for dummiesĒ will not appeal to you. Go code in Python and be happy, but donít trash talk Perl just because you donít get it. Perl is for the artists, the coders that truly want to express themselves in the code itself, to make the code beautiful to them, not to anyone else or some academic fool. Perl can create beautiful code that may look ugly to someone else, thatís perfectly fine. Such is art, and programming is an art, no matter how hard we try to define it in any other way.

    I havenít seen much talk about this malleability of Perl, which to me, is frankly unique. I donít have the academic background in computer languages to formally describe why this is so, but I do have the experience. That is over 30 years of it; not only with Perl, but with MANY other languages. I know what Iím saying is a matter of fact, but I cannot formally describe it or prove it formally. I believe this is a topic that should be studied and formally described, and itís something that could surely help put Perl back in the place where it belongs: which like C, itís probably almost the perfect General purpose language.

    Todayís startup world is fast paced and very dynamic. Product requirements evolve in real time with actual product usage and software needs to adapt at lighting speed. When I see companies struggling every day with even the simplest of problems, I cannot believe they are not exploiting these capabilities of Perl.

    Happy holidays and may the next year bring you all the best!!

    Alex

    Notes and Errata

    Note 1: The original phrase was offensive to Rakudo which was not the intent. Please refer to commentary below for details and clarification.

    Note 2: It is worthwhile to read the comments and replies, especially the the deeper nodes because there is A LOT to learn, A LOT MORE than in my OP. It made me realize there is much more to the Perl 6 story than meets the eye. For example, that early on there was mention to the second-system effect and the Apocalypse, "Second System Syndrome Done Right." , etc. There is also mention on the Three Tales of Second System Syndrome where PHP and Python went through similar processes. So please read the full commentary and deeper nodes for wonderful gems of wisdom, from our much wiser fellow monks.

RFC: Monads in Perl (Send + More = Money)
2 direct replies — Read more / Contribute
by LanX
on Dec 02, 2020 at 13:10
    One of the attendants at German.pm online meeting yesterday pointed to these blogposts of MJ Dominus somehow complaining that Perl is too "clumsy" to reimplement a Haskell solution based on monads

    see

    Basically you have a nice linearized syntax implementing nested loops to find the solution for a number riddle

    Let's say for concreteness that we would like to solve this cryptarithm puzzle:
    S E N D + M O R E ----------- M O N E Y
    This means that we want to map the letters S, E, N, D, M, O, R, Y to distinct digits 0 through 9 to produce a five-digit and two four-digit numerals which, when added in the indicated way, produce the indicated sum.

    the proposed Perl code was actually the semantic translation of some Python code and was indeed clumsy (NB all those curlies at the end)

    Now here my solution reusing some work I've done in the past with List Comprehensions

    use strict; use warnings; use Data::Dump qw/pp dd/; =pod https://blog.plover.com/prog/haskell/monad-search.html https://blog.plover.com/prog/monad-search-2.html =cut # --- List comprehension sub from (&$;$) { my ($c_block, undef, $c_tail) = @_; my $var = \$_[1]; sub { for ( &$c_block ) { $$var = $_; $c_tail->() } } } sub when (&$){ # guard my ($c_block, $c_tail) = @_; sub { $c_tail->() if &$c_block } } # --- rem() Helper function to return digits 0..9 except @_ my %digits; @digits{0..9}=(); sub rem { # set difference my %h = %digits; delete @h{@_}; keys %h; } my ($send,$s,$e,$n,$d); my ($more,$m,$o,$r); my ($money,$y); my $do = # send from { rem 0 } $s => from { rem $s } $e => from { rem $s, $e } $n => from { rem $s,$e,$n } $d => # more from { rem 0,$s,$e,$n,$d } $m => from { rem $s,$e,$n,$d,$m } $o => from { rem $s,$e,$n,$d,$m,$o } $r => # money from { rem $s,$e,$n,$d,$m,$o,$r } $y => # guard when { "$s$e$n$d" + "$m$o$r$e" == "$m$o$n$e$y" } # output sub { pp [ "$s$e$n$d" , "$m$o$r$e" , "$m$o$n$e$y" ] } ; &$do;

    Compilation started at Wed Dec 2 19:11:14 C:/Perl_524/bin\perl.exe -w d:/tmp/pm/send_more_money_monad.pl [9567, 1085, 10652] Compilation finished at Wed Dec 2 19:11:18

    NB: It could be done better and faster, I've just coded this POC from scratch within an hour.

    Please note that making it "lazy" is not really a problem, left for the interested reader.

    So Monads in Perl are not that complicated ... or what am I missing? ;-)

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


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


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.