Damian Conway on Perl and its future
oreillygmt.co.uk
oreillygmt.co.uk
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. :)
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.
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?
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.
[1] http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-as...
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?
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.
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.
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 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.
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.
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.
1. http://java.sun.com/javase/6/docs/api/ 2. http://docs.python.org/library/ 3. http://perldoc.perl.org/perlmodlib.html
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.
EDIT: And your CD suggestion is a good way to get sacked.
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.
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.
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.
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.
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.)
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.
Accessing the first element of the first element of a nested array in Perl 5:
$aoa[0][0]
lol[0][0]
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.
$hash{foo}[3]{children}[2]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?).
You may find this Perlmonks discussion interesting, especially "stvn" comments: http://www.perlmonks.org/?node_id=655788
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.
Safety and correctness.
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.
(On the other hand, you got a better answer than from me when Chromatic answered. :-) )
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.
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 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.
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...)
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).
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.
You can see a list of recent uploads here: 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.
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!)