The ebook/PDF edition is free! It's a great book for learning (modern) Perl basics if you're already familiar with programming concepts and another language like JavaScript (which is where I'm coming from).
Actually, I think the knowledge and best-practices gleaned from the book will help to make me a better programmer in a general sense (not just in terms of the Perl language). It's well written, a pleasure to read and I highly recommend it.
I'm really surprised no one has mentioned Higher Order Perl. It's not just an excellent Perl book - it's an excellent programming book. Even if you don't plan on coding in Perl, HOP may change how you write in Python, etc. Also, the pdf download is free: http://hop.perl.plover.com/
No previous Perl programming-experience. I've been consciously aware of Perl since at least 1998 and even poked at the source code of some scripts here and there, but didn't bother to really learn anything about it until recently.
A brief explanation; perhaps someone here will be inspired or is thinking along similar lines:
I've been using an "object system" for JavaScript named Joose:
http://joose.it/
Joose is amazing and is, roughly speaking, a port of the Moose object system for Perl to JavaScript. (Moose is mentioned in various comments below and many times in the "Modern Perl" book.)
The principal author/maintainer of Joose v3 (Nickolay Platonov) has developed an ecosystem of tools on top of Joose3 and for Joose-oriented distributions (github.com/SamuraiJack). Much of their design is inspired by popular distributions in Perl's CPAN (Nickolay has a strong background in Perl, obviously). And some of them are still tied into Perl libraries, not simply ports to JavaScript.
As node.js and its package manager NPM have evolved rapidly in the last 12 months, some of the Joose stuff is lagging behind and in need of an overhaul, e.g. Nickolay's "JSAN plugin" for Dist::Zilla.
I've been wanting to help, but it's difficult to hack on Perl code if you don't even know the syntax. Well, that's where chromatic's book has come to the rescue! To be honest, it's been a real eye-opener and, as I suggested earlier, I think this Perl learning-experience is actually going to be a big boon for me in the near term and into the future. It's already allowing me to view Joose and related libraries through new eyes.
Not sure if you'd have any thoughts on this matter...
The JavaScript community as a whole (seen especially in the direction of node.js + NPM) is moving away from global namespaces and toward the "module pattern" and dependency injection (note: I had no idea what those terms really meant 6 months ago).
Presently, Joose3 goes against that grain. For example, if in a node.js script you:
require('joose')
if (Joose) { console.log(true) } // prints true!
Basically, the global namespace gets auto-populated with "Joose" and a chain of namespaces below that. This is very Perl/Moose-like, of course.
When you define classes, roles, etc. you get similar behavior:
Joose.Class('MyClass', {...})
if (MyClass) { console.log('effectively stubbed in a global namespace!') }
// does log that text to console, as Joose.Class() behaves that way
And in fact, Joose3 encourages you to embrace that behavior (with `use:` builders and lots of discrete files) to arrive at a network of cross-referenced namespaces which altogether form a library, and API usually.
To go with the flow, and especially to take advantage of emerging module specs like AMD (commonjs thing), a redesigned Joose (i.e. Joose4) needs to eschew global namespaces entirely:
var myJuice = require('joose')
...
// There should be no tie to a "Joose" namespace as such
But how to do that, and elegantly?
Any wisdom from the Perl community in that regard? Maybe someone else has been trying to port Perl stuff to JavaScript/node.js and has found the perfect formalism for translating from global namespaces -> module pattern + dependency injection? Know any Moose wizards that would be willing to help explore this matter?
I haven't written a lot of Joose code, but I use anonymous classes and store their constructors as attributes of a lexically scoped object I inject where I need it, so as to avoid global pollution. So far it works nicely.
Personally, I've found knowing perl useful in some of the same ways that I've found C useful. Perl is still one of the most popular systems scripting languages and perl code always seems to show up somewhere important.
If I were into serious application development I would probably try a project with Clojure before perl, but there are a lot of situations where that might not be desireable (eg you don't want to use the JVM).
Perl is a really great language that i came to love over the years.
First, I've been writing PHP stuff then moved to Perl and experienced Java,Actionscript,Javascript,Objective-C,Python...
But all of them, Perl was the most powerful and expressive language.
For those who learn Javascript, Perl object literal notation
should be really easy to get and if you do some jQuery stuff, many things should come naturally to you somehow. Perl supports packages, closure, utf8 since many years whereas they are just coming to PHP (It's a real pain to go back to PHP for some projects... as it looks like a huge trash of functions in the global namespace with no cohesion at all... working with array_, mb_ or preg_* functions is such a pain... hopefully the doc helps in understanding the quirks of the language).
The integration of regex as an operator is so nice.
q[] or qq[] helps quite a lot and I quickly miss them...
Controlling each instance of the program flow in code is very powerful too.
I guess the very minimalistic OOP system shipped with Perl did not help get Perl across the board of a wider range of company...
Obviously, this le/gend/ary image of unreadable code that one-liners, and to some extend sysadmin community, gave to the language has left a very bad taste in the mouth... and it is now very hard to get rid of.
when you look at http://mojolicio.us/ or http://perldancer.org/ for web development, Perl::Critic that analyzes your code for bad coding habits(JSLink like), perltidy that reformat your code to follow your conventions or Devel::NYTProf to profile every line of your code...
I don't even talk about CPAN that has always get the job done for me in like 90% of the case...
I still have to find a language that offers such a powerful ecosystem.
And for those who wonder, Perl is very active here in Japan.
Considering the amount of legacy Perl scripts that I have had to rewrite since I got
to Japan due to a lack of Perl developers that can mantain them,
I'd think that Japan's Galapagos argument does not work so much
in this case. I think that it is also losing strength around here.
It does not mean that Perl is not active in Japan though.
Many big companies in Japan uses Perl as the language of choice for their websites but indeed,I won't say that it's not loosing some market share though.
If you really want to learn Perl, you must install the read-eval-print loop (REPL) utility. If you have never used this utility, I will have serious grounds to doubt your Perl skills.
Unlike Ruby or Python (or most other modern high-level programming languages), Perl does not come with an interactive REPL shell, which makes no sense at all, since, due to Perl's obscure syntax, someone trying out Perl would benefit at least twice as much from a REPL shell than someone learning Ruby or Python. Fortunately, the Devel::REPL package remedies this. Installing it is super-simple:
Once installed, simply open your terminal and run:
$ re.pl
Once you have the REPL shell running, you can pretty much copy-and-paste into it examples from this tutorial (or any other) and watch what Perl has to say in response.
If you have never used this utility, I will have serious grounds to doubt your Perl skills.
Doubt away.
I have never used that utility. Yet I have been programming Perl since the 90s, and am one of the top 10 posters on Perlmonks. (My nick there is tilly.)
> I have been programming Perl since the 90s, and am one of the top 10 posters on Perlmonks... Care to re-evaluate your criteria?
Yes, for you, I can :) My post was meant only to advocate interactive learning (which I came believe to be faster than the usual code/modify/run cycle). Few things (if any) can beat 15 years of intense experience. Most people, though, whom one is likely to encounter in the real world who claim to know Perl will only have used it for a year or two, probably in combination with something else.
I'm in exactly the same boat. I've been doing Perl for 14 years, and never use a REPL. Occasionally I'll hit 'perl -e ""' on the command line, which I guess is a similar idea...
Hey I didn't mean to offend Perl long-timers. See my response to btilly...
Hacker News is a bit of an exception to what you find in the real world (where 3 years of experience with a language can be considered as better than average).
That works of course, but Devel::REPL is much more convenient: (1) you don't have to end your statements with backslashes -- you can paste whole blocks as is, (2) you immediately see what your statement evaluates to, for example typing "42" in Perl debugger simply begins another prompt while typing it in a true REPL returns the value that your statement evaluates to (i.e. "42") -- which is not a big deal with simple statements but gets interesting once you start evaluating regular expressions, for example, (3) Devel::REPL remembers what you typed (or at least it works the same way as your system shell), (4) it is really easy to work out complicated things in Devel::REPL -- see for example this case of currying a function:
$ my $x = sub { my $x = shift; return sub { $x . shift } }
$CODE1 = sub { # this is what is returned by Devel::REPL
package Devel::REPL::Plugin::Packages::DefaultScratchpad;
use warnings;
use strict 'refs';
my $x = shift @_;
return sub {
$x . shift(@_);
}
;
};
$ $x->('hello ')->('world');
hello world
> sudo /usr/bin/perl -MCPAN -e shell
This reminds me of a gripe with Perl: If you are on a machine where you lack root, everything is a lot less convenient.
It has been on my todo to try the REPL for a long time, but since Perl is the most powerful command line tool in bash, I've never seen a reason to use an interactive tool.
alias p=perl
p -e '...'
p -ne '....'
# etc.
Edit: With powerful I didn't mean "rm -rf", etc. :-)
I've been working with Perl programmers for just about ten years now and the one thing I've sadly learned is that while many folks claim to know Perl, but only a small group can do it well. (although granted you can apply this reality to any other programming language)
Perl is easy to start with by learning something like "Hello World!". Probably just because of this reason, most people stop at early learning stage. Perl was originally created to bridge the gap between C and shell. At the end, it is a language hard to grasp, yet very powerful.
Alright you win -- I'll rephrase to be accurate: "know Perl but are looking for a job!" Often if they were good they'd be busy -- and yes you can claim that about any programming language too unless it's unpopular...
So many single/double char operators which need to be memorised with Perl, before you can start comprehending the programs.
Not to mention Perl hackers used to pride themselves on super succinct code - in certain circles it use to be popular to include one liners to do complex stuff in email signatures.
(Not complaining though, Perl was the first language I used, and probably the simplest for text file processing in CGI's back in the day.)
How do you do that in other languages? Whatever language that you will ever use will require you to understand and to a degree memorize your usual keywords, operators and syntax elements and rules concerning interplay between them.
Regarding other stuff, building good software requires understanding a lot of things which have nothing to do with Perl. Understanding concepts like recursion, closure, OO, functional programming concepts etc etc. These have to be first understood in theory. The Perl syntax is only a notation in which you express your ideas. Besides that designing good software requires people to understand design patterns, designing maintainable software requires people to work on large project under sound practices. Writing fast and efficient software requires people to learn Algorithms and data structures. And so on...
These principles remain the same regardless of the programming language you use. Then why is it that only in case of Perl people hold the language responsible for everything. To be frank, I have seen crappy code more often in other languages than in Perl. I have seen over abuse of certain element like XML in Java, and now these days Python.
The fact is if your technology community is huge you get a lot of crappy people along with your usual set of good people. This happens for various reasons, Everybody wants to learn something that is famous as it helps for Job reasons.
Perl's strength apart from your usual language kit is CPAN, language tools to produce highly useful rapid scripts in time. Heavy data lifting, data munging. A gentle glance at things like Moose, Modern Perl, Devel::Declare and all associated software with them(Catalyst, DBIx::Class), will show you the genius of Perl community in coming up such great stuff in time.
>Not to mention Perl hackers used to pride themselves on super succinct code - in certain circles it use to be popular to include one liners to do complex stuff in email signatures.
One of my favorite examples of that was back when DVD John released DeCSS, and some Perl hackers turned it into a 7-line Perl script:
I built a 2D mmorpg using Perl and Erlang. The languages a lot of people whine about when it comes to syntax.
Syntax is the LAST thing I had to worry. I'm really happy that I chose those two languages.
I do wish he had mentioned the smart match operator ~~ as it nearly eliminates the confusion between EQ and ==. Of course, if you're dealing with legacy code, then you still need to understand both (or all three), but new coders might be well advised to start with smart match.
"Smart" match is a pile of shit, and anyone reading the manual description for it should conclude the same. You can't know what it does unless you can remember the details of a 23-item table.
It's undergoing major revision, and not a minute too soon.
Nice concise writeup. The only important thing he missed as far as I can see is that the '..' operation can create anonymous arrays of sequences of characters too so 'a' .. 'z' gives you an array of all the letters between 'a' and 'z'.
Wish there were similar ones for all the other languages - PHP / Python etc. I always thought that most programmers and web developers experienced in one language can quickly pick up the major features of another lanaguage, if there was a quick overview of this sort. Know of any sites that do this? Maybe this is a great opportunity for someone to put together a site like that?
One thing I've always wanted to do is cross reference the data structures/containers for various languages. In Python a dictionary is what Perl calls a hash and what C++ calls a map. Three different names for the same data structure (key value based).
I don't think Perl has a set container by default, but they can be added from CPAN, Python does, it's called a set ;) as does c++ where it, too, is called a set. Again, a key value based data structure, but in this case, the key is the value.
Rosetta Code's the one I was thinking of, but I really dislike their structure - I never want to see how to do something in dozens of languages, almost all of which aren't relevant to me.
What I would love to see is:
1) select language you want to learn
2) select languages you already know
3) you get a cheatsheet like the OP that goes through all the basics (and maybe even more detailed), and all the code samples are changeable ala MSDN where you click "C#" or "VB.NET" or whatever to see the code in that language: http://msdn.microsoft.com/en-us/library/system.drawing.bitma...
Perhaps someone can use Rosetta code as a starting point (their content is GNU licensed) and build a site that does what you are suggesting - where it only shows you the features for the languages you want to learn, based on the ones you know.
Sam, you've certainly made an enemy out of every member of the Perl community with this sarcastic and incomplete post.
Once you've gotten through OReilly's beginner Perl books and "Programming Perl", if you truly want to learn how to scale Perl in the enterprise, read Damian Conway's Object Oriented Perl. Once you can write solid consistent OO Perl, read "Apache modules with Perl and C".
No, we are not all like that. Fortunately. The author states:
"A bunch of new people started at work and we use a lot of Perl in our department. So I put together some information about Perl and I thought it might be worth sharing so here it is."
The intro is okay, but it did not help Perl community at all. Besides, the article itself has some poor code. For example, if one wants returning nothing, return "" is a very bad idea, since to catch it in as array would make an one-element array which is true.
Perl's used more widely than Python, if you look at job trends -- but then again, you have to consider that Perl 5 was more popular earlier, so there's a lot of entrenched usage. Python may or may not have more new projects written in it; the statistics are difficult to interpret.
You can get by knowing one or the other well. Perl's advantages to me are the CPAN, the tooling culture, the testing culture, and a very pragmatic approach to getting things done without the language or ecosystem dictating how.
Python's advantages are slightly cleaner defaults in Python 3 and the fact that all code looks basically the same. (I'm not sure I see that as an advantage, but other people do.)
That depends on what you want to do. If you want to do things with text, especially transforming text, Perl is IMO opinion better at that task. Perl has been the scripting language for me, but I'm thinking of changing to Python because of NumPy, SciPy and the libraries for numerical analysis and scientific computing. Python seems to be better than Perl in that area. This is a library issue whereas when it comes to text processing it's more of a language thing.
I think Perl and Python have a lot more in common than differences when it comes to what they are good at. If you know one scripting language, you don't gain as much when you learn the next. My recommendation is to learn something different, C, Haskell, Lisp or Prolog for example. That would make you think in different ways.
Also, chromatic (a Perl developer) gives a very balanced answer in a sibling to my answer, so I won't repeat what he said.
If you want to stick to perl, you might want to check out http://pdl.perl.org/ if you haven't already. You can do a fair amount of scientific computing with it.
Among other things it overloads the basic operators, so $a+$b will do the right thing, even if $a and %b are matrices/images, so it is very easy to "read" if you are a perl person already.
Perl has its own strengths. In order to win as scripting language on the UNIX environment a language will have to get some things right very well. Two of them namely 'Processes' and 'Files(text)'. UNIX is really about these two things heavily. That is why you will see UNIX by a vanilla installation has shipped with tools like sed, grep, awk, cut, tr, cat and other text processing tools for decades. Because a file can act as a pretty good representation for data, storage and problem representation use cases. Another area that the language will have to get right is 'DBMs'.
Speaking of Perl's merits as scripting languages alone, Perl offers a native way of interacting with all these things that I mentioned in the previous paragraph. Things like ``, system(), open(), close() , die(), chomp, while<FILEHANDLE>), split(), grep, !~ , ~= and regular expressions make text processing a breeze. In addition, Higher order parsing is very easy in Perl too, Regular expressions are first class objects. For more information on this you can read Mark Jason Dominus's Higher order Perl. Which is a free book.
Now coming to Perl's merits as general purpose scripting language. You have your usual language tool kit with data structures(usual numbers, strings), arrays, hashes. Flow control, functions, OO, functional programming features. But the plus and the biggest winner is the extension system. There is a huge repository of readily solved problems on the CPAN. You have language extension modules like Moose, Try::Tiny, etc etc.
In terms of the web development ecosystem, Perl has catalyst, DBIx::Class, Plack etc etc. You also have a good asynchronous programming framework.
In terms of documentation. Check out the amazing perldoc.perl.org. There is also Learning Perl, Programming Perl and recently Chromatic's beautiful book 'Modern Perl book'.
In terms of development practice and stability. Perl has a track record and battle tested for decades now, Its used to develop mission critical applications. For best practices you can read Damian Conway's Best practices book.
Also, Checkout enlightened Perl and Task::Kensho for the best of the breed modules.
As a plus and cherry on the cake, there is a new sister programming language called Perl 6 in the making. With great concepts, cleaner defaults and more pragmatic in the real world.
Perl 6 is usable today with Rakudo. Give it a whirl.
I personally found that I didn't need Perl at all. I am a bioinformatics programmer/scientist and Perl was the first language I learned. I find that whatever I can do in Perl I can do with bash/awk/sed--and whatever I can't do with bash/awk/sed I can do in Python. I've never been happier.
Whatever you can do in one Turing complete language you can also do in all other Turing complete languages. The point isn't what you can do, the point is what tasks are easier, simpler or faster to do in one language compared to another language, while also respecting how hard the language is to learn to get to the point where can can do what you want (easily).
I would prefer to use Perl over bash/awk/sed since Perl is good at the same things and more and has alot more libraries.
Perl's advantage over bash/awk/sed is that you can test, organize, and maintain code more effectively. This may not matter if you are programming to solve tiny unrelated problems, but it's a waste of effort if you are doing similar things frequently.
Python is basically Perl but with different syntax, libraries, and community.
I agree w/ you about 90% on this. However, you're painting w/ a broad brush including Awk and Sed. I imagine beyond 10 lines of Awk (gsub, anyone?) or about 1 line of Sed things get tenuous, and you would want to reach for Perl or Python. Sed & Awk are great for tiny stuff, but wear thin fast. The realm of text-only problems, about 15 to 40 lines of code is where I find Perl shines. Python is probably my favorite language, but it can be horribly clunky for these sorts of tasks.
obviously in such a small (in terms of computing in general) discipline, a general purpose language might not be the best. Now if you want to publish your results to AWS and a website and pull data from a website front-end, etc. You can probably do it quickest with ducttape.
The scripting languages are quite similar. IMHO, it is better to learn something different instead of another one of them.
Perl has an emphasis on libraries. CPAN is the gold standard for the scripting languages. (To see what I mean -- search for signatures, Moose and Acme::Bleach on search.cpan.org. (+) )
Another good thing is the community of smart and laid back people.
I personally prefer to do Perl because it is fun.
The main disadvantage with the Perl "everything and the kitchen sink" attitude is if you are in a group without good coding standards... Perl also gets a tougher learning curve in the beginning, just from there being more to learn.
(+) Joke modules on CPAN generally start with Acme.
Edit: Huh, why down votes? Just a reflex by language trollers? :-)
How is it too late? Ten years ago, significant pieces of Moose did not exist anywhere.
You can make the argument that if Perl 5 had had a better OO system not borrowed from Python, Moose might not exist now. That may be true in part, but I suspect significant pieces of Moose would still have to exist.
Not enough people on the bandwagon, competition from Ruby/Python/JVM languages on the high end and Perl 5 on the low end, and last but not least the fact you can't use libraries written for Perl 5 with Perl 6.
I wrote a medium-sized project in Perl 5 two years ago. It is my day job right now to work on it. I have very little interest in rewriting it from scratch in any language, but if I did, it would probably be either Ruby or something on the JVM.
Oh my why would anyone want to lean Perl anymore? Unless you are working with a legacy codebase learn Python, Ruby, Java, C#, Erlang, Scala, Haskell... in other words run the f away from Perl if you can unless you are into S&M.
Because it's powerful, it's easy to start, it's flexible, it's productive, it's ubiquitous, and it has an unparalleled extension ecosystem devoted to quality and ease of use.
Thank you I did read the post. Python has pypi. Ruby has gems. I'm not going to google the rest but if they don't have one there is no reason why they can't.
And FYI pypi is better than CPAN so all the other stuff in the that post is crap imho. I was a Perl dev for ~10 years. Now have about 5 worth of Python. So thank you.
I don't know about python, but ruby's gems are quite inferior. Just two points:
gems has no idea if any specific gem is already installed, so if you ask it to, it will just install over whatever is there, no matter if it's the same or not.
Additionally it does not automatically run tests and abort if they fail, so the chance of installing a broken gem over your existing working gem is pretty big.
There is a culture of documentation, cooperation and tolerance in the Perl community that, IME, doesn't really exist for other language communities (Ruby and Python).
Compare, for example, AnyEvent's documentation with that of Twisted - or any of Perl's standard documentation with that of Ruby.
I'm not going to google the rest but if they don't have one there is no reason why they can't.
That somehow fails to convince me that other language ecosystems parallel the CPAN in breadth, scope, maturity, and ecosystem. See CPAN Testers, for example.
Oh my apologies I wasn't trying to convince anyone of anything if that's what you are thinking. I was only stating fact based on my experience but that's okay just downvote this and make yourself right.
Nobody was down voting you to make themselves right. But the remarks that you made about CPAN to be frank didn't make any sense at all to anybody who has worked with CPAN seriously over years.
Both in terms of quantity and quality CPAN beats any other scripting ecosystem by a very great margin. And its really not about the number of the modules. That many number of modules would not have been possible if Perl(syntax, extensions system) was not flexible enough to allow them.
The traditional approach used by languages is to first build a set of semantics define a syntax and standard library for it. Then any other development in that language happens through frameworks and libraries. Perl is special in this case that Perl allows syntax extensions through modules. There fore you will find not just Modules to do your task, but also modules that add and extend to exiting Perl syntax with sugar. Perl 6 extends this concept further through grammars.
How often and how many language are there today(Counting Python and Ruby especially) that can add something like Moose(Moosex extensions) and other syntactical extension to their language, without breaking backwards compatibility?
Python took around 8 years and broke backwards compatibility to make as little changes as context of a for loop and print statement. Now imagine what it would take Python to fix its object system or its scoping problems.
Thank you for the excellent reply. That was response I was hoping for. I don't know everything and I appreciate you talking on point and not just pressing the down arrow because someone said something you don't like.
> Are you really surprised about the down votes...?
For that post of course not. For the others yes.
I can only assume you are coming from this viewpoint
"Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them."
and no I don't think I had anything genuinely new to bring but I how could I know about something I didn't know about.
I guess what I am really saying if people can't acknowledge the flaws in a thing how could they ever make it better. And to say even more if they can't vocalize their reasoning how does downvoting make it okay but I am sure that is another thing I have missed.
Hi. Thank you for taking all the things I said out of context. I am going to try my best to do the same despite the fact that I believe this is what HN is trying to avoid, moderator.
> My trivial point was that your claim about the down votes was contradicted in the first sentences. It seems you missed that, too.
I am sorry you think your thoughts are trivial and despite your grammatical errors I would love to know how a first sentence can be plural. I have no doubt that I missed a lot things prior. That was my entire point of my following posts. Maybe if I knew which first sentence you were referring to I could have a better response.
> Quite fun to do personal attacks like that after such creative way of misreading.
There were no personal attacks in the previous posts unless of course you are Perl. In this post maybe there are many only because you made it so.
And I would appreciate if you read this small thread, moderator, and came back with an intelligent reply.
Yes I could have not been a dick on this but you reap what you sow.
I hear about new Perl projects starting in large enterprises everyday!
Unless you are in the web programming domain(Somehow web developers think their's is the only software being written in the whole world) where your Python and Ruby frameworks seem to be famous. Perl is pretty big in the backend.
Perl is here to stay, and its simply too useful to be going away anytime soon.
I didn't get your point. I have found Perl(And many have) very useful for whatever we do.
So we continue to use it. Just because there is some new shiny stuff around, we don't use just for the sake for using it.
Trolling Perl to advocate Python hasn't helped for decades and won't help now either. A better debate will be to argue on technical merits. Trolling and whining gets people curious to verify if all that is true, thereby forcing them to read and some readers adopt it too.
To be fair I didn't think I was trolling but I can completely understand why you think I was. I could only talk about things I as knew them to be. Whether that makes me an ass or an idiot I don't care. I did want to hear a good argument as why I was wrong and again I appreciate your reply.
EDIT: My original comment was really just meant to be humorous I am sure know why since you are aware of Perl's syntax. It did make me a lot of money at a time but nevertheless I stand by what I said as that is the best advice I could give myself right now.
http://onyxneon.com/books/modern_perl/
The ebook/PDF edition is free! It's a great book for learning (modern) Perl basics if you're already familiar with programming concepts and another language like JavaScript (which is where I'm coming from).
Actually, I think the knowledge and best-practices gleaned from the book will help to make me a better programmer in a general sense (not just in terms of the Perl language). It's well written, a pleasure to read and I highly recommend it.