
Damian Conway on Perl and its future - draegtun
http://www.oreillygmt.co.uk/2010/05/damian-conway-on-perl-and-its-future.html
======
agentultra
_I usually say "I agree. Sad, isn't it. Ah, well."_

A wise opening anecdote. "Dead language" trolls have very little experience
and even less wit. If you bother trying to spend the time to properly refute
their arguments, they'll go off on a tangent about market share, mind share,
and other very ephemeral things. It's often easier to let them walk away
feeling right and get back to business.

Dead-language-haters are in my experience, are a vapid and eccentric lot. The
majority of them have a lot of criticism for something they have absolutely no
experience with or knowledge of. Damian does a great job of pointing this out
in the interview without being as snarky as myself. He has an infinite amount
of patience for Perl's critics it seems. I cannot count the number of times
he's had to repeat the same arguments over and over. Even with the
overwhelming amount of evidence he backs his statements with, people still
keep asking him if Perl is a dead language.

That's why I think waving them along and getting back to work is a great idea.
Let the smug weenies feel right and wear their proud little smiles as they
walk away. I'm sure their satisfaction with themselves will keep them coding
for many weeks to come. In the mean time real people with real work to do can
get back to doing what they do best. In their un-hip dead-language of choice.

Great interview, Damian. :)

------
martythemaniak
"Recently Martin Drashkov wrote "Why Perl lost It"
(<http://martin.drashkov.com/2009/11/why-perl-lost-it.html>). "

OMG, I'm famous! Now that fame is here, fortune must be right around the
corner. ;)

I wish I spent more than half an hour ranting there. I could have made a much
better argument, especially concerning new programmers and Perl.

~~~
rubashov
> neither Perl5 nor Perl6 seem to offer much for developers

Saying that Perl 6 offers nothing is just ridiculous. If a fast and solid
implementation appeared today it would blow the competition out of the water.

~~~
prog
I am quite excited about Perl 6 features (not a fan of the syntax though ...
coming from Python). While I enjoy Python, I would actually consider using
Perl 6 because of features like macros, regex etc. I am not sure if Perl 6 has
TCO. However, I would be a little bit concerned about using Perl 6 (rakudo) in
any sort of production system before say 2013 or so considering that Parrot
has just started to add some critical pieces[1] like JIT and threads. I
suppose based on the interview Perl 6.1 would coincide with that.

[1] [http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-
as...](http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-as-target-
platform.html)

~~~
chromatic
_I am not sure if Perl 6 has TCO._

It does.

 _I would be a little bit concerned about using Perl 6 (rakudo) in any sort of
production system before say 2013 or so considering that Parrot has just
started to add some critical pieces[1] like JIT and threads._

Why? Do you use Python or Ruby or PHP now?

~~~
prog
> Why? Do you use Python or Ruby or PHP now?

Don't get me wrong. I like Parrot. Its just that IMO complex pieces like JIT,
threads and GC take some time to stabilize. So while I am all for Perl 6 being
on Parrot and Parrot seems to be quite a feature rich VM I would want to see
it used in the field for at least a year before I use it for a critical
application.

For the same reason, I would probably pick up the JIT/unladen-swallow version
of CPython (whenever it comes out) only about a year or so of being out.

At the moment I use Python quite a bit and have started to use Ruby sometimes.
No PHP. Perl 6 and Parrot appeal to me because of their feature set. As for
the syntax, I prefer Python syntax much more than Perl 5/6 but thats
subjective. I would very much want to try out Perl 6 as it brings a lot of
good stuff to the table, I think syntax would be a small price to pay for
those features.

~~~
chromatic
You don't have to use concurrency or JIT in Rakudo Perl 6 now. These systems
do take a while to stabilize, but they're not requirements for any Perl 6
applications. As for the GC, it'll always undergo tuning and experimentation.
Even so, if it doesn't work, we'll know and we'll fix it.

