6 ms·

Damian Conway on Perl and its future

57 points by draegtun 16y ago

jbellis 16y ago
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 16y ago
  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 16y ago
    I'll trollishly bite. I just read http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Concepts.pod http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Co.... 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 16y ago
      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 16y ago
        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/Roles.podm http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Ro..., 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 16y ago
        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 16y ago
        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 16y ago
        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.
    - berntb 16y ago
      Sorry for being irritated in the other comment, you obviously asked serious questions out of interest. I'll try to not let the trolling whenever Perl is mentioned to get under my skin in the future. (On the other hand, you got a better answer than from me when Chromatic answered. :-) )
  - loewenskind 16y ago
    Anything in the competition, like say, CLOS? But I'll grant you that Moose is better than what a lot of other languages offer.
    - draegtun 16y ago
      Moose is heavily inspired by CLOS and its borrowed features from it including having it built on top of a meta-circular MOP: http://search.cpan.org/dist/Class-MOP/ http://search.cpan.org/dist/Class-MOP/ You may find this Perlmonks discussion interesting, especially "stvn" comments: http://www.perlmonks.org/?node_id=655788 http://www.perlmonks.org/?node_id=655788
- acg 16y ago
  Decline is different from dead. The language is not dead, less people might use it. You cannot judge the popularity of a language just from, say, the position of a web programmer. Computing is so diverse now, perl will always have an active community (it seems to me) as it is very good for certain types of problems. Funnily enough, those are the problems that is was originally designed for: not CGI. Perl is a great tool, in the tradition of the Unix command line. It is a testament to its success that is not considered to be a more powerful awk.
  - bmj 16y ago
    Perl is a great tool, in the tradition of the Unix command line. Indeed. Most of my day job programming is in C#, and I don't suspect that my employer would ever want a major product release written in Perl, but we have plenty of internal tools that are written in Perl, and new ones are always being created.
    - sigzero 16y ago
      I belong to a fairly large development shop. There is a lot of Perl development, a little Python and no Ruby. That probably doesn't snapshot the industry but the talks around the watering hole are usually Perl or Python related.
