http://qs1969.pair.com?node_id=1188013

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Respected Monks,

I've been trying to re learn perl after a long hiatus. Things seem to move along slowly. I'm at a point where I am not quite sure if it's even possible for me to continue with learning as my learning speed is considerably slow.

While using a hash is a preferred way to remove duplicate values, I wanted to play around with perl trying to see if it could be done without using a hash. This is what I came up with.

$ more rem_duplicates.pl use warnings; use strict; my @arr = (29,24,0,24,24,12,0,10,10,19,17,15,13,1,12,12,24); sub del_duplicate { my @sortit = sort{$a <=> $b} @_; my @unique; foreach my $index (0..$#sortit) { --$index; my $current = $sortit[$index]; my $next = $sortit[++$index]; if ($current == $next) { $current = undef; } else { push @unique, $current; } next if $current = undef; } @unique = sort {$a <=> $b} @unique; print "@unique\n"; } &del_duplicate(@arr);

And it seems to work fine.

$ perl rem_duplicates.pl 0 1 10 12 13 15 17 19 24 29 $

My problems are:

1) It took me about 3-4 hours to write this, that too, I had to re re re edit the code several times. Never wrote it in one fell swoop. I did take breaks in between to do some weekend chores though. Oddly enough, the $current = undef came in my mind when I was doing some mundane chore. I had earlier added the next if $current = undef; line just above the  if loop, but then, after about 5 minutes of thinking, I added it where it is right now and it seemed to work. I didn't write this nicely, meaning step by step, just kept changing the code, checking the output, then adding a print command to do some debugging, then changing again...and so on.

2) I had tried the same thing about a week or two ago, still it took me long time to write it. Also the code I wrote today is not identical to what I wrote a week or two ago.

I am not a developer by profession or by vocation. Some folks watch TV, some play games, I solve puzzles and/or play with Perl. Hope is someday, I will be able to write some good Perl code and become a good perl programmer.

But I am totally pissed with my lack of speed, I cannot write stuff in one fell swoop (meaning at one go), I keep re editing stuff many times.

Does this happen with you guys too? Were you too slow and made lots of mistakes as beginners? Or should I take this as a sign that, perhaps, my goal of becoming a good perl programmer is a mere mirage and I should better invest time somewhere else? Your guidance will really be helpful.

Replies are listed 'Best First'.
Re: Trudging along the learning perl path.
by zentara (Archbishop) on Apr 15, 2017 at 22:38 UTC
    Hi, I'm just like you, and have been hacking at Perl code for 20 years as a hobby. The only code that effortlessly flows off of my keyboard is
    #/usr/bin/perl use warnings; use strict;
    after that, I'm consulting a library of my past code, good snippets which I have saved, or searching google for code examples. An esteemed monk here has a sig which reads "90% of all code has already been written", the secret is to find an existing code template for what you are trying to do. After you get some experience, a well-worded google search will almost always give you some usuable code to get started, the talent is in knowing the vocabulary of the language well enough to launch a precise search for your intended purpose.

    Also when you see a good snippet, or write something yourself, save it in a personal code library so that when you need a script template, some time down the road, you just pull it out of your existing library. After 20 years, my Perl snippet collection is around 10 gig's !! It pays to have your collection in a set of useful subdirectories, like "file operations", "ascii hex", IPC, Tk, Gtk2, cgi, etc, etc, etc.

    Don't worry, you are normal. :-)


    I'm not really a human, but I play one on earth. ..... an animated JAPH
