
The Perl Renaissance - fuzzix
http://lanyrd.com/2013/linuxconfau/szzxt/
======
nnq
...don't get mad for the question, but: anybody has any arguments for using
Perl instead of, let's say Python, these days? (besides the "I already know it
incredibly well" argument)

...cause the lack of an answer to such a question has only one conclusion: the
language is dying, even if this is not already happening in a visible way!

(don't get me wrong, I'm not a Perl hater, and fyi, I think the world would be
a much better place if Rasmus Lerdorf would have learned Perl and written a
nice Perl web framework instead of inventing PHP :) )

~~~
wazoox
Python significant white space. Really, that's what preventing me for ever
liking Python.

~~~
sylvinus
Opinions on Python aside, I'd never hire somebody saying something like that
at an interview, even about a language I don't like. You should really look
past petty details when evaluating any tech and come up with actual arguments.

~~~
nnq
Really, _why_? You wouldn't hire someone that has some "language aesthetic
preferences", although a bit different that the mainstream ones? He said
"preventing me for ever liking Python" not "I'll never touch it because of
this".

~~~
pyre
This is really the same as saying, "I won't work for company X because I don't
think the brackets in the C++ code should be on the following line[1]!"

[1] E.g.:

    
    
      int main() {
      }
    

vs.

    
    
      int main()
      {
      }
    

This is an apt analogy because most companies will have some sort of code
style guide that you have to follow, which doesn't make "coding at company X
where bracket placement is enforced" much different from "coding in Python
where whitespace is enforced."

I've yet to come across someone that had a severe hatred of Python due to the
significant whitespace that was a programmer I respected. The last person that
I knew (who had a visceral hatred of Python whitespace) wrote Perl code like
this:

    
    
      sub func1 { shift->func2(shift)->func3(@_) }
    

or

    
    
      sub func1 { grep { $_[0]->func2($_) } $_[0]->func3() }
    

Note: These are literally code samples with the function names changed.

I don't know any Perl programmers that would condone this sort of code. It's a
maintenance nightmare, especially since these were not one-off instances.
Seems to me that the people that have a hatred of Python's handling of
whitespace don't like being 'constrained' by their language, and are probably
happier with Ruby or Perl.

~~~
berntb
There are some problems with the whitespace in Python.

I wrote some code with lots of nameless functions as input parameters (think
JavaScript style or Ruby blocks), which of course was an _ugly pain_ to port
to Python with no multi-line lambdas.

List comprehensions is another example -- a kludge coming from that the lack
of multi instruction lambdas stop real map functions. (The fun part is that
this necessity is touted as something good, instead of admitting that it is
unnecessary complexity to learn.)

~~~
pyre
I've used both Perl and Python. When using Perl I use anonymous functions all
the time. When writing Python, I don't. There are instances where in Perl I
would use an anonymous function, but in Python I define a local function an
pass the reference. Each language has it's own style.

If you're trying to fight the language's style, then you will obviously run
into friction. I'm sure there are plenty of people coming from C/C++/Java that
think that dynamically-typed languages are unusable because type can't be
enforced at 'compile time.' Defining an anonymous function vs. a one-time use
local function is mostly a matter of style/preference[1].

    
    
      | which of course was an ugly pain to port to Python with
      | no multi-line lambdas
    

There are two things you are describing here:

1) It was a pain to name all of these anonymous blocks.

2) The idea of naming the blocks is annoying / aesthetically displeasing to
you.

#1 is just part of porting something between different languages. You would
equally run into issues porting JS and/or Ruby code to Haskell, even with
support to lambdas. #2 is just personal opinion / preference, even if it's one
that shared by many.

    
    
      | (The fun part is that this necessity is touted as
      | something good, instead of admitting that it is
      | unnecessary complexity to learn.
    

I could use the same argument to rail against statically-typed languages. "A
type system is just unnecessary complexity to learn."

[1] I welcome examples of where anonymous functions are unable to be replaced
by local functions passed by reference.

~~~
berntb
>>Ruby code to Haskell

Uh... different paradigms. The scripting languages, which we are talking about
here, are generally _very_ similar.

>> I welcome examples of where anonymous functions are unable to be replaced
by local functions passed by reference.

Where did I write "unable" -- did I disprove some Turing machine theorem and
forget about it? :-)

In this specific case it was a declarative data structure with some data next
to code. It was well suited to have a dozen or two short functions next to the
data structures.

You could rethink the whole thing and do something different in Python to keep
it readable. But among the normal languages (in the same paradigm), Python is
the odd man out, just because of the lack of multi line lambdas.

(I also gave the example of bad influences on map, etc.)

~~~
pyre

      | >>Ruby code to Haskell
      |
      | Uh... different paradigms. The scripting
      | languages, which we are talking about here,
      | are generally very similar.
    