- draegtun 16y ago
  There is nothing sad about Damian Conway. I highly recommend you catch one of his many presentations and most likely you will come away feeling intensely thought provoked and definitely not "sad" :)
  - klein_waffle 16y ago
    I have seen Damian's amazing presentations and I still feel sad for what's happened to Perl since he became a strong influence. I believe he is the one who has most encouraged the tendencies which led to the Perl 6 debacle. His strong charisma has made it acceptable to have the following attitudes in the Perl 6 effort: - Actual use by mortal programmers is boring; satisfying your desire to be brilliant and clever is what matters - Complexity and obscurity are fun. Perl is good or popular because the language is complex, therefore the next version of Perl should be even more complex. Perl 6 really has nothing to do with Perl 5. It's more like those movies that say "a movie by the producers of $THING_THAT_WAS_AWESOME" which neglect to mention the script and the director are different.
    - chromatic 16y ago
      None of those attitudes drive the design of Perl 6. Why do you believe they do?
    - sigzero 16y ago
      I have thought and continue to think that Perl6 is running the VB.NET route. VB.NET had a cursory relationship to VB but they really are two different languages.
    - berntb 16y ago
      I had decided to not comment any more in this thread because the language trolls got started, but... This is what Conway is claimed to be influencing: >>- Actual use by mortal programmers is boring; satisfying your desire to be brilliant and clever is what matters [etc] Go check who wrote "Perl Best Practices". Better yet, read the book. (And please don't try arguing "REAL influence", or something...)
- mst 16y ago
  There are more CPAN authors than ever before. There are more CPAN uploads than ever before. I used to give out a couple commit bits a week to projects I'm involved in; now we've got half a dozen people with access to do that giving out at least one a week (and this in spite of the fact that we're getting at least that many new contributors through github as well). Overall Perl use may have declined, but good, effective, maintainable Perl use by people who're involved in the community is on the rise - and that's the group that I'm a part of, the people who write Perl as a robust, team-oriented, scalable production language rather than the PERL scripters of old (and my thoughts go out to the PHP and ruby communities who seem to have acquired a similar breed of idiot this time round the hype mill).
  - whopa 16y ago
    There's a lot of CPAN activity, but my impression is that a lot of it seems confined to only a handful of problem domains. There's tons of choice with date libraries, or OO frameworks, or unit test frameworks, but other languages have solutions for that too. For all the talk of CPAN being so killer, there actually isn't much there that other languages don't also have. There may be more choice in implementation of a fairly common concept, but that's the Perl way. The "aha, I'll use Perl because this CPAN module implements exactly what I want, and nobody else does" moment rarely happens.
    - expeditious 16y ago
      > There's a lot of CPAN activity, but my impression is that a lot of it seems confined to only a handful of problem domains. You can see a list of recent uploads here: http://www.cpan.org/RECENT.html http://www.cpan.org/RECENT.html > There's tons of choice with date libraries, Most everyone uses DateTime. > or OO frameworks, Nowadays choosing this one is simple: Moose > or unit test frameworks Test::More is pretty standard. > For all the talk of CPAN being so killer, there actually isn't much there that other languages don't also have. That is approximately the opposite of my experiences with the CPAN.
- prog 16y ago
  While I would choose Python (or Ruby) over Perl 5, I think Perl 6 has a lot to offer a programmer. I am just waiting for a stable release. Even if Perl 5 may have declined (can't say for sure), I think Perl 6 may change that.
loewenskind 16y ago
"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 16y ago
  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.
- mjs 16y ago
  I might have missed it, but does Conway concede at any point that there's anything he (or the Perl 6 development process) should've done differently, or better? From the interview, it seems that the last 10 years turned out as entirely as he was expecting and hoping, and that he has no regrets. He's like: "Some people think Perl is dead ... but they're so wrong I won't even bother correcting their misconception." Or: "It's taken 10 years ... but designing Python took 10 years as well, and since Python is popular, we'll be popular too." Interesting that he's now giving a date for a Perl 6 release. (6-12 months.)
pellicle 16y ago
This is a great interview. I'm glad Damian took the time to answer those questions.
martythemaniak 16y ago
"Recently Martin Drashkov wrote "Why Perl lost It" (http://martin.drashkov.com/2009/11/why-perl-lost-it.html 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 16y ago
  > 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.
  - deleted 16y ago
    [deleted]
  - prog 16y ago
    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-target-platform.html http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-as...
    - chromatic 16y ago
      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?
garret 16y ago
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 16y ago
  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 16y ago
    ...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 16y ago
      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 16y ago
        Perl 5: $hash{foo}[3]{children}[2]
10ren 16y ago
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/ 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 16y ago
  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-_- 16y ago
    Catalyst is surely a fairly solid web framework. Moose provides a more standard OO syntax...
agentultra 16y ago
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. :)
korch 16y ago
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!)

57 points by draegtun 16y ago

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 16y ago
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 16y ago
  I'll trollishly bite. I just read http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Concepts.pod http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Co.... 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 16y ago
    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 16y ago
      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/Roles.podm http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Ro..., 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 16y ago
        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 16y ago
        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 16y ago
        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.
  - berntb 16y ago
    Sorry for being irritated in the other comment, you obviously asked serious questions out of interest. I'll try to not let the trolling whenever Perl is mentioned to get under my skin in the future. (On the other hand, you got a better answer than from me when Chromatic answered. :-) )
- loewenskind 16y ago
  Anything in the competition, like say, CLOS? But I'll grant you that Moose is better than what a lot of other languages offer.
  - draegtun 16y ago
    Moose is heavily inspired by CLOS and its borrowed features from it including having it built on top of a meta-circular MOP: http://search.cpan.org/dist/Class-MOP/ http://search.cpan.org/dist/Class-MOP/ You may find this Perlmonks discussion interesting, especially "stvn" comments: http://www.perlmonks.org/?node_id=655788 http://www.perlmonks.org/?node_id=655788
acg 16y ago
Decline is different from dead. The language is not dead, less people might use it. You cannot judge the popularity of a language just from, say, the position of a web programmer. Computing is so diverse now, perl will always have an active community (it seems to me) as it is very good for certain types of problems. Funnily enough, those are the problems that is was originally designed for: not CGI. Perl is a great tool, in the tradition of the Unix command line. It is a testament to its success that is not considered to be a more powerful awk.
- bmj 16y ago
  Perl is a great tool, in the tradition of the Unix command line. Indeed. Most of my day job programming is in C#, and I don't suspect that my employer would ever want a major product release written in Perl, but we have plenty of internal tools that are written in Perl, and new ones are always being created.
  - sigzero 16y ago
    I belong to a fairly large development shop. There is a lot of Perl development, a little Python and no Ruby. That probably doesn't snapshot the industry but the talks around the watering hole are usually Perl or Python related.
draegtun 16y ago
There is nothing sad about Damian Conway. I highly recommend you catch one of his many presentations and most likely you will come away feeling intensely thought provoked and definitely not "sad" :)
- klein_waffle 16y ago
  I have seen Damian's amazing presentations and I still feel sad for what's happened to Perl since he became a strong influence. I believe he is the one who has most encouraged the tendencies which led to the Perl 6 debacle. His strong charisma has made it acceptable to have the following attitudes in the Perl 6 effort: - Actual use by mortal programmers is boring; satisfying your desire to be brilliant and clever is what matters - Complexity and obscurity are fun. Perl is good or popular because the language is complex, therefore the next version of Perl should be even more complex. Perl 6 really has nothing to do with Perl 5. It's more like those movies that say "a movie by the producers of $THING_THAT_WAS_AWESOME" which neglect to mention the script and the director are different.
  - chromatic 16y ago
    None of those attitudes drive the design of Perl 6. Why do you believe they do?
  - sigzero 16y ago
    I have thought and continue to think that Perl6 is running the VB.NET route. VB.NET had a cursory relationship to VB but they really are two different languages.
  - berntb 16y ago
    I had decided to not comment any more in this thread because the language trolls got started, but... This is what Conway is claimed to be influencing: >>- Actual use by mortal programmers is boring; satisfying your desire to be brilliant and clever is what matters [etc] Go check who wrote "Perl Best Practices". Better yet, read the book. (And please don't try arguing "REAL influence", or something...)
mst 16y ago
There are more CPAN authors than ever before. There are more CPAN uploads than ever before. I used to give out a couple commit bits a week to projects I'm involved in; now we've got half a dozen people with access to do that giving out at least one a week (and this in spite of the fact that we're getting at least that many new contributors through github as well). Overall Perl use may have declined, but good, effective, maintainable Perl use by people who're involved in the community is on the rise - and that's the group that I'm a part of, the people who write Perl as a robust, team-oriented, scalable production language rather than the PERL scripters of old (and my thoughts go out to the PHP and ruby communities who seem to have acquired a similar breed of idiot this time round the hype mill).
- whopa 16y ago
  There's a lot of CPAN activity, but my impression is that a lot of it seems confined to only a handful of problem domains. There's tons of choice with date libraries, or OO frameworks, or unit test frameworks, but other languages have solutions for that too. For all the talk of CPAN being so killer, there actually isn't much there that other languages don't also have. There may be more choice in implementation of a fairly common concept, but that's the Perl way. The "aha, I'll use Perl because this CPAN module implements exactly what I want, and nobody else does" moment rarely happens.
  - expeditious 16y ago
    > There's a lot of CPAN activity, but my impression is that a lot of it seems confined to only a handful of problem domains. You can see a list of recent uploads here: http://www.cpan.org/RECENT.html http://www.cpan.org/RECENT.html > There's tons of choice with date libraries, Most everyone uses DateTime. > or OO frameworks, Nowadays choosing this one is simple: Moose > or unit test frameworks Test::More is pretty standard. > For all the talk of CPAN being so killer, there actually isn't much there that other languages don't also have. That is approximately the opposite of my experiences with the CPAN.
prog 16y ago
While I would choose Python (or Ruby) over Perl 5, I think Perl 6 has a lot to offer a programmer. I am just waiting for a stable release. Even if Perl 5 may have declined (can't say for sure), I think Perl 6 may change that.

loewenskind 16y ago

"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 16y ago
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.
mjs 16y ago
I might have missed it, but does Conway concede at any point that there's anything he (or the Perl 6 development process) should've done differently, or better? From the interview, it seems that the last 10 years turned out as entirely as he was expecting and hoping, and that he has no regrets. He's like: "Some people think Perl is dead ... but they're so wrong I won't even bother correcting their misconception." Or: "It's taken 10 years ... but designing Python took 10 years as well, and since Python is popular, we'll be popular too." Interesting that he's now giving a date for a Perl 6 release. (6-12 months.)

pellicle 16y ago

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

martythemaniak 16y ago

"Recently Martin Drashkov wrote "Why Perl lost It" (http://martin.drashkov.com/2009/11/why-perl-lost-it.html 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 16y ago
> 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.
- deleted 16y ago
  [deleted]
- prog 16y ago
  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-target-platform.html http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-as...
  - chromatic 16y ago
    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?

garret 16y ago

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 16y ago
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 16y ago
  ...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 16y ago
    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 16y ago
      Perl 5: $hash{foo}[3]{children}[2]

10ren 16y ago

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/ 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 16y ago
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-_- 16y ago
  Catalyst is surely a fairly solid web framework. Moose provides a more standard OO syntax...

agentultra 16y ago

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. :)

korch 16y ago

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!)