------
10ren
I think Perl's _market_ success came largely with the internet, and the need
for CGI script (though it was popular before then, as a sysadmin tool, it
really took off with the net). It's hard to replicate that market success,
without some similar wave (true in general; I'm not singling out perl).

Damian mentions some cool features; but I'm getting a Lisp vibe: clever people
use it, they develop cool new things with it, but it doesn't attain market
success (aka _secret weapon_ ). Damian himself is a clever guy (though you
only hear of his over-complex stuff, the 3 he mentions, using latin, haiku and
whitespace); eg. mjd too is great (<http://blog.plover.com/>) and of course
Larry. As in Lisp, these clever ideas get adopted into other languages (eg.
today, even Java has Perl-style regex).

Fitting in with this is the psychographic profile of the wish to not be
standard - to do things differently - which is great (crucial) for research
and development; but becoming less great for later stages, such as production
code.

My personal view is that both standard and non-standard are important, though
necessarily antagonistic.

~~~
elblanco
IMHO, the things that Perl really has to do are no so much the clever syntax
designs and run-times etc. which while cool to people interested in languages
and how they work, don't really allow the language itself to be used in larger
scoped work. What Perl needs is a robust standard library that supports the
kinds of things that people want to do with languages, like build interfaces,
or solid web frameworks. Even better would be retargeting Perl to other
languages, like a Perl->JS (so I can write Perl code for a browser) or
Perl->JVM (so I can build the kinds of things I need that run on the JVM)
compiler rather than building a runtime (Parrot), and re-targeting many
languages to that platform.

Don't get me wrong, Parrot and Perl 6 are all worthy efforts. But I'm not sure
they will have the kind of impact towards growth of the language and userbase
that Perl needs. Perl desperately needs better OO syntax and support for
functional programming paradigms. But syntax is syntax, libraries are what
make a language useful in today's day and age.

~~~
adam-_-
Catalyst is surely a fairly solid web framework. Moose provides a more
standard OO syntax...

~~~
elblanco
Yeah, I forgot about Catalyst true...

Moose though is an example of what should just be part of the language. I'm
glad to hear that Perl 6 will be doing some of what I want, it'll be a good
start. But Perl really really needs the kinds of things that people want to
use modern languages for. It's still so geared for processing data files (of
various sorts), and most of what I see in Perl 6 seems to target this problem
in various ways.

Don't get me wrong, Perl is my preferred language, I can crank out a Perl
solution to a problem about as fast as I can type it. But when I really want
to push the project larger, the language doesn't really do much to help you.

------
loewenskind
"The lady doth protest too much, methinks"

If the majority of your article is spent saying "no, really! We're still
relevant, I promise!" then you should take a step back and decide if the group
you spend all your time with is bias'ing your views.

~~~
mst
When you're unable to determine the difference between "the majority of [an]
article" and "the first three questions out of eighteen" then you should take
a step back and decide if you're reading from the assumption that Perl is no
longer relevant rather than with an open mind.

------
garret
_the essential complexity of the code ... will manifest elsewhere_

By using a different language or by writing simpler code, you can avoid every
complexity mentioned, so it's not really essential complexity. And programmers
in any language can create these problems, except "the intrinsic Python OO
worldview," and maybe "weird library APIs". So this sounds like it's really
just a criticism of Python.

~~~
loewenskind
I'm glad you brought this up, I had forgetten that part of the interview.
Damien's argument about complexity of data is bizarre given that, due to perls
inability to do any nested structures without using perl-refs, complex data in
perl is much more effort than in say, python.

~~~
chromatic
_...complex data in perl is much more effort than in say, python._

Accessing the first element of the first element of a nested array in Perl 5:

    
    
      $aoa[0][0]
    

Accessing the first element of the first element of a nested list in Python:

    
    
       lol[0][0]
    

Perl 5 references do sometimes produce uglier syntax, but your quibble here is
over a sigil.

~~~
loewenskind
Nested array, fine. Now try that with a hash of arrays of objects with an
array member, the 3rd element.

Python:

hash['foo'][3].children[2]

But it's instructive that you assume I'm talking about something as trivial as
an array of arrays.

~~~
chromatic
Perl 5:

    
    
      $hash{foo}[3]{children}[2]

------
jbellis
It's a little sad watching people who live in the Perl echo chamber convince
themselves that Perl use hasn't declined in the last years.

~~~
berntb
I found out something that makes life on HN better.

To avoid the [language war] trolls in stories about Perl, I mention Moose.

Since it is a better OO system than anything in the competition, they
generally go away... :-)

Edit: I really wish Lisp was the competition today, I always loved it. :-(
I've never used CLOS, but afaik Moose is directly inspired by it (MOP,
right?).

~~~
sreque
I'll trollishly bite. I just read
[http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Co...](http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Concepts.pod).
While it does look like a good library that I'd be interested in learning if
I'm ever forced to code Perl for monies again, I don't see anything special in
it that isn't in other languages or couldn't be implemented in them as a
library.

~~~
berntb
Please see draegtun's references, re MOP. (You don't like mixins in Role form?
Ah, never mind -- I have real work to do.)

