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.
I don't really mind either way; the fact you went to the trouble to write the article indicated that the first stage of our marketing work - reminding the world the Perl community was still there and still cared - was complete.
Now it's time to move on; the endless debates about whether a provably growing language is "dying" aren't productive for anybody.
I'd love to see a follow up article from you decrying the features of Perl you hate the most though and describing how you think they could have been done better (or are done better in other languages) - serious technical debate is so much more interesting than "not dead!" "are dead! "not dead" "are dead!", don't you think?
> 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.
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.
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.
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.
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.
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.
> 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).
The difference is, (AFAICT) Perl 6 also aims to be easy to use for the everyone else. Damian is extremely bright and surely wishes to have (and (I think) has helped design) a language that allows him to do some frightening and epic stuff. Larry is also a very bright guy, and is very humble, and (again, AFAICT) still requires that Perl 6 make easy things easy. "Baby Perl 6" should be easy to pick up and use.
So, the only part of the Lisp vibe I'm sensing is: yes, clever people will use Perl 6 to do clever things. But also, people who just need to get their work done in a straightforward way will be using Perl 6 as well.
My prediction: Perl 6 will have a long and steady increase in use as time goes by. This is because although there's not a tremendous amount of hype, potential users will trickle in and say, "I need to do $x"; and then as usual, Perlers will come out of the woodwork with multiple ways to quickly do $x without much trouble, and bang: you've got one more Perl 6 user.
What the parent was saying, that you seem to be missing is: there's no reason for anyone to use it.
Perl5 took off because for a lot of things it appeared to be the only game in town. Today that isn't the case anywhere. For the web there is a very established PHP (I just tried to make a web store without writing any code and I REALLY didn't want to touch PHP but there are literally no other options) and a very well established Ruby/Rails. For the enterprise you have Java, C# and all the languages that run on their respective VMs.
Perl6 has no killer app (well, I would consider Parrot potentially a killer app, but thankfully that has afaik no perl requirement). Saying "but we can get stuff done fast!" holds no water anymore. So can Ruby, Python, C#, Haskell, etc., etc., etc. It's not a selling point.
EDIT: Forgot to mention, for sys admin perl6 will be competing with, among other things perl5.
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.
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.
Perl already has a large standard library, it's called the CPAN. Unlike say Python the aim of Perl's standard libraries isn't to give you a good stand-alone programming environment, it's rather to bootstrap the CPAN toolchain so that you can install these libraries.
Perl has numerous web libraries on the CPAN (Catalyst, Mojo, Dancer etc.), and if you don't like the bare-bones object system you should look at Moose.
While I think CPAN is a fantastic resource (I wish other languages had something even half as good as CPAN for a centralized repository of various libraries and other odds and ends), it's not a standard library, it's a collection of libraries. While PPM is sweet, I work on lots of systems that are not connected to the Internet, and believe me, not having a guaranteed minimum standard library can be a serious PIA. Most distros do at least come with a set of stuff installed by default, which is nice, but it also is not the same as a standard library since that loadout might change from distro to distro, or version to version.
Basically the standard Perl library are whatever functions Perl happens to have. Which, while amazing for text processing, don't help much with other needs.
Any standard library is a collection of libraries. While I get your point, mine is that different languages have different ways of handling libraries, with different tradeoffs. Perl's way is to make it really easy to get libraries over the network, instead of trying to ship a large collection of them with the core.
A standard library, I think. Is what you go look for when you need a module to solve your problem. With Java that's [1], with Python that's [2]. With PHP (until somewhat recently) that was using one of the ~1200 built-in functions.
With Perl, the place to go for libraries is the CPAN. I look at http://search.cpan.org, not `perldoc perlmodlib` if I need a library to do X.
There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.
This is exactly why perl is moving out of the big orgs (at least everyone I've worked at in the last 5 years, and I'm a contractor). Getting anything on a production system is a hastle. Using a language like python that just has most everything out of the box is much easier than something like perl where I need to make a hundred different requests to be able to do any big project.
EDIT: And your CD suggestion is a good way to get sacked.
I see and think the complete opposite on this (and I'm also a contractor).
Like a lot of things in working life it depends on where you're coming from and where you are but I find Perl much easier to maintain across multiple servers because of CPAN (especially by using internal mirrors... for eg. minicpan) than with some other languages.
> There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.
Which is pretty much what I have to resort to :(
I don't have to do this for the most part with Java or Python.
PAR is good for deployment, but obviously hard for offline development work (sometimes you just have to do the work on those machines).
Thanks for the pointer to minicpan. I might give that a shot, might save me from manually mirroring CPAN.
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.
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.
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.)
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.
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.
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).
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.
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.
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.
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.
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" :)
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.
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.
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.
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?).
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/
I'll trollishly bite. I just read 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.
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. :-) )
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..., 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.
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++?
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.
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.
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!)
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. :)