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").
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
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.
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?
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
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...
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:
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.
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:
"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.
Perl's default sort algorithm is mergesort (perlsec: Algorithmic Complexity Attacks) from 5.8.0 version (Although there may be some optimizations or different behavior if an array length is less than 18? e.g. RFC: Simple switches for 'sort' and list 'reverse').
How does it work? Sort subroutine ignores values of both elements of a pair to compare, i.e. we don't use bindings: nor $a neither $b. Just a constant and rand() function. Here rand() produces some number from an interval 0 to 1 and compares it to a constant (i.e. 0.5). And the "spaceship" operator returns either -1, either 1 (hence with 0.5 probability). Then sort, depending on subroutine's value, changes positions of elements of a pair.
How the results obtained with this sort subroutine differ from uniformly shuffled array, e.g. Fisher-Yates shuffle?
Hi Monks, is anyone interested in old Perl Journal and Perl Review magazines? I will be moving and don't want to move these, again. I think I have a complete set of both:
The Perl Journal: 22 issues, spring 1996 through fall 2001
The Perl Review: 18 issues, winter 2004 through spring 2009
I would rather give these away than throw them in the recycle bin. I'd prefer to give them to someone who will take one or both complete sets but if there is nobody interested in that I will send individual issues. If you will take a complete set I will ship them to anywhere in the US, free to a good home. Outside the US, let's talk :) .
Upd. I slightly changed a node name and rewrote a section about reverse (older text is under strikethrough and moved to the end of the post).
Rarely we want to do something the same with both: with original and reversed list, or with original and sorted (and sorted backwards) list. Here you will find few examples how to use a simple switch to turn ON/OFF sorting or reversing list.
sort: Say we want to apply some function on original, sorted, and sorted backwards list. Example program:
I suspect a lot of abuse of config files comes from moving logic out of source code for bad reasons. There are good reasons for not hard-coding, say, ports and service endpoints in your source code, because it makes it easier to run the code in different environments. However, there are also bad reasons for taking things out of code. A couple that I have encountered:
Pride in creating a "generic" system that can be configured to do all kinds of new things "without touching the code." Reality check: only one or two programmers understand how to modify the config file, and changes have to go through the same life cycle as a code change, so you haven't gained anything. You've only made it harder to onboard new programmers to the project.
Hope that if certain logic is encoded in config files, then it can never get complicated. Reality check: product requirements do not magically become simpler because of your implementation decisions. The config file will become as expressive as necessary to fulfill the requirements, and the code to translate the config file into runtime behavior will become much more complex than if you had coded the logic directly.
Hope that you can get non-programmers to code review your business logic. Reality check: the DSL you embedded in your config file isn't as "human readable" as you think it is. Also, they're not going to sign up for a Github account and learn how to review a PR so they can do your job for you.
Marketing your product as a "no code" solution. Reality check: none for you; this is great! Your customers, on the other hand, are going to find out that "no code" means "coding in something that was never meant to be a programming language."
So I decided to make a new release. Features - you can:
make it behave just like 0.12 with argument "s" to import: perl -d:Trace=s scriptfile
limit trace to namespaces: perl -d:Trace=Foo::Bar,Baz,Quux scriptfile
You have to add "main" also to trace scriptfile
limit trace to subroutines: perl -d:Trace=Foo=sub1:someothersub scriptfile
limit trace by line numbers and number ranges: perl -d:Trace=20-42:123..321,Foo=17-21
This limits trace in "main" to lines 20 through 42 and 123 through 321 (you may use "-" and ".." for ranges) and to lines 17 through 21 in package Foo
trace the codepath stemming from limited traced lines: perl -d:Trace=20..42+:123-321
Lines 123 - 321 are traced in main but not calls, whereas the entire codepath in lines 20 - 42 is followed
exclude packages from trace in the open codepath: perl -d:Trace=42-127+:somesub,Net::LDAP=0
Codepath in lines 42 - 127 is followed as well as calls to "somesub" in main, excluding code in Net::LDAP
provide other filehandles to trace to (which comprises tracing to a variable) by assigning an open filehandle to Devel::Trace::FH
provide an alternative format for trace output by assinging a sprintf format to Devel::Trace::FORMAT
use a formatting function by assigning a function reference to Devel::Trace::FORMAT
An ugly example is shown below
Now it is possible to narrow down tracing to just the interesting parts of a program without touching the source. It is not fully tested and possibly has bugs. I'd be happy if you'd like to play with it and comment. Bug reports, critics, suggestions for improvement, code review etc are most welcome. Have fun!