Different languages are different, no matter how many similarities that they
have. You _are_ going to run into issues porting between languages. Expecting
anything else is setting yourself up for disappointment.

C++ and ObjC are both 'C-based', so there should be zero issues porting code
between them, right? French and Spanish are both Latin-based, so they are
practically the same language, right?

    
    
      | >> I welcome examples of where anonymous
      | >> functions are unable to be replaced by
      | >> local functions passed by reference.
      |
      | Where did I write "unable" -- did I disprove
      | some Turing machine theorem and forget about it?
      | :-)
    

Poorly worded on my part.

    
    
      | In this specific case it was a declarative
      | data structure with some data next to code. It
      | was well suited to have a dozen or two short
      | functions next to the data structures.
      |
      | You could rethink the whole thing and do
      | something different in Python to keep it
      | readable. But among the normal languages (in
      | the same paradigm), Python is the odd man out,
      | just because of the lack of multi line lambdas.
    

1\. The inclusion of multi-line lambdas in a language is what makes it
'normal'? This just seems more like a personal opinion than anything
objective. I could easily say that Ruby is the odd-man out and Perl/Python are
the 'normal' languages, because of this:

    
    
      a = 0
      if a
        puts "Evaluates to True"
      end
    

Or Perl is the odd-man-out and Ruby/Python are the 'normal' languages because
they have a GIL.

2\. If keeping the data structure and functions together was the best use-
case, then maybe Python wasn't the tool for the job. Just like I wouldn't talk
about how crappy Ruby is because it doesn't have SciPy/NumPy.

~~~
berntb
>>The inclusion of multi-line lambdas in a language is what makes it 'normal'?

All the scripting languages are very, very similar (see data structures, etc).

In short, you don't argue against my point.

