Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number


( #480=superdoc: print w/ replies, xml ) Need Help??

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
RFC: Automatic logger module
2 direct replies — Read more / Contribute
by balajiram
on Mar 23, 2015 at 22:51
    I have written a Perl module that redirects the the output of STDOUT and STDERR to a file very easily. For example:
    use Auto::Log; my $log = new Auto::Log, "some.log"; ...Write some code here... print "INFO: This gets printed to the log file" $log->DESTROY;

    One could also use the log file in tee mode using a simple option.

    I wanted to hear from users as to how they feel about this. What do you think? Do you think you'd like to use such a Perl module?

    The principal use of this module is that all that a user ever needs to do is to use the print, or warn statements. One doesn't have to open a new file using open() or anything. In my opinion this saves effort for a regular programmer who wants to get code written fast.

    Let me know what you think though.

    Also, please do give some suggestions for the module name. Do you like the name 'Auto::Log'?


Perl and the Future
6 direct replies — Read more / Contribute
by hangon
on Mar 19, 2015 at 02:22

    Good evening Monks, I thought I'd try to stimulate some discussion on advocating and passing Perl along to the next generation.

    While Perl is not dead as some advocates of other languages like to point out, it sems to have lost ground in some areas. Web development is one example, when PHP became popular. Another is as a "scripting" interface for other applications. Apparently Python is now the language du jour for that purpose, as well a good number of standalone open source programs.

    I get it that Perl is no longer the "cool" new language, that distinction was taken by Python, then Ruby and possibly Lua will be next. I see an evolution here, where in the public perception these languages go from shiny & new, to mainstream, to old and somewhat unknown or overlooked.

    Today I had an interesting conversation with the technical programs coordinator for the public library system of a mid-sized U.S. city. Among other things, they hold classes on programming for people of all ages. There are visually oriented languages for teaching young children, and they teach Ruby, Python and Javascript to people from early teenagers through older adults. However, she seemed to be unfamiliar with Perl, I don't think she was more than vaguely aware of Perl's existence.

    So, it occurs to me that this may be a good place to advocate Perl. Perhaps experienced Perl programmers could volunteer to teach the language at public libraries or similar venues, where to that audience Perl would be new again. This could be a win-win where you advocate and teach your favorite language, while giving back to your community and the Perl community as well.

Using serialized data structure to change hash key
3 direct replies — Read more / Contribute
by docdurdee
on Mar 18, 2015 at 10:13
    I have on occasion had the need to dig down into a complex data structure to change a key (e.g. s/SOMEKEY/SomeKey/, etc. ). The usual digging approach is using loops. Here is a useful trick using a serialized data structure that has saved me some time here and there:
    use YAML::XS; my $yaml = Dump $hash; $yaml =~ s/SOMEKEY/SomeKey/; $hash = Load $yaml;
    I posted this on Stack Overflow to an old question, but it didn't get many votes. So either it's a bad idea or the question was too old. Anyway, I post it here because I like this trick. Clearly, you should dump the structure and be sure that your replacement won't mess something else up. With power comes responsibility...
Happy PI day!
1 direct reply — Read more / Contribute
by docdurdee
on Mar 14, 2015 at 17:16
    perl -e ' $runs = 10000000 ; do { $x = rand(1); $y = rand(1); $cnt++ i +f $x*$x + $y*$y>1 } foreach (1 .. $runs); print 4*(($runs-$cnt)/$runs +)."\n"'
Perl 5, Python, Rakudo, C/C++, Java, Lua?
6 direct replies — Read more / Contribute
by raiph
on Mar 11, 2015 at 22:44
Why PerlMonks is an amazing place.
4 direct replies — Read more / Contribute
by Anonymous Monk
on Mar 03, 2015 at 01:34


    I know this is not a question, but as an anonymonk, I cannot post it anywhere else, so here goes.

    I was the same guy who asked a question on "Re learning Perl". I even gave a small code snippet I wrote just to show how much I remember. This was pretty late in the night. I woke up half expecting someone to shoo me away at worst, or un answered post at best, because I was not sure how my question would be perceived. To my amazement and satisfaction, not a *single* sullen response!!!. The monks who responded genuinely wanted to guide. They suggested tips and books. Truly, there is no other forum like this. I've been here so many times, asked so many questions, but not even once, I repeat, not even once was I rudely sent back. I've seen much much worse forums, but there is something different here at the Monastery. Whenever someone asks me why I use Perl, I tell them 1) Because this is the only scripting language I know (and like) and 2) that they should visit PerlMonks. It's the most amazing place to come to ask questions and get genuine answers.

    It's also here at PerlMonks that I learnt that it's ok if you do not remember syntax, you can look up the documentation, no one expects you to remember everything by heart. As long as you have the basic fundamentals clear, you can barge ahead, and then fill in the gaps. You monks may not believe it, but there are other places not so forgiving/understanding/helpful.

    I hope the place stays as wonderful as it is right now. Thank you Monks.

