Learn Perl in about 2 hours 30 minutes
qntm.org
qntm.org
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.
I've always wanted to give Perl a go but can't find something I want to use it for.
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.
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!
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
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
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?
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).
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.
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:
$ sudo /usr/bin/perl -MCPAN -e shell
> install Devel::REPL
$ re.pl
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.)
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.
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).
shell> perl -de 1
This will take you into the perl debug shell (after evaluating the string "1" which is true).
$ 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 worldhttp://search.cpan.org/~apeiron/local-lib-1.008004/lib/local...
This very handily includes instructions on how to bootstrap its own installation.
also you can do this: $ perl -e 'print "Hello World!\n";'
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.
Same applies to C++ and Vim.
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.)
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.
Nonsense. All you have to know is how to identify operators and how to use the documentation. The Modern Perl book covers that in a page or two.
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.
It's undergoing major revision, and not a minute too soon.
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.
I know there's a site that does that (can't remember the name) but having it side by side with a great overview like this would be awesome.
Or perhaps Rosetta Code?
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...
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".
What does the Perl community mean to you? It must not include Sam.
Is it people who organize and participate in conferences and get indignant at the slightest negative comment?
"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."
For that purpose, it is fine.
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.)
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.
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 would prefer to use Perl over bash/awk/sed since Perl is good at the same things and more and has alot more libraries.
Python is basically Perl but with different syntax, libraries, and community.
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? :-)
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.
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.
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.
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.
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.
Compare, for example, AnyEvent's documentation with that of Twisted - or any of Perl's standard documentation with that of Ruby.
That somehow fails to convince me that other language ecosystems parallel the CPAN in breadth, scope, maturity, and ecosystem. See CPAN Testers, for example.
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.
Regards,
Sigh... :-)
He started:
>>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 [etc]
Are you really surprised about the down votes...?
I honestly have no idea what you mean by that :).
> 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.
My trivial point was that your claim about the down votes was contradicted in the first sentences. It seems you missed that, too.
>>if people can't acknowledge the flaws in a thing
Quite fun to do personal attacks like that after such creative way of misreading.
Edit: Sorry for wasting time/space, I am easily trolled.
> 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.
Edit: Thank you for trolling moderator.
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.
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.
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.