~~~
sreque
What does Moose's mixins in role form give you over Ruby's mixins, or Scala's
mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple-
inheritance hierarchy ala Python or C++? I'm not going to spend a ton of time
researching, but from what I see at links like
[http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Ro...](http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Roles.podm),
it seems like a nice idea but it's certainly been done before and since in
other languages. A lot of the features like method exclusion and aliasing or
required host methods could easily be implemented in a library on top of your
favorite dynamic language as well if they don't include them natively.

The MOP looks like a necessary tool for Perl's horribly designed OO that
wouldn't be necessary for most other languages or could just as easily be
implemented as a library. Python and Ruby both have what seems to be the
equivalent of metaclasses. Most OO languages have some idea of what an
attribute is. And so on. Once again, MOP looks neat, but it's certainly not
unique to Moose.

edit: reading the MOP link more carefully, the idea of a class builder builder
is more sophisticated than I originally thought MOP was, but as the link says,
you're heading into esoteric territory at that point.

~~~
chromatic
_What does Moose's mixins in role form give you over Ruby's mixins, or Scala's
mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple-
inheritance hierarchy ala Python or C++?_

Safety and correctness.

~~~
sreque
Not sure what you mean. In Ruby, for instance, whenever a module is mixed in a
hook method on the module is called. You can enforce any safety or correctness
constraints on the parent class that you want at that point. You can easily
imagine writing a library in ruby that lets you do the same things as in Moose
in terms of correctness and safety. Similarly, you could write your own
'include' method that took extra parameters and performed the same mixin magic
Moose is doing like excluding or aliasing methods, performing special handling
of conflicting methods, etc.

My main point in all this is that, from my perspective, Moose may have a few
bells and whistles beyond the base OO features of other dynamic languages, but
these features are more 'nice to haves' than 'essentials. More importantly,
these features could also be trivially added in other languages as libraries.
Most importantly of all, none of these features is as important as starting
out with a clean, well-designed language in the first place, and Perl is
anything but clean or well-designed.

~~~
chromatic
_Not sure what you mean._

Duck typing suffers from the false cognate problem, and mixins suffer from
false cognates and potential collisions. They also do nothing to ensure type
safety or optional type-based compile-time optimizations.

 _More importantly, these features could also be trivially added in other
languages as libraries._

Non-Moose Perl 5, Tcl, Lisp-pre-CLOS, Lua, and JavaScript to some extent
demonstrate the "you can roll your own object system trivially!" fallacy,
especially when you want to use libraries written by other people. Likewise,
I'm not aware of anyone who's used roles in a serious project who wants to go
back to object systems without them.

------
pellicle
This is a great interview. I'm glad Damian took the time to answer those
questions.

------
korch
Perl _is_ dead. It's the new Lisp. I can say this as an ex-Perl hacker. But
don't get me wrong—they have their niches. I look at this matter with ruthless
practicality: code is dead the moment you write it, there is no other way! The
only thing that matters is what specific new, awesome code you're building
right now in the real world, who is using it, and what they're doing with that
code.

So what if folks are speaking a dead language like Latin on a mysterious,
magical island that may not even exist, where planes recurrently crash, where
time travel is the normal mode of being, and where the line between the living
and the dead is unclear. Great! Protect the light!

One thing about the Perl community has always bugged me, and it pops up in any
interview with any of the top Perl guys discussing Perl6. It's the notion that
Perl code exists in some sort of weird theoretical hacker-academic world,
where, like wannabe undiscovered rock stars, or an anointed Software
priesthood, they keep saying "this code would be awesome if only everybody
would come around, recognize it and then use it." Meanwhile everybody else
says "Perl is write-only line noise." If you have to operate this way, I see
it as using the wrong tool for the job—code for the living, not the dead!

/anecdotal

I do know I have no reason to go back to any version of Perl after having
moved on to Ruby/Rails. It does seem like many more people are contributing
code to newer, more bleeding-edge open source projects that have no equivalent
in Perl. Especially for the web as it exists in 2010—a lot has changed!
Grandma's CGI-style, old-school MVC framework(i.e. Catalyst+mod_perl) won't
cut it now. So if you're doing something that requires the new, and you hit up
Github or Stackoverflow to see what folks are using, the answer is never
"here's a link to CPAN for this awesome Perl module that will blow your mind,
help you finish your job, get you kudos from everybody, _and_ get you laid."
Instead it's here's the link to Github for this awesome ruby|python|javascript
code. (Please prove me wrong here!)

