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").
I've seen that Perl likes operators and have plenty. I was amazed after I saw new in 5.22 (Bitwise String Operators).
And I remember that usually I use to write '$max < $c and $max = $c;' (if not using List::Util qw( max )), which is self repeating. And my idea was to somehow shorten such statements. Here I suggest an operator which shortens previous statement, e.g. these two code would be equivalent: '$max < $c && ( $max = $c );' === '$max <&&= $c;'. New operator '<&&=', with other similar variants: '>&&=', '<=&&=', '>=&&=', and 4 more with '||' in the middle, although they are redundant. Associativity could be the same as of other assignment operators. Another construct suggestion for same operations, would be this: '(comparison_op.)=', which means, that any comparison op can be written inside parentheses, and it corresponds to: '$max comparison_op. $c and $max = $c;'. Isn't this bad idea?
I was reading a post about the future of Perl. I don't know if it is the most appropriate place to provide this feedback.
I've seen the statistics in TIOBE on how Perl is loosing places in the rank of the most performed languages. I freshly finished my IT studies and i discovered Perl language now in my company.
I wanted to raise the fact that the rank of the language doesn't matter at all. The most important thing is the maintain activity.
Why ? Because by default , Perl is a more powerful language ( not only according to me ) than Python or Ruby or others. Perl is not so friendly let's say or common but Perl is doing the job better, because the Perl community is actively "better" and because the language has in his own genetic heritage the basis to be essential.
The black dot is coming of lobbying which is not serving Perl interest. And how the language is taught at school.
As we are in a monastery, i would like to suggest this precept: If someone need to go somewhere he will need oxygen. Perl is like oxygen ( in the air ) and there is only one thing to do , making this oxygen available ( meaning having a strong Perl community ).
And another black dot and not the least: the availability of Perl in growning country. I had discussion with some foreigners, IT engineers and software developers. As suprising as it might seem, some of them don't even know what is Perl language !!
It could be difficult to teach Perl in Universities in Western countries from a political point of view due to these lobbies and pressures but it could be different in growning countries. It's important to make partnerships with them ( with their Univeristies and so on..)
A good idea ,maybe, would be to organize the Perl conference or any big related Perl event in one of these countries.
Thanks for reading and the sorry for the spam. I wanted to share my feeling
Why are so many contenders to the throne of Perl
nothing but a cheap copy of Perl 4?
PHP, Python, Ruby, Javascript all start by copying Perl's
worst practices, according to computer scientists, to
become immensely popular, with no strict and globals
everywhere.
But the fun never lasts because they eventually succumb
to aspersions of computer scientists to add all sorts
of cruft to enforce austerities that satisfy obsessively
compartmentalized minds.
I think the reason is this: Languages like Perl force computers
to think like people, rather than forcing people to think
like computers.
Don't get me wrong, we need the scientists to build and
maintain the playgound so we can play, but we also need
them to get the heck out of our way, and to stay away!
Hard Fork Perl with a trendy cool name and make sure the
batteries are included by throwing in a kitchen sink of
about 1000 of the most awesome CPAN modules in a way that
will do everything and run everywhere and you may
have (another) winner.
When did all the talk of Perl5 dying out begin? It must have been 15 years ago when Python arrived on the scene. Yet.... here we are, still the place of last resort where programmers come because their multi-gigabyte Microsoft Programming Pack didn't have a ready made simple solution. Perl5, was, and still is, the best swiss army knife of the programming world.
What prompted me to write this, is an article in the Perl Newsletter on how simple Perl makes it to connect to UPS and get tracking information. Not only does he solve the socket connection, he color codes the output for a better man-machine interface. terminal colors to cnvey information. Its articles like this, and further, that Perl5 has the ability to do that, is the reason Perl5 will never die! :-)
I'm proposing we try out the Five Whys process at work.
The primary goal is to determine the root cause of a problem by repeating the question "Why?".
Each answer forms the basis of the next question.
The "Five" should not be taken literally, keep asking why until you uncover the root cause.
The method provides no hard and fast rules about what lines of questions to explore, or how long to continue the search for additional root causes.
Even when the method is closely followed, the outcome still depends upon the knowledge and persistence of the people involved.
It's important to note that the purpose of Five Whys isn't to place blame, but to uncover the root cause of the problem.
To create small, incremental steps so that the same issue doesn't happen again.
Our bias as developers is to over-focus on the technical part of the problem;
Five Whys tends to counteract that tendency.
What started as a technical problem often turns out to be a human and process problem.
Sometimes a solution may cut across several departments ... requiring the support of someone with authority to change process at that level.
I'd like to learn from your experiences with Five Whys.
Has Five Whys been tried in the Perl or Open Source world? (for example, on the Perl 6 project).
Have you tried it at work?
How did it go? What did you learn?
Proposed Five Whys Process
As advised by Eric Ries (see References below), at least for a trial period, all Five Whys meetings will be run in the same way, by the same "Five Whys Master".
We'll continuously adapt our use of Five Whys, based on our experiences.
Note that Five Whys is a technique for continuous improvement, and can therefore be applied to itself.
Loosely based on Ries' advice, this is the proposed Five Whys process:
Get everyone who was involved in the problem in a room together.
It's not a crisis, it's a learning opportunity; not to assign blame, but uncover the root cause.
Agree on a statement of the problem; express the problem statement as a question.
Hold a brainstorming session in which "Why?" is repeatedly asked to find the root causes. The Five Whys Master may employ a Fishbone diagram (see next section).
Look for causes step by step. Don't jump to conclusions.
Screen your causes by asking two questions: How likely is this cause to be the major source of the issue? V-Very Likely, S-Somewhat Likely, N-Not Likely; How easy would it be to fix or control? V-Very Easy, S-Somewhat Easy, N-Not Easy. Put the answers to the two questions together, e.g. SV.
For each root cause, try asking "how" five times until the best solution is found ("Five hows").
Commit to make a proportional investment in corrective action at every level of the analysis.
These small investments cause the team to go faster over time. Proportional means not to over-react to problems; a ground-up rewrite is not always required.
Though the Five Whys Master leads the discussion, others assign responsibility for the solution to anyone in the room.
The analysis should propose solutions, aka corrective actions. For each solution, ask "how will this solution prevent the error from occurring again?".
Each corrective action is marked as must (mandatory), should (strongly recommended), or may (use discretion, depending on time and resources);
periodically after the analysis is published, track which corrective actions have actually been implemented (this metric will be used to tune our Five Whys process).
The results of the Five Whys analysis is shared with the whole company. The solution is in plain English that anyone can understand.
Each Five Whys analysis is a teaching document.
Fishbone (aka Ishikawa) diagram
There may be many opinions of root cause.
The fishbone visually displays many potential causes for a specific problem. Because people by nature often like to get right to determining what to do about a problem,
the fishbone can help bring out a more thorough exploration of the issues behind the problem - which leads to a more robust solution.
To construct a fishbone, start with stating the problem in the form of a question. Each root cause idea should answer the question.
The rest of the fishbone consists of one line drawn across the page, attached to the problem statement, and several lines, or "bones", coming out vertically from the main line.
These branches are labeled with different categories; the categories are up to you to decide, for example:
Four Ps (Policies, Procedures, People, Plant/Technology); Six Ms (Machines, Methods, Materials, Measurements, MotherNature, Manpower).
The team should agree on the statement of the problem and then place this question in a box at the head of the fishbone.
The defect is shown as the fish's head, facing to the right, with the causes extending to the left as fishbones; the ribs branch off the backbone for major causes, with sub-branches for root-causes, to as many levels as required.
One or two of these "causes" will have a greater effect than the others and will guide you to the root of the problem.
This structure allows you to tackle smaller chunks which have a large impact on the problem.
Looking at elements of the problem and not the whole process will likely make finding your solution less daunting and problem solving more manageable.
Screen your causes as described above. Focus on causes with result VV, VS and SV.
Typical Software Problem Categories
I couldn't find much specific advice on applying Five Whys to software problems -
if you know of good references, please let me know.
Examples of typical software problems can be found at: Common Software Development Mistakes.
As for categories of typical software problems, perhaps:
People
Process (e.g. Agile, Build system)
Measurement (e.g. Estimation, Measuring rate of progress)
Five Whys by Eric Ries (start with a single person as the "five whys master", email whole company with results of analysis, common question: why didn't automated test catch a bug?)
Five Whys Process (not to assign blame but uncover the root cause. 1 invite all affected, 2. select a leader, 3. ask why five times, 4. assign responsibilities for solutions, 5. email the team the results)
Seven Basic Tools of Quality (fishbone, checksheet, control chart, histogram, pareto chart, scatter diagram, stratification)
You know that feeling, when the big program you've been working on approaches completion, and you're scanning for those invisible bugs the others will find when running your code. That's when I saw something like this somewhere between lines 6000 and 7000:
my $one = 1;
my $six =
my $nine = 9;
print $six; # prints 9
I didn't know you could chain lexical declarations like that! The bug survived for months because $nine was 0 and $six was supposed to be an empty string. Playing around with it reveals more questionable behavior:
#!/usr/bin/perl -l
use strict;
use warnings;
use diagnostics;
print my $J = my $A = my $P = my $H =
'Just',' Another ','Perl',' Hacker';
"But seriously, many computer scientists have fallen into the
trap of trying to define languages like George Orwell’s
Newspeak, in which it is impossible to think bad thoughts.
What they end up doing is killing the creativity of
programming.
A more insidious trap, promulgated in many places these
days (including the most recent Discover magazine), is
that a computer program should be beautiful. Let me tell
you that when it comes to computer languages, this is
totally bogus. If you want to do beautiful art, you don’t
go out and buy a beautiful canvas, and a beautiful brush,
and a beautiful palette, and slather beautiful paints on
it. If you want to write beautiful poetry, this doesn’t
happen because you started with a beautiful language.
Languages are an artistic medium. I don’t want Perl to
be beautiful–I want you to write beautiful programs in
Perl.
Finally, I believe that any language essentially should
be out of control, because no one person or institution
is capable of controlling a language (or a culture, for
that matter) without destroying it. Living languages are
always a cooperative effort, and I want Perl to be a
living language."
Hello Perl Experts. I have some generally useful Perl XS modules which I developed on the Mac OS platform. This work was originally used for my private consulting practice in the printing industry. Last March, my partner and I presented a technical paper about a technique we developed for calibrating printing devices. Now, we're getting requests for the apps and modules from potential users running Windows.
This code is generally useful because it accesses the BLAS and LAPACK libraries of the Accelerate framework, which are the basis for MATLAB. This brings some serious computing power to Perl, without the overhead and complexity of PDL.
I've gotten the non-XS modules to work on Strawberry Perl, but have no idea how to get the XS modules compiled. I'd really appreciate some help with this. Thanks
I've been wanting to write a meditation on encodings or Path::Tiny, but I always seemed to come up with a substantive perl question, which is more the purview of Seekers of Perl Wisdom. A confluence of events makes me interested in the word "bork." I had believed it to be an american english word, a verb that had been called into being in the 80's, and surprised to read marto describe File::Slurp as "borked." I think he took it at as a synonym for "kaputt," "busted," "broken," "f*****." I thought, gosh, that's a different meaning than the one I use it for.
Imagine my surprise as I'm surveying the cpan material for Lingua, and I see Lingua::Bork 'bork'. At first I thought it was a joke, then a con, but then I realized it was a function that rendered text in the idiom of the swedish chef from the muppets show. The assignment is explained in this pdf.
What makes this timely is the etymology of the american verb. Wiki included the meaning I remember, when some feminist said of Clarence Thomas, "we're going to bork him." This declaration was widely broadcasted and galvanized conservatives. This verbing supplanted an earlier passive verb "borking," where Bork would substitute his opinion for precedent.
What brings this all into focus is that Robert Bork was voted down by the US senate, replaced by Anthony Kennedy, who retired recently, and now we have all the same forces arrayed against each other again. It will be the best of times, the worst of times, and the end of life as we know it, if you can stand to watch tv. Mormon Methusalah Orrin Hatch will say the same things. If Kavanaugh isn't confirmed, we'll get someone else who thinks that speech is money, corporations are people, and that women cannot be trusted to make decisions about their bodies.
One thing I like to do when the parade of Not Normal is blaring at high volume is perl. I won't worry about the russia probe because I've got other russian stuff to do. I can't change institutions or states, but I can change the scripts I work with. I can make them more useful, gain a competitive edge. Many times I run an example of someone else's code, leave it sitting for a while, then come back to it when need for it arises.
Other times, perl is for distraction, education or entertainment, and it is in this vein that I introduce 1.bork.pl:
#!/usr/bin/perl -w
use 5.011;
use utf8;
binmode STDOUT, ":encoding(UTF-8)";
use Lingua::StopWords qw( getStopWords );
my $stopwords = getStopWords('en');
use Lingua::Bork 'bork';
say bork("This is the conjunction junction.");
my $sentence = "Many think this judge's nomination will lead to a rest
+riction on abortion.";
my @words = split / /, $sentence;
my $stop = join ' ', grep { !$stopwords->{$_} } @words;
say $stop;
say bork($stop);
__END__
Guys I am in the process of mininmizing the amount of stuff I have. While going trough my stuff, I have found some old issues of the "$foo - Perl Magazin" I'd like to give away if somebody is interested. Otherwise they go to the recycling.
Issues: 3/2007, 4/2007, Summer 2007, 1/2008, 2/2008, 4/2008
holli
You can lead your users to water, but alas, you cannot drown them.