Acknowledgement of Contributions
1 direct reply — Read more / Contribute
by jmlynesjr
on Mar 02, 2015 at 14:24


    Unlike most(a lot?) of you, I am retired and I enjoy learning Perl and wxPerl. As such, my time is free, which gives me a great appreciation for the time contributed to the Monastery by those of you who do make your living by doing Perl.

    A few days ago I got a 911 from my daughter who is writing her Doctoral Dissertation in Economics. She needed data on all the power plants in the US. The available data came from the EIA and EPA. As governments are famous for, the plant identifiers between the agencies are different. She ended up with a 10,000 row spreadsheet to normalize.

    I remembered reading posts on working with Excel. A search of the Monastery turned up Excel To Tab Delimited using Spreadsheet::ParseExcel posted by upallnight.

    Within an hour I had installed the module from CPAN and had the sample code running against her data. Several iterations later, I could extract selected columns into a hash to determine the unique plant names and generate a file of edits compatible with Matlab. I still have 700 rows to manually edit, but Perl has already saved us a lot of time.

    Whether you post a complete solution or just a hint, you never know who might can benefit from your knowledge even years after your post.

    Thanks for all of your contributions.

    Update: Fixed typo in title.


    There's never enough time to do it right, but always enough time to do it over...

Porting (old) code to something else
8 direct replies — Read more / Contribute
by Tux
on Feb 16, 2015 at 09:41

    As I am in the process of porting Text::CSV_XS to perl6, I have learned not only a lot about perl6, but also about loose ends.

    We all know by now that perl6 is reasonable likely to be available in September (of this year), and depending on what you hope or expect, you might be delighted, disappointed, disillusioned or ecstatic (or anything in between: YMMV).

    My goal was to be able to present a module working in perl6 that would provide the user with as much functionality possible of what Text::CSV_XS offers: flexible feature-rich safe and fast CSV parsing and generation.

    For now I have to drop the "fast" requirement, but I am convinced that the speed will pick up later.

    Text::CSV_XS currently offers a testsuite with 50171 tests, so my idea was that if I convert the test suite to perl6 syntax, it good very well serve a point of proof for whatever I wrote in perl6.

    There's a few things that you need to know about me and my attitude towards perl6 before you are able to value what has happened (at least I see this as a valueable path, you might not care at all).

    I do not like the new whitespace issues that perl6 imposes on the code. It strikes *me* as ugly and illogical. That is the main reason why I dropped interest in perl6 very early in the process. In Sofia however, I had a conversation (again) with a group of perl6 developers who now proclaimed that they could meet my needs as perl6 now has a thing called "slang", where the syntax rules can be lexically changed. Not only did they tell me it was possible, but early October 2014, Slang::Tuxic was created just for me and low and behold, I could write code in perl6 without the single big annoyance that drove me away in the first place. This is NOT a post to get you to use this slang, it is (amongst other things) merely a reason to show that perl6 is flexible enough to take away annoyences.

    Given that I now can write beautiful perl (against, beauty in the eyes of the beholder), I regained enjoyment again and John and I were so stupid to take the fact that perl6 actually can be used now, to promise to pick a module in the perl5 area and port it to perl5. XS being an extra hurdle, we aimed high and decided to "do" CSV_XS.

    So, I have 50000+ tests that I want to PASS (ideally) but I soon found out that with perl6 having type checking, some tests are useless, as the perl6 compiler already catches those for you. Compare that to use strict in perl5, so I can just delete all tests that pass wrong arguments to the different methods.

    Converting error-dealing stuff was fun too but I think that if you try to mimic what people expect in perl5, it is not too hard to get the best of both worlds: I'm quite happy already with error-handling as it stands.

    So, the real reason for this post is what I found to have no answer to, as it wasn't tested for or had tests that were bogus.

    • What should be done when parsing a single line of data is valid, but there is trailing data in the line after parsing it.?
      $csv->parse (qq{"foo",,bar,1,3.14,""\r\n"more data});
      parse is documented to parse the line and enable you to get the fields with fields. In contrast with getline, which acts on IO, it will just discard all data beyond the EOL sequence. I am uncertain if that is actually what it should do. Should it "keep" the rest for the next iteration? Should it be discarded? Should it cause a warning? Or an error?
    • What is the correct way to deal with single ESCapes (given that Escape is not the default " or otherwise equal to QUOtation). Here I mean ESCape being used on a spot where it is not required or expected without the option to accept them as literal.
      $csv->escape_char ("+"); $csv->parse ("+"); $csv->parse ("+a"); $csv->parse ("+\n");
      Leave the ESCape as is? Drop it, being special? Warn or Error?

    Questions like those slowed down the conversion as a whole, as I can now take my own decisions with sane defaults (like binary => True) instead of caring about backward compatibility issues.

    Anyway, feel free to check out what I have done so far on my git repo and I welcome comments (other than those on style) in the issues section. Feel free to join #csv on IRC to discuss. Hope to see you (or some of you) at the next Dutch Perl Workshop 2015 in Utecht.

    Enjoy, Have FUN! H.Merijn
Good programming practices and changes in requirements: how to maintain good code
7 direct replies — Read more / Contribute
by DanBev
on Feb 11, 2015 at 09:10

    Hi Monks!

    We know software engineering principles and how to write maintainable code, and it's all well and good.
    AFAIK, we should also know that in the real world, with real projects and real requisites, we have to find a middle between software engineering and "make things work".

    I don't want an ideology war, I know what should be better, but IMHO I think - probably I'm wrong- maintain real code in real world, according the engineering principles it's very very hard. Not impossible, but difficult. That's because in real world, requisites changes too fast, and projects are not "so" descriptive: in real world, in real companies, in the control room there aren't always project manager with competences in IT.

    So, you can try to write your perfect code but after release - no beta testing, it's horrible but in real companies can happen-, control room changes requisites and operation, and this must be done for "yesterday", and they changes again and again and again, because they don't know really what they want.
    In order to satisfy "everything at once" you see your almost-well-written-code fall into WTF-code: you can control it almost, but entropy grows.

    How do you manage this situations, what are your experiences about?

In place editing without reading further
2 direct replies — Read more / Contribute
by trippledubs
on Jan 27, 2015 at 14:22

    In transitioning Solaris Sparc sun4u to newer sun4v architecture we found that, sometimes, the image of the old server would not install onto the new server. The image file contains 20-30 text lines describing the system that was imaged and then the image itself. This file is quite large in some cases, takes a long time to create, and is made during an outage.

    The fix, once the image is already made, is quite janky. You need to append the string 'sun4v' into the the field 'content_architectures=' at the 20th or so. The other part is you do not want to read the rest of the file. Someone came up with this and saved the day. What do you think? Was there a better approach? Is there a way to do this using command line arguments that makes sense?

RFC: automating modular classes
1 direct reply — Read more / Contribute
by Arunbear
on Jan 26, 2015 at 08:44

    Minions is yet another OOP automation module, roughly similar to Moo, but which has the addtional goal of putting Encapsulation centre stage. I wrote it because after reading How Large Does Your Project Have To Be to Justify Using Moose? (especially the comments by tye and JavaFan), I became increasingly disillusioned with the Moo(se) way of OOP (essentially OOP with no Encapsulation).

    Here is a sample that implements the fixed size queue from Re^5: The future of Perl? (that sub-thread also illustrates limitations of the Moo way of OOP)
    package FixedSizeQueue; use Minions interface => [qw( push pop size )], construct_with => { max_items => { assert => { positive_int => sub { $_[0] =~ /^\d+$/ && $_[0 +] > 0 } }, }, }, implementation => 'FixedSizeQueue::Default', ; 1; package FixedSizeQueue::Default; use Minions::Implementation has => { q => { default => sub { [ ] } }, max_size => { init_arg => 'max_items', }, }, ; sub size { my ($self) = @_; scalar @{ $self->{$__q} }; } sub push { my ($self, $val) = @_; log_info($self); push @{ $self->{$__q} }, $val; if ($self->size > $self->{$__max_size}) { $self->pop; } } sub pop { my ($self) = @_; log_info($self); shift @{ $self->{$__q} }; } sub log_info { my ($self) = @_; warn sprintf "[%s] I have %d element(s)\n", scalar(localtime), $se +lf->size; } 1;
    And a sample of usage:
    % reply -I lib 0> use FixedSizeQueue 1> my $q = FixedSizeQueue->new(max_items => 3) $res[0] = bless( { '932db126-' => 'FixedSizeQueue::__Private', '932db126-max_size' => 3, '932db126-q' => [] }, 'FixedSizeQueue::__Minions' ) 2> $q->can $res[1] = [ 'pop', 'push', 'size' ] 3> $q->push($_) for 1 .. 3 [Mon Jan 26 12:01:53 2015] I have 0 element(s) [Mon Jan 26 12:01:53 2015] I have 1 element(s) [Mon Jan 26 12:01:53 2015] I have 2 element(s) $res[2] = '' 4> $q->pop [Mon Jan 26 12:02:09 2015] I have 3 element(s) $res[3] = 1 5> $q $res[4] = bless( { '932db126-' => 'FixedSizeQueue::__Private', '932db126-max_size' => 3, '932db126-q' => [ 2, 3 ] }, 'FixedSizeQueue::__Minions' ) 6> $q->push($_) for 4 .. 6 [Mon Jan 26 12:02:55 2015] I have 2 element(s) [Mon Jan 26 12:02:55 2015] I have 3 element(s) [Mon Jan 26 12:02:55 2015] I have 4 element(s) [Mon Jan 26 12:02:55 2015] I have 3 element(s) [Mon Jan 26 12:02:55 2015] I have 4 element(s) $res[5] = '' 7> $q $res[6] = bless( { '932db126-' => 'FixedSizeQueue::__Private', '932db126-max_size' => 3, '932db126-q' => [ 4, 5, 6 ] }, 'FixedSizeQueue::__Minions' ) 8> $q->log_info() Can't locate object method "log_info" via package "FixedSizeQueue::__M +inions" at reply input line 1. 9>
    Not all Moo features are supported (for this early release I've focused on those I actually use). Important differences from Moo include
    1. Attributes can be safely accessed inside classes without the overhead of a function call
    2. As a consequence of 1., attributes need not be exposed via methods (unless there is a good reason to do so).
    3. No need to clean up animal droppings
    4. Private subroutines via the mechanism shown in Re: OO - best way to have protected methods (packages)
    5. Class methods are "class only", and object methods are "object only"
    6. No compatibility with Moose
    Feedback is much appreciated.
The Boy Scout Rule
9 direct replies — Read more / Contribute
by eyepopslikeamosquito
on Jan 25, 2015 at 04:59

    You've got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales.

    On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

    -- The Developer Abstraction Layer by Joel Spolsky

    Though my natural inclination is to be a bit OCD about keeping code clean, I concede that spending too much time and money on refactoring, writing programmer tools, and endlessly polishing code will likely lead to commercial failure. As will the converse, namely neglecting your developers and their code and architectures in favour of sales and marketing. Successful software companies tend to have a healthy balance.

    Refactoring, perhaps the most commercially successful Perl-based company, has caused a bit of controversy over the years with their attitude towards refactoring. To give you a flavour, I present a couple of comments below:

    Booking is destroying my career because I am not allowed to do anything new. I am not allowed to use new technologies. I'm not allowed to "design" anything big. I am not allowed to write tests. I am allowed to copy that 500 line subroutine into another module. If people have done that several times before, maybe it should be refactored instead of duplicated? If you do that, you get in trouble. As one boss says, "we do not pay you to write nice code. We pay you to get job done."

    Management, and the term is quite lose when applied to, sees no gain in refactoring code. By refactoring I'm talking about taking a few weeks to rewrite an existing piece of software. By definition refactoring doesn't bring new functionality so this is why management is reluctant to go down that road. We're quite lenient about code that gets added to the repo, as long as there's a business reason behind it. If a quick hack can be deployed live and increase conversion then it will be accepted. But rest assured that crappy code doesn't last long, specially if other devs have to use it or maintain it.

    -- from Truth about (Blog)

    One of the posts specifically deals with the culture of "get it done and fast" and how they do not encourage refactoring or basic testing. I actually work in a Perl shop where management has the same kind of mentality, and it is slowly killing our efficiency.

    Regarding testing, it's true that we're not very unit testing focused. This is mainly because we've decided to spend most of the time/money/infrastructure that you might usually spend on unit testing on monitoring instead. If you have unit tests you still need monitoring, but in practice if your monitoring is good enough and you have an infrastructure to quickly rollout & rollback systems you can replace much of unit testing with monitoring.

    We're not adverse to refactoring when appropriate. But if you're going to propose rewriting some code here you'll actually have to make a compelling case for it which isn't just "the old code is hairy". Do you actually understand what it does? Maybe it's hairy and complex because it's solving a hairy and complex problem. Are you not aware of where this system fits into the big picture? We've also had code that's looks fantastic, had tests, used lots of best practices that we've had to throw away completely because it was implementing some idea that turned out to be plain stupid.

    -- from What exactly is up with (reddit)

    Opportunistic Refactoring and The Boy Scout Rule

    Some people object to such refactoring as taking time away from working on a valuable feature. But the whole point of refactoring is that it makes the code base easier to work with, thus allowing the team to add value more quickly. If you don't spend time on taking your opportunities to refactor, then the code base gradually degrades and you're faced with slower progress and difficult conversations with sponsors about refactoring iterations.

    There is a genuine danger of going down a rabbit hole here, as you fix one thing you spot another, and another, and before long you're deep in yak hair. Skillful opportunistic refactoring requires good judgement, where you decide when to call it a day. You want to leave the code better than you found it, but it can also wait for another visit to make it the way you'd really like to see it. If you always make things a little better, then repeated applications will make a big impact that's focused on the areas that are frequently visited - which are exactly the areas where clean code is most valuable.

    -- Opportunistic Refactoring (Martin Fowler)

    The Boy Scouts have a rule: "Always leave the campground cleaner than you found it"

    What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out"

    -- The Boy Scout Rule (O'Reilly)

    At work, we perform opportunistic refactoring following the Boy Scout rule, trusting the judgement of developers. How do you do it at your workplace?

    Code Reviews

    By way of background, my company went agile about five years ago, at first with great zealotry, nowadays with more maturity and less dogma.

    Before check-in, all code must be reviewed, either continuously via pair programming, or via a lightweight code review (typically over-the-shoulder). We also have a coding standard, though it is not strongly enforced.

    To give a concrete example, during a code review the other day, I persuaded the author to eliminate unnecessary repetition by changing this snippet:

    my $config = <<'GROK'; ADD UDP_LISTENER ( 515 ) ADD UDP_LISTENER ( 616, 657 ) ADD UDP_LISTENER ( 987 ) GROK my @test_cases = ( { desc => "# Test 1", conf => $config, find => [ 'port = 515', 'port = 616', 'port = 657', 'port = 987' + ], }, );
    my $liststr = 'ADD UDP_LISTENER'; my @ports = ( 515, 616, 657, 987 ); my $config = <<"GROK"; $liststr ( $ports[0] ) $liststr ( $ports[1], $ports[2] ) $liststr ( $ports[3] ) GROK my @test_cases = ( { desc => "# Test 1", conf => $config, find => [ map { "port = $_" } @ports ], }, );

    What would you have done?

    I'm sure some other programmers at my company wouldn't have bothered suggesting any changes at all: after all, the code worked as is, it's pretty clear, plus "it's only a test script", so why bother?

    Though I felt the code was more maintainable with duplication eliminated, I had another motivation in this specific case: training. You see, the programmer in question was very new to Perl and, as I found out during the review, had never used map before! Training (and improved teamwork) are important benefits of code reviews.

    Eliminating unnecessary duplication and repetition is a common discussion topic during code review in my experience. (Note: I did not include this example to argue further about what DRY means exactly in Room 12A :). Other common discussion points during code review are:

    • Commenting.
    • Naming.
    • Clarity vs Cleverness.
    • Encapsulation.
    • Interfaces.
    • Error handling.
    • Testability. Is the code testable in isolation?
    • Supportability.
    • Portability.
    • Security.
    • Performance.
    Note that we do not normally discuss code layout because all code is pushed through Perl::Tidy before review.

    I'm interested to learn about your workplace experiences. In particular:

    • Do you have a coding standard? How is it enforced?
    • Do you do pair programming?
    • Do you do code reviews? Are they heavyweight (e.g. Fagan Inspection) or lightweight (e.g. over-the-shoulder)? Mandatory or optional?
    • What are common discussion points during your code reviews?


    To finish, here's another one, derived from Clever vs. Readable.

    Would this statement pass your code review?

    my $value = [ $x => $y ] -> [ $y <= $x ];
    If not, would you suggest changing it to:
    my $value = $x < $y ? $x : $y;
    use List::Util qw(min); my $value = min( $x, $y );
    Or something else?


Empty string but True
1 direct reply — Read more / Contribute
by Yary
on Jan 22, 2015 at 11:30
    I was looking at an old StackOverflow question about generating an explicit null XML namespace and had the thought, "maybe an object that stringifies to the empty string, but is true in every other context, will trick LibXML into doing what the seeker of wisdom required."

    It did not, nor did an earlier attempt using than Scalar::Util's dualvar. Still I liked my little Empty but True module enough to post it here. (Seems too useless/dangerous/not worth the bother to be on CPAN.)

    package MyEmptyTrueVar; our $singleton; use overload fallback => 'TRUE', '""' => sub { "" }, # Return empty string on stringification bool => sub { 1 }, # Return true in boolean context '0+' => sub { 1 }, # Return true in numeric context cmp => sub { !ref $_[1] }; # unequal to empty string, or any other +string bless $singleton=\$singleton;
    say "Single str='$MyEmptyTrueVar::singleton', Num=", (0+$MyEmptyTrueVa +r::singleton) if $MyEmptyTrueVar::singleton && $MyEmptyTrueVar::singleton ne '' && '' ne $MyEmptyTrueVar::singleton;
    shows that Single str='', Num=1.
quickness is not so obvious
3 direct replies — Read more / Contribute
by DanBev
on Jan 22, 2015 at 04:00

    Computers can do so many operations per second, so fast, that sometimes are considered omnipotent. But, sometimes an approach a little too direct or dumb can transform our fastest machine in a cart ...

    This is not the discovery of the century, I know, and every good programmer pays attention to the issue, but sometimes I stop to think how is easy to turn a good-performing program in a disaster.

    Just yesterday, I had to check about 10,000 files in a directory from a database of about 20,000 records: the iterating solution a-query-by-file it take an hour; by loading the entire table in a hash and then looking information it take few seconds.
    So far, not the sense of life, but a thing on which I like to meditate.

What 'should' a professional PERL programmer know?
7 direct replies — Read more / Contribute
by perloHolic()
on Jan 09, 2015 at 07:08

    Hello fellow monks and monkesses.

    I am very new to the monastary as far as being a member goes, however have been a frequent part of the 'flock' if you like, for some time.

    My meditation today comes from my recent personal experience of applying for a proffessional role as a PERL programmer - which leads to my pondering, 'what do i have to know/should know in order to be qualified for such a position'? I have read many articles before such as Professional perl which are obviously inciteful in this area.

    I am really looking for specifics such as a minimum amount of required knowledge in certain areas such as OO Perl, or Database management with Perl, Optimisation, Threads or Web programming in Perl etc. I have only self tought knowledge of PERL, and of course with helpful textbooks, tutorials and articles in the monastary have grown this knowledge over time. I don't however, have any professional experience of PERL per say, other than small scripts I have written for my current job as a C language software Engineer.

    SO - I do have a relatively small amount of knowledge in some areas in comparison to, lets say, what I would class as the contrastingly very experienced monks around here, whom provide a vast array of knowledge in most if not all 'Areas' of PERL. I have yet to receive any feedback from my recent application, however 'I' feel like I may be underqualified. It would be very helpful if my fellow peers may be able to offer some incite into 'what the minimum requirements' may be for such a junior PERL programmer role.

    Apologies in advance if my question is unhelpful,in the wrong place, poorly titled or worded.

    Your ever faithfull functioning perloHolic.

Add your 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!
  • 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
  • Outside of code tags, you may need to use entities for some characters:
            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.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others perusing the Monastery: (7)
    As of 2015-05-24 11:27 GMT
    Find Nodes?
      Voting Booth?

      In my home, the TV remote control is ...

      Results (472 votes), past polls