My point was that Python stops multi-line lambdas for some weird purity
argument re white spaces (I haven't found any other motivation).

This hurts quite a few use cases (for a 2nd -- copy paste and automatic
indentation of code is at least more complex, and so on) and makes it
necessary to learn weird syntax (list comprehensions), which incidentally is
touted as the next coming of Christ...

And the inability to admit a wart on Python is quite typical -- didn't Guido
tell you guys to stop trolling recently, because you were getting bad
reputation..?

>> Or Perl is the odd-man-out and Ruby/Python are the 'normal' languages
because they have a GIL.

These three are all similar -- avoid threading. :-(

Not that it is relevant for my original point, either.

~~~
kbenson
> These three are all similar -- avoid threading. :-(

Perl gets a bad rep on threading because it's threads don't map to what many
people consider the strong points of threads, which is light weight processes.
Perl fails spectacularly in that regard, but if you want multi-process
programming with a standard, well understood set of primitives for IPC, it's
really quite nice. That is, the 'threads' module isn't all that great by
itself, but when paired with 'threads::shared', it's really quite nice (as
long as you are pre-spawning workers or don't require quick thread spawning).

For example, I love how locks are scope based, which makes the following
possible:

    
    
      my $local_var = do { lock($lock_var) }
    

as well as:

    
    
      {
        lock($sync_var);
        $sync_var = "start!";
        cond_broadcast($sync_var);
      }

------
mpdehaan2
I would recommend starting with MooseX::Declare instead of Moose if you are
trying to upgrade your Perl, as Moose is great above standard Perl OO but
doesn't go far enough by itself.

Previously I found that MoooseX::Method::Signatures was very slow, so I ended
up selecting Method::Signatures::Simple.

Coupled together, you end up code that looks somewhere between Ruby and Java.
It's not my first choice for a new project, but it's not a bad way to fixup an
old but large codebase.

Possible code example:

<https://github.com/mpdehaan/Elevator/>

------
oneandoneis2
Wow.. I've been using Perl heavily for the last three years and he still
managed to cram some amazingly useful stuff I didn't know into that short
talk.

Well worth watching if you still equate "Perl code" with "line noise" :)

------
jlikesp
Anything you can build in Perl, you can also build in Ruby or Python (or hell,
even PHP), so it seems rather pointless to argue any of these solutions are
superior to another.

At the end of the day the choice is largely personal preference (or company
requirement). Also, I know plenty of programmers who still earn a living
writing Perl, so it's clearly not a dead language by any stretch of the
imagination.

Personally, I would LOVE the chance to work on a Mojolicious project. IMHO
that's the best web application framework today (in any language).

------
psadri
Perl unfortunately has a bad image vs its true reality.

I think Perl / Python are interchangeable as a language choice for web scale
projects. If your biggest problem is whether to use Python vs Perl vs X, then
I say good luck to you -- you should really have more important problems to
worry about.

I'd never use ruby for a web scale project (as evidenced by the many services
solely dedicated to scaling ruby on rails apps). PHP is not really a language.

Maybe the future belongs to ECMAScript.

------
joel_perl_prog
Great talk! I've never posted before, but I'm inspired to today. Forgive me if
my code is formatted terribly this post.

I used Perl back around 2000, like everybody else, to make CGIs. Then went
away from it for a long time. But I've used Perl over the last year to create
a large DMCA takedown system, the bulk of which is spidering and analyzing web
pages for infringements. Torrent trackers, one-click file download sites, etc.

It's been a beautiful experience. The code runs quickly (for a scripting
language), and CPAN is AMAZING. I feel Perl was the best choice for this
project, and since I enjoy the language--and trust me, it's NOT line noise:
these aren't little scripts, this package-based, documented, modular software
development, the likes of which people normally associate with Java (for
instance.

I have to say I disagree with one point in that talk. I don't think there are
"too many" ways to do OO in Perl--and this sort of ties into his gripe about
"@_" and slurping in subroutine arguments, which I think is pure joy. I'm not
certain, but I think Larry Wall got this from Lisp. Please correct me if I'm
wrong on my history there.

Anyway, in one package that I use as an object, I have this code:

    
    
        #/ @param object $this    an Offense::Analyzer
        #/ @param string $event    an EVENT_x constant value
        #/ @param int $targetId    a target id
        #/ @param int $obvious    TRUE for obvious offenses, or FALSE
        #/ @param int $same    TRUE for offenses found on the same target, or FALSE
        #/ @return int    the value for the given event, or undef
        sub getEvent($$$$$) {
            my ($this, $event, $targetId) = (shift, getEventFor(shift), shift);
            my $obvious = getObviousKeyFor(shift);
            my $same = getSameTargetKeyFor(shift);
    
            return undef unless $this->hasTarget($targetId);
            $this->{'data'}{$targetId}[$obvious][$same][$event];
        }
    
    

And I supplement that code with the following convenience getters:

    
    
        sub getIgnored($$$$) { shift->getEvent(EVENT_IGNORED, @_) }
        sub getNotified($$$$) { shift->getEvent(EVENT_NOTIFIED, @_) }
        sub getQueued($$$$) { shift->getEvent(EVENT_QUEUED, @_) }
        sub getRemoved($$$$) { shift->getEvent(EVENT_REMOVED, @_) }
    

I love the convenience of being able to use the incoming arguments array in
this manner. In fact, because you explicitly pass the object reference as the
first argument to methods in Perl, I even have this:

    
    
        #/ @param object    an Offense::Analyzer
        #/ @param string    an EVENT_x constant value
        #/ @param int    a target id
        #/ @return int    the value for the given event
        sub getEventTotal($$$) {
            int(getEvent(@_, TRUE, TRUE)) +
            int(getEvent(@_, TRUE, FALSE)) +
            int(getEvent(@_, FALSE, TRUE)) +
            int(getEvent(@_, FALSE, FALSE));
        }
    

Those are not static method calls (so to speak--package sub calls), but are
object method calls. I love that convenience.

Does your fluency need to be very high for this to seem like a good idea?
Probably. And in this manner, Perl can never compete with Python. But I guess
my argument is similar to the argument a lot of Lisp dialect programmers make:
I'm an advanced user, I don't need to be babysat, I can take care of myself,
and I'm ok with exploiting the expressiveness of the language.

~~~
falsedan
why aren't you using POD for your documentation

why are you mistakenly using prototypes for function signatures

~~~
joel_perl_prog
You're right on both counts. I would never perldoc my private code...I already
don't use it for installed modules. So that's a personal preference. The
prototypes issue is spot on. They're ignored during compilation when
dispatching isn't clear ($obj->method() ... which subclass?). Most of my subs
aren't called that way, so I do get argument checking, which has saved my butt
many times, so I just make a habit of always using prototypes. They've been
useful for me: that's all I've got there. I could easily be wrong.

And that goes for my whole coding style. You could easily say it's wrong to
use "@_" the way I do, which I feel is incredibly convenient. I'm not saying
it's a best practice. Maybe it isn't. But for me, it presents no obstacle, and
I feel the code is perfectly clear. In in fact, having to enumerate every
single argument merely to pass them along, in the same order, to another
sub...to me, that seems like a terrible idea. Some people prefer that
verbosity (or clarity, if you like). I don't think it's necessary.

~~~
falsedan
fair reasons both

------
pfortuny
The fact that they "like" the language.

Not noticing it does not equal "nonexistent". Your perceptions do not describe
the whole reality.

Any turing complete language can do any job. As long as they are not
astoundingly unequal, which is not the case, people choose based on... taste.

------
ShiningRay
I'm always looking forward to Perl6, waiting for its stable version, for 10
years.

~~~
Roboprog
I think perl 5.10 and beyond kind of preempted perl 6.

Alas, perl 6 in some ways isn't even perl. Perl 6 is cool, but Larry should
have made a new name for his next hobby :-)