Re: Trudging along the learning perl path. -- wrong path? :=)
by Discipulus (Canon) on Apr 15, 2017 at 20:33 UTC
    welcome AnonymousMonk,

    First of all it is a good thing you want to learn experiencing but, BUT! trying to do something without using the simpler, acclaimed way (an hash for uniqueness) maybe is not so good idea, worst if you are beginning. The satandard way is a FAQ infact (infaq?)

    Anyway it is possible for example using the smart match operator (it is sperimental) which syntax is ~~ see Smartmatch-Operator and act, in the form $scalar ~~ @array like if array contains scalar

    my @arr = (0,1,2,3,1,2); my @uniq; foreach (sort{$a<=>$b} @arr){ unless($_ ~~ @uniq){push @uniq, $_} } print join ' ', @uniq;

    This is very similar to another existing builtin tool any from List::Util (update: fixed from Utils to Util) core module:

    use List::Util qw(any); my @arr = (0,1,2,3,1,2); my @uniq; foreach my $it (sort{$a<=>$b} @arr){ unless(any{$_ == $it}@uniq){push @uniq, $it} } print join ' ', @uniq;

    I say this because it is very important and crucial to know which Perl tool to use for a task: this can save hours of your precious time: get the habit to read across perldoc to know everyday more: functions tutorials, core modules.. perldoc save your day!

    Then, instead of start spending several hours trying to get uniqness without using an hash it will be by far better to read some good manual like ModernPerl.pdf the free book, or to get a copy if the even old PerlCookbook (a must have to get a wide panorama of solutions and fields to play with).

    I say this because me too i'm somehow a Perl-just-for-fun (I use at work too but when conceiled and i just show perl result and benefits when i've done).

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      Hi Disciplus

      So can I safely assume that the good Perl developers use these modules and these are not training wheels for new learners? Meaning professional Perl guys too use modules and they rarely roll their own stuff (unless needed)?

        So can I safely assume that the good Perl developers use these modules and these are not training wheels for new learners? Meaning professional Perl guys too use modules and they rarely roll their own stuff (unless needed)?

        Yes, of course, if they remember that they exist, while solving a problem. For a good programmer, pulling unique values out of an array is an easy thing, and it is written quickly. If it is a small bit in the overall task, they just write it inline, and done. But if it is to be done all over the place, and/or the program deals extensively with lists, they will pull in List::Util for sure, instead of writing subroutines already written.

        Good programmers know when to use a module; and good programmers also understand the modules they are using. They use modules, because they are lazy and won't solve things already solved; because they are impatient and want to see their job done, so they just include things already done; and because doing that, their hubris can unfold making just their own code bullet proof - because the modules they include are tested elswhere, and they avoid the technical debt of maintaining, testing and improving stuff written by somebody else: it is somebody elses burden.

        Of course, paraphrasing Fred Allen, "CPAN is a medium because anything well done is rare" - there surely are lousy modules on CPAN, but many gems. To tell them apart, you need expertise, and you get that by experience, which besides trial and error and reading documentation means learning from others. So, yes, modules are also training wheels for new learners, and I recommend reading their source code. If after reading you frown upon them, or feel enlightened, that's a good sign; but beware: you might frown for the wrong reason, or have been enlightened by false lights.

        update: s/List::Utils/List::Util/ - thanks Discipulus

        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
        Hello again,

        While i'm not a professional perl developer, but i bet yes; i saw them.

        Then, have you seen my signature? ;=)

        But look from another perspective: having or well using a module is a little price you pay, generally. If you use core modules, which every perl incarnation has ( http://perldoc.perl.org/index-modules-A.html ), the way is super plain: they are, for sure, better implemented than my or your code, they are tested a lot, they will remains stable during ages..

        Normally a well desinged module push in just the code you want like in use List::Util qw(any); so you pay quite nothing.

        CPAN is full, leterally, of useful modules too; here is preferable to choose carefully a well developped module, a famous and widely tested, or be able to understand what it is really doing: the risk to indroduce something unxepcted is present; with core modules is rare (by experience if i find something wrong with perl itself and it's core module i start looking for what i misunderstood about..).

        Experimental features are by other hand to avoid unless playing with the language to learn.

        I smiled the last time i was called Disci+ anyway; Discipulus is ancient latin word meaning pupil or student ;=)

        PS: another good way to learn is creating an account on perlmonks.org asking and observing questions from others and their replies

        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
        "Meaning professional Perl guys too use modules and they rarely roll their own stuff (unless needed)?"

        I'm not officially a professional Perl guy, but I promise you, the best of the best use what is already available, as long as it has a good test suite, an extremely high test pass rate, along with very good documentation and even better if the distribution's author is reachable for questions and feedback.

        Regarding the "rarely roll their own stuff", that's not just "unless needed". I have written distributions on the CPAN not because I needed it, and not because there are already duplicates, but because I needed/wanted to expand my knowledge on a specific area, and at the time, I had a need for a module that would allow me to gain that experience while writing something that was already written.

        Not all of my duplicate efforts have made it to the CPAN, but many have. There's nothing wrong with that, it's just a different way to achieve the same goal. I typically note the other modules that do the same thing in my documentation, and in some cases I've had authors of the similar distributions contact me to discuss my own approach. Re-writing something isn't always a waste of time is what I'm saying here.

        I'm not necessarily for re-creating the wheel, so when it comes to the basics and re-learning, knowing completely how to integrate other modules into your code and use other APIs are just as important as being able to do a print "hello, world!\n"; imho.

        Just as important however, is understanding and fluently using the common idioms, as some things just aren't worth trying to re-work/reproduce and there are better things to re-invent for learning purposes.

Re: Trudging along the learning perl path.
by eyepopslikeamosquito (Archbishop) on Apr 15, 2017 at 23:19 UTC

    I've been trying to re learn perl after a long hiatus. Things seem to move along slowly. I'm at a point where I am not quite sure if it's even possible for me to continue with learning as my learning speed is considerably slow.

    You're doing it wrong. You just need to go out and buy the book "Learning Perl in 24 Hours, Unleashed, in a Nutshell, for Dummies" and all your problems will be solved. :)

    Seriously, as convincingly argued in Peter Norvig's classic essay Teach Yourself Programming in Ten Years, there are no shortcuts:

    Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.
    There are many other useful tips in Norvig's essay, such as: make it fun; learn by doing; talk to other programmers, read other programs; work on projects with other programmers; be involved in understanding a program written by someone else; learn at least half a dozen programming languages; and many more.

    If you have the passion and the ability, the results will come. Be patient. And good luck in your journey.

    BTW, in case they are of interest, I keep a list of similar questions.

Re: Trudging along the learning perl path.
by huck (Prior) on Apr 16, 2017 at 01:04 UTC

    I'm at a point where I am not quite sure if it's even possible for me to continue with learning as my learning speed is considerably slow.

    You can continue learning "as long as you keep putting one foot forward at a time". Just because it seems slower does not mean it has stopped.

    Also the code I wrote today is not identical to what I wrote a week or two ago.

    I think you will find this true for many of us. That is what makes programming an art. (even if that art is art evans). There is both a technical and expressive side to programming anything, perl is no exception. This is one reason to write it over and over a few times, then you recognize the core of that piece of art, and can produce a module or subroutine or tool out of it. What you will find is that by the 5th or 6th time you realize they are all beginning to look the same.

    Just as there is both science and art in the task, the science side has many facets. I studied "compSci" and found it very useful. First was being taught "tricks", the slight of hand manipulations that tighten programs up. Second was learning methods of thinking. One of the best books for the first actually is The Art of Computer Programming. There are many others, some more perl or c related but they are about algorithms so the language doesnt really matter. Since my formal "learnen" i have found that looking at other peoples code can be just as good. There are perl cookbooks and tutorials that can guide you just as well. I have also found the discussions here to show many of the tricks of the trade, same for other places like stackoverflow

    In regards to methods of thinking you will come to realize that the way you debug best is not the same thinking mode you are in when you are designing a process. And when doing the coding you need to think in a whole different way. Learning how to switch between them when you need to is important. Dont drift off to design issues when you are trying to get it working, dont dwell on the implementation as you layout the design. Learn to wear one hat at a time, but also how to change them when you need to.

    Wanting to do this yourself is impressive. Realizing a working model is gratifying. Just dont forget that its probably been done before too, and better, Written about in books from the 60's even. Then go out and do it yourself for some other task, get it done again, and feel good that you did.

    Were you too slow and made lots of mistakes as beginners?

    No of course not, im still too slow and make lots of mistakes, and its hard to consider me still a beginner. What has changed tho is the timing of the cycle. No longer do i have to wait in line for a keypunch. getting in line for the card reader, bideing my time in the execution queue till i could get runtime, and waiting by the printer to then get out of its queue. Hey it could be worse, I knew guys that put their decks in a box, it was picked up at the end of the day, and if you got runtime that nite, you could get a printout by noon. Now i save and test after adding 3 lines, just to make sure i didnt drop a brace or semicolon. Expect things to go slow, expect mistakes, then when things go well you are extra happy! It doesnt change just because your not a beginner anymore.

Re: Trudging along the learning perl path.
by 1nickt (Canon) on Apr 15, 2017 at 20:17 UTC

    You are learning a new language! As an adult! It takes quite a while to become fluent. And as with any other language, the more you practice the more fluent you will become. Stick at it!

    The way forward always starts with a minimal test.
      Thanks sir for your kind words.
Re: Trudging along the learning perl path.
by BillKSmith (Monsignor) on Apr 15, 2017 at 22:38 UTC
    I too often spend several hours on small projects. Most of the time is spent on small 'improvements' which have little value beyond what they teach me. Much of the remaining time is spent correcting the mistakes of fingers that do not seem to do what they are told and eyes that see what they expect rather than what is really on the screen. Its all part of the fun.
    Bill
Re: Trudging along the learning perl path.
by Marshall (Canon) on Apr 16, 2017 at 20:42 UTC
    While using a hash is a preferred way to remove duplicate values, I wanted to play around with perl trying to see if it could be done without using a hash. This is what I came up with.
    I re-coded your idea of sorting the array and then not printing duplicates. This algorithm is going to be much slower than using a hash table, but your idea certainly works. I can tell that your brain cells were on overdrive! I hope my example will be helpful in terms of algorithmic thinking.

    First a few quibbles... I changed the name of the subroutine to more accurately reflect what it does, "print the unique values". Also, in general don't push when you can print! If there is no need to save the data, then don't. Now probably this routine would have a return value in practice, but I went with what you did to illustrate this "print it!" point. I passed a reference to the @arr instead of the numbers themselves. This is just a performance tweak.

    Now, to the code... Very often code isn't written in a single top down, straight line approach. I didn't do that here. First I wrote the shift statment to make clear what the interface is and to give my input param a name. Then I wrote the sort statement since I had decided to follow your approach.

    Next, I decided that I was going to iterate over the @sorted array and I wrote the loop condition, the foreach(). Next I wrote the 2 statements that comprise the main part of the looop and embody the idea of "print this number unless I just printed the same number". This caused me to go up to before the loop and add the my $last_printed = undef; statement. Next, I realized that I needed to do something special right at the beginning of the array to handle the first number. That's when I wrote the "if" statement before the main bodypart of the loop. At that point, I could have made the code into an "if","else" construct, but I decided to just use "next;" in the if statement. I had already written what could have been the "else" clause.

    In loops, my advice is to write the loop conditional first... what is being interated over/what stops the loop. Next write the "main line" execution path. Then decide what to do to in order to either "get the loop started" or "fix it up" after it finishes. The print "\n"; is an example of something to do in order finalize what the loop did.

    Another common pattern is to do something before the loop even starts. If I were writing this in assembly, I would do it that way because it eliminates the "if" conditional within the loop. But I am not writing assembly and a simple logical test is of no consequence (btw, the sort uses comparitively massive amounts of CPU). Also note that I did not use any indicies. The "off by one" error is the most common programming mistake and my code avoids that pitfall.

    One of my hobbies is chess. I am an average player. When I play a master level player, my brain is working really, really hard and burning lots of glucose. The master level player's brain is hardly working at all! His brain is accessing patterns from thousands of previous games. Those patterns were formed by working really, really hard to figure them out. Programming is similar, patterns repeat and re-occur. It takes a lot of hard work to burn these patterns into the brain.

    Don't be so hard on yourself. Practice will help form those pathways to repeating patterns. The coding process will become easier and you will become more aware of the algorithms and design of the system. Concentrate on writing clear understandable code. Forgo tricky one liners - focus on the basics.

    I hope this code and my explanation of how I went about writing it is helpful to you.

    use warnings; use strict; my @arr = (29,24,0,24,24,12,0,0,10,10,10,19,17,15,13,1,12,12,24); sub print_uniques { my $array_ref = shift; my @sorted = sort {$a<=>$b} @$array_ref; my $last_printed = undef; foreach my $element (@sorted) { if (not defined $last_printed) # special case for 1st number { print "$element "; $last_printed = $element; next; } # do not print duplicates of the previously printed number print "$element " unless $element == $last_printed; $last_printed = $element; } print "\n"; } print_uniques(\@arr); #0 1 10 12 13 15 17 19 24 29
      super post Marshall!

      Beside of very clean explanation of your code generation, i like the example of chess gamers: patterns are a central argument while learning.

      A second general principle come to my mind: we are what we eat

      Listening good music open your music possibilities as reading good perl code can lead to better programs. Here idiomatic perl fit well as suggestion: to recognize and to write idiomatic perl is not a way to be flattened to a monolithic usage of the language, is instead a way to collect good patterns to rearrange with creativity to solve your problems.

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Trudging along the learning perl path.
by Marshall (Canon) on Apr 16, 2017 at 23:40 UTC
    I already posted an example of another way to do this subroutine at Re: Trudging along the learning perl path..

    Below, I have modified your code which uses array indices and "looks forward" to the next element. I am sure you wondered why you needed to sort the array yet again? That is because the index of -1 means the last element of the array in Perl and that caused the largest value to appear at the beginning of the @unique array.

    Here is another way of using "look ahead" indicies.... compare with your code...

    use warnings; use strict; my @arr = (29,24,0,24,24,12,0,10,29,10,19,17,15,13,1,12,12,24,31); sub del_duplicate { my @sorted = sort{$a <=> $b} @_; my @unique; my $current; my $next; foreach my $index (0..@sorted-2) { $current = $sorted[$index]; $next = $sorted[++$index]; if ($current != $next) { push @unique, $current; } } # this is a "fix-it" statement after the loop # in order to get the last element of @sorted push @unique, $next; # add the last value print "@unique\n"; } del_duplicate(@arr); #0 1 10 12 13 15 17 19 24 29 31
    I encourage you to sign up for a Perl Monk logon.
    You are trying to learn and are writing code. Beginners don't write perfect code and by the way sometimes experts don't either!

    Update: There is a problem with the above code if say, there is only a single element in @arr, i.e., @arr=(29);. This is one of several reasons why I would discourage iterating over array indices in Perl code.

Re: Trudging along the learning perl path.
by duyet (Friar) on Apr 16, 2017 at 10:33 UTC
    use strict; use warnings; # CPAN packages use Data::Dumper; my @array = (29,24,0,24,24,12,0,10,10,19,17,15,13,1,12,12,24); my %hash1; # slice @hash1{@array} = undef; my @uniq1 = sort keys %hash1; print 'uniq1 = ' . Dumper \@uniq1; # map my %hash2 = map { $_ => 1 } @array; my @uniq2 = sort keys %hash2; print 'uniq2 = ' . Dumper \@uniq2;
    Output:
    uniq1 = [ '0', '1', '10', '12', '13', '15', '17', '19', '24', '29' ] same for uniq2

    There are many ways to archive something with Perl, as Slices and map are shown above. And there are more as shown in other posts ...

    As you are starting to learn Perl (and any other programming languages), it is always painfull in the beginning!!! Get a book, learn the basic, follow online tutorials, and keep execise ... and it will get easier and easier ...

Re: Trudging along the learning perl path.
by karlgoethebier (Abbot) on Apr 17, 2017 at 13:13 UTC

    My 2˘ for fun and learning purposes or TMTOWTDI

    #!/usr/bin/env perl use strict; use warnings; use Data::Dump; use feature qw(say); my @array = ( 29, 24, 0, 24, 24, 12, 0, 0, 10, 10, 10, 19, 17, 15, 13, 1, 12, 12, +24 ); dd uniq( \@array ); sub uniq { my $array = shift; my $last = @$array[0]; my @uniq; for my $item ( sort { $a <=> $b } @$array ) { if ( $item != $last ) { $last = $item; push @uniq, $item; } } return \@uniq; } __END__ [0, 1, 10, 12, 13, 15, 17, 19, 24, 29]

    I cheated a bit until i got it ;-)

    And to be honest: in real life i would prefer uniq from List::MoreUtils:

    sub uniq (@) { my %seen = (); my $k; my $seen_undef; grep { defined $_ ? not $seen{ $k = $_ }++ : not $seen_undef++ } @ +_; }

    Regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

    Furthermore I consider that Donald Trump must be impeached as soon as possible

Re: Trudging along the learning perl path.
by Anonymous Monk on Apr 16, 2017 at 08:59 UTC

    You like puzzles. Programming in general is about solving puzzles. Perl is full of puzzles. The code you posted is puzzling. Puzzles are supposed to be fun. If you're having fun, keep at it. If you're not, go find another puzzle.

    In any case, here is my stab at your hash-less puzzle:

    perl -lwe '@a=(29,24,0,24,24,12,0,10,10,19,17,15,13,1,12,12,24);@x[@a] +=();print $#x and delete $x[-1] while @x' 29 24 19 17 15 13 12 10 1 0

      That's cheating a bit, because it only works with arrays of nonnegative integers. The OP version works with any numeric elements (<=> comparison). Interesting angle nonetheless.

      The hashless solution doesn't actually need any sorting. The following is a brute force filter, which maintains the input order of elements:

      use v5.14; use warnings; sub uniq { my @u; for my $x (@_) { next if grep { $x == $_ } @u; push @u, $x; } return @u; } say join ', ', uniq(29,24,0,24,24,12,0,10,10,19,17,15,13,1,12,12,24);

      It's of course asymptotically slower than sorting (O(n**2) vs O(n*log(n))), but if the input happens to be mostly duplicates, it will be faster in practice.

Re: Trudging along the learning perl path.
by Anonymous Monk on Apr 16, 2017 at 19:34 UTC

    Respected monks,

    I am at an absolute loss of words to express my gratitude towards your amazing responses. Its as if the monks consider answering with such knowledge, clarity,earnestness their moral duty.

    I posted the question late in the night yesterday and based on what I had heard, was half expecting either ignorance or rebuttal with perhaps a few enlightening replies , but to my utter dismay, I get such amazing responses. Not a single reply with even a shred of negativity, nor any with a holier than though attitude. You guys make folks like me love Perl even more.

    I had heard from a friend that one is more likely to get RTFM'd here or highly likely to receive a cold shoulder. But now I understand how totally incorrect his statements were. He had almost warned me to "tread carefully" here based on his experience. I'm going to mail him the link to this node. Thanks once again for your encouraging and knowledgeable answers. I hope this node stays here as a reminder for those who might have preconceived notions about this place.

      Your friend may have a point though. You should know that your original post was exactly what works here. You were polite, communicated well, showed code, and presented an interesting, if common, problem. Some seekers never do that, even after years of posting here.

      You got good replies because you made a good post. Some monks are crabbier than others and everyone can have a bad day. Questions are sometimes answered with RTFM but usually only when the OP hit some kind of sour note or rubbed someone the wrong way.

      Be prepared for a little friction while trusting the soul of the monastery.

        very well said YourMother!

        this come from a general principle: is the question to be important.

        When you ask the wrong question to the oracle you get not usable garbage: a good question can profit even from a concise or somehow obscure answer.

        Even agent Spooner know this since years..

        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      If so definetively choose your monkname and signin!

      It can happen to find someone upset, but we are all human being after all; generally monks are polites and want to help: see Spirit of the Monastery

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Trudging along the learning perl path.
by kbrannen (Beadle) on Apr 21, 2017 at 15:08 UTC
    We all learn at different speeds and many times the speed we learn at is proportional to the time we spend. If your life is busy and you only get a little bit of time to spend on this, the natural result is that it'll take longer to learn. That's natural and there's nothing wrong with that. I do applaud your willingness to hang in there and continue; I'm sure that determination will get you where you want eventually.

    As to your problem, looking at and understanding classic problems is a decent way to learn. Many of us wouldn't solve it that way, but that's because we're probably trying to solve a business problem and not teach ourselves something. We'll grab the first thing that works and use it.

    As I'm lazy, I'd probably just use the hash and do:
    @arr = ( ...as defined in the problem... ); %h = map { $_ => undef } @arr; print join(" , ",keys(%h)), "\n"';
    There's probably even a way to do that in 1 line, but again, I'm lazy. :)

    Besides all the other good advice you've been given, I'll add 1 more I didn't see (my apologies to anyone if I overlooked this in your post).

    I believe someone did say they keep snippets of code, which we all do, but I'll advise you to go further. I actually keep a notebook of code examples and explanations from PerlMonks/blogs/web-searches/books/etc for reference, not to mention little things I've found on my own over time that are helpful. I put it in an electronic notebook for easy searching and organization (I use OneNote, but use whatever works for you). It's grown over the years and has become a helpful companion along the way -- a trusty toolbox of tips and tricks and reminders.

    Good luck in your journey, and sign up and join us here too. :)