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").
Googling Organizational Culture revealed many folks offering
(often pricey) Organizational Culture workshops
based on theories concocted by a pair of enterprising boffins,
at the University of Michigan,
located in the picturesque village of Ann Arbor.
Though the definitive reference on their work is available for purchase from amazon, you can also get a feel for their process by reading this early paper:
Abstract: This chapter outlines a process for diagnosing and changing organizational culture.
It uses the Competing Values Framework to describe a validated approach to helping an organization change
from a current culture to a desired culture.
... and from the (mostly youtube) links in the References section below.
As you might expect, I was too cheap to pay for advice on this topic, so instead watched some youtube videos and read Kim's original paper.
Though not necessarily the best organizational change process (alternative citations welcome), at least this
is a concrete thing that can be discussed and analysed, and thus serve as a starting point for
discussing specific ways to improve Organizational Culture (and Perl organizational culture too).
Although many definitions of culture have been proposed, the two main disciplines are:
Sociological (organizations have cultures). Assumes you can identify differences among organizational cultures, can change cultures, and can empirically measure cultures.
Anthropological (organizations are cultures). Assumes that nothing exists in organizations except culture, and one encounters culture anytime one rubs up against any organizational phenomena.
In her 2008 paper, Cameron gave a popular and practical definition of culture as:
the taken-for-granted values, underlying assumptions, expectations,
and definitions present which characterize organizations and their members
serves as the social glue binding an organization together; and
represents how things are around here, affects the way members think, feel, and behave.
and further perceptively noticed that:
With very few exceptions, virtually every leading firm has developed a distinctive culture that is clearly identifiable by its key stakeholders
This distinctive culture is sometimes created by the initial founder: Walt Disney, Bill Gates, and Larry Wall, for example.
All three of these legends developed something special, something more vital than corporate strategy, market presence, or technical advantages:
the power that arises from a unique and spirited culture.
Curiously, most people are unaware of culture until suddenly confronted with a different one:
travelling to Vietnam, for example, finding yourself immersed in different noises and smells and unable to understand a word of the local lingo ... or asking a question on SO after years of posting at Perl Monks. :)
The culture of most organizations is invisible, most members have a hard time describing it, let alone consciously changing it --
that is why you need tools, such as The Competing Values Framework and the Organizational Culture Assessment Instrument (OCAI),
developed by scholars Cameron and Quinn.
Notice that Organizational Climate is distinct from Organizational Culture:
Climate is temporary, Culture enduring.
Please feel free to mention other disciplines I've overlooked or that you'd like to see discussed.
A possible breakdown by topic is:
Broad Overview of Organizational Culture
Meta Process: that is, a process to build a process to effectively change Organizational Culture
Culture variation in different countries
Software Industry Culture
Open Source Software Culture
Perl Monks Culture! :)
Space/Aircraft Industry Culture. As a space nut, I doubt I'll be able to restrain myself from scrutinizing the
impact of organizational culture on the Space Shuttle Challenger
and Columbia disasters.
Again, feel free to suggest other topics you'd like to see discussed.
Please note that I'm just an interested layman on all these topics, so please correct me when I veer off course.
I also welcome your feedback and opinion, along with insights, anecdotes and any useful citations you may know of.
To kick off this series, given that I've just finished reading Sapiens, I thought it'd be fun to speculate on how our early evolutionary history
helps explain some of the peculiar and counter-productive behaviour we witness today.
Around 2.5 million years ago, an unremarkable new species appeared in Africa.
Now, I doubt these early humans, enduring their daily battle for survival along with many other species,
had any inkling back then that they would one day walk on the moon, split the atom, map the genome,
calculate the age of the universe ...
and compose Perl programs, obfus and poetry.
How on earth did this unremarkable and physically weak new species win this brutal evolutionary war?
revealed the (surprising to me) secret:
A green monkey can yell to its comrades, "Careful! A lion!".
But a modern human can tell her friends that this morning, near the bend in the river,
she saw a lion tracking a herd of bison.
She can then describe the exact location, including the different paths leading to the area.
With this information, the members of her band can put their heads together
and discuss whether they should approach the river, chase away the lion, and hunt the bison.
Homo sapiens is primarily a social animal.
Social cooperation is our key for survival and reproduction.
It is not enough for individual men and women to know the whereabouts of lion and bison.
It's much more important for them to know who in their band hates whom, who is sleeping with whom,
who is honest, and who is a cheat.
... The most important information that needed to be conveyed was about humans, not lions and bison.
Our language evolved as a way of gossiping.
Do you think that history professors chat about the reasons for the First World War when they meet for lunch,
or that nuclear physicists spend their coffee breaks at scientific conferences talking about quarks?
Sometimes. But more often, they gossip about the professor who caught her husband cheating,
or the quarrel between the head of the department and the dean, or the rumours that a colleague
used his research funds to buy a Lexus.
Only Homo sapiens can speak about things that don't really exist.
You could never convince a monkey to give you a banana by promising
him limitless bananas after death in monkey heaven.
But why is it so important?
Fiction has enabled us not merely to imagine things, but to do so collectively.
We can weave common myths.
Such myths give Sapiens the unprecedented ability to cooperate flexibly in large numbers.
Ants and bees can also work together in huge numbers, but they do so in a very rigid manner and only with close relatives.
Sapiens can cooperate in extremely flexible ways with countless numbers of strangers.
That's why Sapiens rule the world, whereas ants eat our leftovers and chimps are locked up in zoos.
(Update: so far researchers have failed to locate lawyer bees; bees don't need lawyers because there
is no danger that they might forget or violate the hive constitution).
Myths and fictions accustomed people, nearly from the moment of birth,
to think in certain ways, to behave in accordance with certain standards,
to want certain things, and to observe certain rules.
They thereby created artificial instincts that enabled millions of strangers to cooperate effectively.
This network of artificial instincts is called culture.
The theory of evolution tells us that instincts, drives and emotions
evolve in the sole interest of survival and reproduction
... yet when some of these evolutionary pressures abruptly disappear (due to sudden changes in human culture),
these hard-won instincts
do not instantly disappear with them ...
which explains why today young men drive recklessly and fight in pubs.
They are simply following ancient genetic impulses that, though counter productive today,
made perfect sense 70,000 years ago, where a
young hunter who risked his life chasing a mammoth outshone all his competitors
to win the affections of the local beauty.
Sadly, those same successful macho genes today give us a mouthful on Perl mailing lists, IRC and Twitter.
With their brain growing (to keep track of the thousands of connections, deceits and subterfuge required for superior gossiping)
and their hips narrowing (to facilitate walking upright), evolution favoured early births
... leading to helpless babies ... requiring a tribe to raise them ... favouring those with strong social abilities.
Being born immature and with a big brain further allowed humans to be taught more flexibly than any other species --
which explains why we witness today the appalling spectacle of impressionable youngsters being
effortlessly led to love Python and hate Perl.
Updated: Make Homo sapiens stand out from surrounding text, and with the species name (sapiens) in all lower case, a convention used by biologists, such as erix. 13-June: added bee lawyer joke to quoted Sapiens passage.
I'm old-school, object-oriented programming didn't start to get mainstream until I'd been in the industry 20 years (the roots go back to before my start, of course). And then Perl has a not completely generic approach to objects.
Today I learned, less painfully than I might have, that when I instantiate an object in one program, use Dumper to make it a string, send that to another program, and eval the string, I get an object exactly matching what Dumper saw (I know there are cases where it can't do that, but my situation is simple and that part works). But...the blessed object and the class/package it's associated with don't interlock. So, having forgotten to include that package in the second program, evaling the Dumper string gave me a blessed object (hash, in this case) with all the right members -- but didn't notice that the package was missing, and that therefore all the methods, including accessors, were missing.
I didn't take that long to realize what was wrong, even. It's a cleavage line I don't think exists in most other object environments.
No particular point beyond this; I'm not saying this is bad and must be fixed or anything. It's an extra way to screw up (which I exploited :-) ) made possible by the flexibility of Perl's rather ad-hoc approach to objects. "Meditation" is about right; I'm just thinking about this out loud.
I suppose you could make this a slightly harder mistake, but only by making some low-level changes. If a blessed object kept track of whether it was associated with a package of that name, and the information went into the Dumper output, then when the string was evaled, if there was no package of the right name loaded, it could point that out (optional extra parameter to bless, or something?). Huh; my first thought was that it was going to be hopeless, but maybe there are holes in that idea I haven't noticed yet. I wonder if there is code out there that deliberately uses this somehow?
I often have to update Perl and the CPAN dists i use for my projects on many machines at once. Over time i have to come more and more to realize how much of a drag badly written test suits are. In this post, i'll try to formulate this into a somewhat readable list of things that can be improved.
Make your tests as short and fast as possible
Some dists really seems to drag their feet when it comes to running tests. Do you really need to run a gazillion slow tests on every single computer your dist is installed? This wastes the users time.
For example, do you really need to test if 1+1=2? You can assume that Perl did some extensive tests on the basics during its installation, so you don't have to.
Don't run extensive "timeout" tests unless you absolutely have to.
Make more of your tests Author-only tests
Decide which tests only makes sense for you, the author. Prime examples would be tests that check the documentation or running Perl::Critic. Others might be check if your network protocol handler conforms to the specification. Unless part of your code is specific to the system architecture, these tests only need to be run whenever you change the code.
Don't make assumptions about the users network architecture.
Quite a few dists in CPAN make assumption on how the network setup of a users should behave. Don't assume that the user is even allowed or able to access the internet. For the same reason, don't assume DNS resolution is going to get you the expected results, these days many users and companies run filters on Nameservers.
Don't try to access servers you don't personally own or have explicit permission to use
I've seen tests that run against other peoples (or companies) servers. This is generally frowned up on, you are wasting resources of the server owner and quite possibly their money.
Also, your tests might suddenly start to fail. You don't have control over those servers. If their configuration suddenly changes or they go offline, your users might have problems installing your dist.
Accessing certain sites may also be against company policy or even against the law in the country the user resides. Think "news sites" for example. Accessing news sites during work hours might get the user into trouble. Trying to access these sites might even get the user into legal trouble because they are "banned" in the users country.
Don't ask stupid questions while installing
Quite a few dists hold up the installation process to ask stupid questions. This is very annoying, especially if you run the installation on multiple hosts and once and you have to constantly switch through all tabs of your terminal. Just to check if some installation script has put its lazy feet on the table and won't do anything until you press enter.
Like "should i run the network tests over the internet". Answer: "No, you shouldn't" (see above). Provide some Author-tests instead that the user can run if they run into trouble - and document this in the dists "Troubleshooting" section.
Another good example is Template Toolkit. You get the questions "Do you want to build the XS Stash module?" and "Do you want to use the XS Stash by default?". How the f should i know? You are the author and you should know the answer to that better than me. If the author answer is "i don't know", then try to build the module while catching errors as non-fatal. If the module build, run its tests, if those tests work, use it as default.
Don't keep outdated tests and workarounds for external modules
If your dist uses external modules, and you encounter bugs, you will probably check for those bugs and write a workaround. Say the author of that module has since fixed the bug. Instead of keeping slow workarounds and extensive tests for that outdated module around, just require the current version of that external module as your minimum version.
Don't install if your requirements are not fulfilled.
If your dist needs either ACME::Foo or ACME::Foo::PurePerl installed to function properly, don't just print a message and continue. Either fail the installation (not good) or pick one at development time. In this case, picking the PurePerl version might be more reliable. Just printing a message during installation is pretty useless, especially if your dist is getting installed at the same time as a number of other dists. Your message might be on screen for only a fraction of a second.
Don't make the computer unusable during building and testing (unless you have to).
A good example where this is unavoidable is install Tk. It has to pop up many different windows to test this GUI library, which makes working on the computer while the installation is running impossible due to focus stealing. But if at all possible, avoid this.
Be careful when testing floating point numbers
Different systems might handle floating point numbers in slightly different way. Just because 1.0 + 0.05 = 1.05, this might not be true on the users system. It might only be "1.04999999". That is how floating point numbers work on on computers, because they use binary representations of varying length (precision) to work on those internally.
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
David Plummer, a former MS software engineer with a popular youtube channel, recently posted a video comparing C#/C++/Python performance with a Primes implementation. He uploaded the source code to a github repo and people started adding implementations for many other languages. There's a Perl implementation, although I haven't yet looked whether it can be improved on. I thought I'd post it since I found it interesting and thought somebody might welcome the challenge of making a faster Perl solution (or making a Raku solution).
Today is six months since I created an account here in the Monastery...
Seldom have more than a few days passed without me kicking myself that I didn't do so much, much earlier. I have been writing Perl code since the mid-1990's but have learnt more in the last six months than in most of the time before. I managed to get quite a bit of 'stuff' working, mostly web based but also quite a few client tools. Even a handful of GUI tools using Tk. Over the years I has to do some C++ coding as part of my physics degree which I did not get on with and knew I never wanted to revisit... I've had a couple of brushes with Java including recently to create a couple of simple Android apps. But it has always been Perl that has been the language of choice.
When I needed to do something, I found out just enough to make it work. Then didn't go any further. Why would I? I didn't know there was a better way to do things!
A great example was when I posted some code and suddenly found out about placeholders in database queries...I had vaguely heard about the things but thought they were just for reusing one query multiple times. I soon found out they were a lot more useful than that. So useful in fact that all my code is slowly being converted. Re^5: Splitting the records into multiple worksheets
The Monastery changed all that from almost immediately entering. Straight away I was implored to use strict. Something I knew of but didn't understand. I thought it was a pain and made coding much slower. But I tried using it and, yes, I have to be more careful with my coding but that's no bad thing. Now all my code has use strict at the start. Just today I've refactored a script to include it and had to change 638 lines, mostly adding my to the start!
All my code now uses Template's where appropriate. All thanks to the Monastery. Yes, it was quite a learning curve but has enabled me to refactor an entire website and incorporate AB Testing right into the core. We just create test templates rather than having to duplicate all the code. So much easier to create, test and maintain. Certainly worth the learning curve.
My blind uncle now has automated curtains thanks to Controlling USB on Raspberry Pi which quite possibly would never have been successfully completed without the help of fellow Monks.
Plus, I have published a module on CPAN - Business::Stripe::WebCheckout
Something else that almost certainly would not have happened without the help and encouragement of so many Monks
Thanks for making the last 6 months sch a great period of learning....
Here's to plenty more time. Hopefully, over time I will be able to pass something on to new Monks.
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:
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';
# and now re-bless back to original
bless $cookie_jar => 'HTTP::Cookies';
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.
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.
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
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 :-)
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.
*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.
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.
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?"
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-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.
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.
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-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.
"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."
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.
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
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
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
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
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
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
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
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
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.
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?
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):
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.
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.
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:
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
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.
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
Snippets of code should be wrapped in
<code> tags not<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor