
What is Modern Perl - davorg
http://www.josetteorama.com/perl/what-is-modern-perl/http://www.josetteorama.com/perl/what-is-modern-perl/
======
chernevik
I'm torn between thinking there is value in learning some Perl and not really
knowing that value might be.

I've found a lot of embedded wisdom in the "old school" stack. If you edit in
vi, add some sed / awk / grep, and learn some bash, you'll find these tools
start to come together and leverage one another up substantially. Perl might
be more post-Bell Labs but it still was written and used by smart people to
Get Stuff Done. It stands to reason that there are large returns on learning
it.

But it isn't as approachable as Python. When I needed a glue language, I first
looked at "Learning Perl" -- after a few days I concluded that, if this was
The Path, then I would never get There. Python was much more approachable, and
my code already gathers so many hacks that I'm glad my language forces me to
make these at least somewhat intelligible.

I would learn Perl faster now. But for what? I've learned some PHP to meet
client demand, and for web development the next language would be RoR. I bet
Perl is better than bash for various sysadmin and utility tasks, but bash
feels good enough for the simple stuff I do. If I needed to do something
really beyond bash I'd turn to Python, and I'm not sure why Perl would be
better. I suspect there's a lot of general knowledge embedded in Perl but I'm
not sure how that gets extracted and made current among today's toolset for
the tasks I have.

So to my mind, Perl is something of a sysadmin tool, better than bash and very
useful for a workload focussed on system and file processing, on *nix, without
much service to HTTP. I'd love to hear how it pays returns for people more
focussed on back-end support of web development.

~~~
kamaal
>>But it isn't as approachable as Python.

Minimalism, is both an advantage and a curse. You may be able to learn python
quickly, and that is because the syntax and semantics are designed with a goal
to do that. But unfortunately that is not the only problem programmers have,
Learning how to program is problem only for first few weeks of your
programming career, there after its hardly a problem. Beyond that verbosity
becomes a curse, once you begin to understand what 10's of lines of code do,
you wonder why you even need 10's of lines of code when something can be
expressed more elegantly.

In my experience people complain about learning Perl for the same reasons why
they don't get awk/sed/tr and other text processing utilities. Tools like that
are a little difficult to start with, but offer tremendous advantages. Skip
learning them, and suddenly you put yourself in a situation where you start
your eclipse and write Java programs for every small bit of text processing
task. That sucks up your time, effort and code forever. So its better to learn
tools that are better designed to solve such problems.

>>and I'm not sure why Perl would be better.

Perl and Python are both excellent languages, so you find a range of problems
that can be solved in both languages well. But try solving problems that Perl
was specifically designed to solve, Pick up the book Higher Order Perl by Mark
Jason Dominus(Its Free) and see for yourself how Perl helps you solve a
certain kind of problems. I'm sure its the same case with Python too! Its good
for academia, as its easy psuedocode.

Problems that can be solved in both Python and Perl can obviously be solved in
any of them.

>>So to my mind, Perl is something of a sysadmin tool, better than bash and
very useful for a workload focussed on system and file processing, on *nix,
without much service to HTTP. I'd love to hear how it pays returns for people
more focussed on back-end support of web development.

You have just described a very small subset of problems Perl can solve. Perl
is used for developing very large application in nearly almost every industry.

Web programming != Entire Programming world.

Much of the software world never writes a web page. And they do programming
too. But like us they don't tweet/Facebook/blog every time they finish writing
a class.

------
smugengineer69
What is modern Perl? Python. (I'll elaborate more here from my earlier one-
word answer).

Long-time perl programmer here, until I found Python. Perl is powerful, but
Perl is for the programmer, not the programmer's coworkers. It's not even for
the programmer 6 months down the line. This is nothing new, and it has become
a stereotype in the community.

Yes, this argument has been made and refuted many times, but I argue the
reason isn't the language, but the dominant language paradigms.

Perl's "monk" ideal is not sustainable in the long term, and encourages
"clever hackers" who can do things with the fewest lines of fundamentally
unreadable code. Yes, the language has evolved. Yes, it is slightly easier to
read now. But the goals of the community still tend toward the ideals of
becoming a master of arcana who can pass his wisdom down to the less
experienced.

Give me a language that the commoners can read, that a beginning programmer
can feel empowered to learn because he can take one look at the source code of
someone truly experienced and know at least a part of what is going on.

You can change Perl all you want, but you cannot get away from the fundamental
guiding principles of the language, which encourage antisocial, clever, and
magic code.

~~~
jimmytucson

        > What is modern Perl? Python.
    

Ah, 'fraid not.

I am also a Perl to Python refugee. For most applications I get far more
enjoyment out of Python. But try implementing Higher Order Perl in Python and
you won't get past Chapter 1 without some weirdness. Using decorators, lambda,
map, reduce, itertools, even generators all feel like bending over backwards
to achieve what comes naturally in Perl.

This isn't an attack on Python. I'm just saying, Python is not meant for
functional programming any more than Perl excels at OO, and that's why I
disagree with your thesis.

~~~
berntb
>>any more than Perl excels at OO

Check Moose and related on CPAN, modern Perl has probably the best OO among
the usual scripting languages (Python, PHP, Ruby, etc).

------
r4vik
I actually own the domain modernperl,net, for trollish reasons actually
(www.modernperl.net redirects to Ruby) but if anyone wants it / wants to do
something useful with it. I'd be happy to transfer it to you for free.

~~~
hippich
I think you might want to contact chromatic so this domain could be setup to
redirect to his <http://modernperlbooks.com/mt/index.html>

He gives away his ebook for free, so I guess giving him free domain might be
very good for your karma :)

------
kamaal
I started using Perl around 2006'ish, that was pretty late in the day compared
to most Perl hackers. I was primarily a C/C++ Dev, going the OO way. And I was
doing Java here and there.

Until one morning a colleague of mine, saw me doing some stuff I was taking
really long to finish. He just walked up to my cubicle and just said 'Why dont
you use Perl to do this' and then started my crazy journey with Perl. What I
really like about languages like Perl/Python and Ruby is how quickly you can
go from learning to building something really useful.

Perl has seen atleast 3 major rise in its popularity since its inception.
First one among sysadmins, its from these days that you will powerful terse,
small but elegant solutions to a range of problems. If you ever get a chance,
do browse and read essays from Tom christiansen written during those times.
They are just pure gem. The second was during Perl/CGI days. And third was the
most recent with the Modern Perl movement. Much of the thanks for this goes to
People like Chromatic, Audrey, People of p5p, Moose devs and etc. From each of
those times, you will see varying variety of code written. Starting from
really amazing one liners to at times some frustrating code during the dot com
bubble, to now where Perl code really looks very nice.

Modern Perl really is set of many successful sub projects. And its not just
code, it covers everything. Code is just the beginning. To give you an
example, these days you have very nice cpan package managers. You can search
packages using Metacpan in a very user friendly GUI with nice syntax
highlighting. You have awesome documentation, Modern Perl book really is the
Perl's equivalent of the K&R book. There is Moose, And there are things like
Class::MOP. There are things like DBIx::Class.

In terms of other new breath taking stuff you will see things like
Devel::Declare. This allows new syntax extensions to be written using Perl
itself. Then as a result you have a range of modules like
Moosex::<extensions>,Try::Catch, Gather::Take etc.

In terms of web frameworks your have Catalyst.

So its really these many many successful subprojects together which form
'Modern Perl', if you wish to describe it that way. Its no one thing. Code,
documentation, culture, events, infrastructure etc etc all together form the
'Modern Perl' thing.

If you come to the Perl core development, then they have real good time based
releases. They are fixing bugs, adding new features, and doing a lot of
amazing stuff. There have been pretty neat syntax features added in the past
few releases and I guess much of Perl 6 based features will continually seep
into Perl 5 as needed over time.

Modern Perl, or other wise. Perl continues to retain its niche. Which is text
heavy lifting, automation, rapid prototyping, development, a deep learing
curve and larger gains in productivity with time. Its still the go-to tool for
most back end tasks. If you wish to get something done faster, with little
effort, sanely with little bugs in say over a weekend, You have little
alternatives apart from Perl. If you are in dev ops and you have P1 tickets
standing on your head pretty often, a tool like Perl is indispensible.

And most importantly its areas of strengths are only growing- Unicode, regular
expressions, CPAN, powerful syntax etc. If you ever get a chance Higher Order
Perl is one book you must read. It really opens your mind to elegant solution
to a range of problems.

But like every other language, you need to invest time and effort
incrementally to keep yourself updated.

~~~
einhverfr
I started in 2003 or so, and got into it more seriously because I ended up
with customers to support using Perl software. Perl is an amazing language,
and with many modern perl approaches, it's wonderful.

This being said like most frameworks it is extremely important to know when to
leave the framework or leave things out. While I LOVE working with Moose, my
own projects are very heavily stored procedure centric and therefore an ORM
like DBIx::Class really does me very little good. DBIx::Class by all reports
is an excellent ORM but it's still an ORM. ;-)

There is no better glue language I have ever encountered than Perl We use it
in LedgerSMB to glue together stored procedures, web templates (in Template
Toolkit), and the web server interfaces. It's a wonderful language and I can't
recommend it highly enough.

As for Perl 6, it has joined HURD 1.0 as one of those projects that will be
released when pigs fly. I suspect that Perl 5.x will be as far as Perl gets.

~~~
mst
David Wheeler (theory) started working on a stored procedure centric project a
while back and as a result extracted the DBIx::Class connection logic into
DBIx::Connector - which I have a feeling you're already using.

I spent a fair amount of time hanging out in #ledgersmb a while back and in
spite of being the project founder of DBIx::Class, I don't think I ever felt I
had a convincing argument for using it, so honestly I'm glad you're not doing
so (if I ever come up with an O<sproc>M or something I'm sure you'll find out
:)

~~~
einhverfr
Glad to see you again.

Actually some of your recommendations are pending getting rid of old code (we
simply can't move everything to PSGI when we have the mixture of old and new
code we have, so it's CGI only for now still). However we are giving hard
thought as to the best way to do so and I expect that as we continue that
process things will become more PSGI friendly until it is just a matter of
changing one sub somewhere.

I should note you have convinced Josh Drake on the merits of DBIx::Class for
other projects though.

Finally I think it is worth noting that I think that in the 1.4 tree we've
come out (I hope) of the contageous effect of the bad SL code, and so the
coding styles which evolved so much during LSMB 1.3 are being formalized and
moved to Moose in 1.4.

------
jboggan
I started picking up Perl (as my first programming language) in 2003 while
working in a genetics lab. I used it for years on a number of bioinformatics
projects due to its strengths in tackling disparate sources of often irregular
information. Recently I've been using it for the Kaggle Facebook competition
simply because I can iterate my designs faster than in any other language. I'm
looking forward to learning a few of these more newfangled modern
appurtenances of Perl.

------
sausagefeet
I really wanted to see what Modern Perl looks like.

~~~
simcop2387
Have a look at <http://onyxneon.com/books/modern_perl/> This is from the
author of the book, there's a nice pdf preview there to show the book off and
a way to buy it.

~~~
mhd
Preview is a slight understatement, it's the full book as both pdf and epub.

It is a bit of a marketing term, though. Not many of the "modern" features are
really new to Perl, but basically rather common modules. In the case of Moose,
they do change the language use significantly, but mostly it's about showing
that Perl can be used beyond small, one-file Unix scripts. And it's been able
to do that for quite a while, the Perl 4 days are long gone.

Still, getting some new-found traction is important, and popularizing some
great CPAN modules definitely won't hurt.

------
alrondy
In perl culture, "Modern Perl" refers to bad programming by a core group of
egocentric, sanctimonious developers who are to Perl what Lennart Poettering
is to Linux.

There are now dozens of CPAN modules with names like "common::sense" and
"Modern::Perl" that provide no useful code, but introduce packaging
dependencies and administrative overhead in the name of not having to type
"use strict;" out by hand.

Modern Perl is using Moose::Any instead of just using a language that does
what you want. Modern Perl involves an average of 130 CPAN dependencies for
any give application.

Modern Perl is when perl stopped being perl and started being awful.

~~~
gatlin
I actually despise Moose as much as I despise blindly over-doing OO. To me
Modern Perl meant tackling problems in a much more Lisp-inspired way (via
lexical scoping, anonymous functions, closures, lists, etc) ... but in Perl.
Kind of like "Higher Order Perl."

I had the impression it was more a cultural shift, a renewed interest in Perl
and people wielding it much differently. There's a different CPAN web
interface[1], a lighter cli client[2], and everyone is on GitHub and writing
hundreds of tests. I guess Moose is part of that shift but I'm torn a lot of
the time - I support modern Perl but I hesitate to support blindly copying the
warts from other languages just to appear modern.

This[3] is a result of searching for common::sense ... yikes.

[1]: <http://metacpan.org> [2]: <https://metacpan.org/module/App::cpanminus>
[3]: <https://metacpan.org/module/Real::Handy>

~~~
phaylon
Personally, I think Moose' value to the community is much larger than that it
just provides good OO.

It pushed a much more declarative approach than usual, that swaps over to
other projects (Moo, Mo, even Class::Accessor supports has declarations now).
It has a community that is focused on best practices with regards to OO. It
put introspection more in the spotlight (like the idea of getting Getopt
definitions by introspecting classes).

It is also flexible, which allows for lots of extensions to its functionality.
That means a lot of concepts are tried out on CPAN already. Even if someone
doesn't use Moose, there is lots of OO knowledge to be found in the ecosystem.
Same goes for runtime type constraints/coercions.

Then there's the p5-mop project, that would provide a common core, so many of
the things above could find themselves in a much more light-weight and broadly
usable variety, with side-effects like less heavy anonymous packages.

Personally, while I'm very excited about where Perl 5 has come so far, I'm
even more excited by the things we haven't thought of yet.

------
trebuch3t
Writing a book on Modern Perl is nuts.

As the author of this post points out, there have been about twenty releases
since Perl 5.6, when the book was published. Features like the "switch" and
"state" keywords have been introduced. If you look away too quickly, another
database interface crops up, or people are doing objects differently. Perl
changes so often that writing about it is like trapping a unicorn.

It's impressive that users of a 25-year-old language are not afraid to improve
upon it (with the caveat that it stays backwards compatible). But since I
started using $OTHER_LANGUAGE I don't have to worry about keeping up to date
because language features change twice a decade.

~~~
ajross
That's a terrible straw man. Everything changes. Javascript is morphing into
this weird "Coffee" thing before our eyes. Python pushed a completely new
language and is currently supporting two of them. Even python 2.6 looks
absolutely nothing like 2.0. People fled whole-hog from perl and python to
ruby (another hardly static language) a few years ago, and most of those same
people are now retraining their brains on that JavaCoffee thing I mentioned.

C++? Yeah, brand new version out with whole new metaphors (An... rvalue
reference?! And what is that -> operator doing there?).

If you want compatibility, you have it. 15 year old perl scripts run fine on
5.14. If you want the community to not invent new stuff... dig yourself a hole
I guess.

------
gouranga
Python!

Sorry couldn't resist.

