Anyhow, this is my response:
Software Quality: Code vs. Interface
I actually have a lot to say on this subject. I wrote a blog post about software quality a little while ago.
I think the ideal situation is that people design their code correctly from the beginning, and also make a good user interface to go with it.
Of course, in the "marketplace" (whether it's paying customers or just free downloaders) what the program does is king. A program that works better for the user will be used by more users (barring a highly effective marketing campaign by the inferior software). Every currently successful software company knows this. Most of the code I've ever read, for any product anywhere, is horrific.
But personally, I'm more concerned with whether or not people are still going to be using my software in five years, not whether they're going to be using it right now.
The reason that Bugzilla 3.0 has so many new features and also saw about a 5x increase in downloads over any other version is that we spent three years refactoring. Before that refactoring, I think we were in real danger of being blown away by the competition.
But then, at the same time, the reason that we weren't blown away was that we added new user-visible features, not purely because we refactored.
A Bit More About Perl
Since the "problems of Perl" post, I've had the opportunity to start a brand-new project in Perl that was entirely my own, VCI. I did it in Perl because it has to interact with Bugzilla, but also because I wanted to see if using all the modern techniques of Perl development could lead to well-architected code from the start.
I found that Moose is the best object system in any language I've ever used. I find it weird that when I go to write in other languages again, I'll probably think, "Gee, I wish this had Moose." I used to think, "I'm so glad this language isn't Perl" (except when dealing with regular expressions, which are so much easier to use in Perl than in other languages). But with Moose, I just wish everything had Moose.
The problem with Perl, I think, is that the basic documentation that everybody reads doesn't say, "Okay, here's the Good Way To Do Things. Use Moose and Be Object Oriented." I had to really go out of my way and research the best way to do things in modern Perl. There are ten thousand (or more) modules on CPAN, which is great, but...there are ten thousand modules on CPAN. Thankfully we have IRC and blogs, or it'd be pretty tough to find out what the current "best" way to do things is, with Perl.
On the other hand, when you read up on Python objects, it's pretty straightforward: "Here's how you do it. This is the way. It's the only way, and if you don't like it, tough, but at least it's basically a good way." It's not as good as Moose, but it's the way that everybody does it, because it's the One True Way from the documentation. So everywhere you go, Python code is at least consistent in that respect.
So Perl isn't fundamentally flawed, but it's kind of flawed in practical terms, in the way that it's commonly used. Imagine that you had a book that taught you how to write, and then after you were done with it, somebody had to come up to you and say, "Okay, that's not really how you write. I mean, you could write that way, but everybody would laugh at you. Also, you can't use that pencil, you should use this special pen, because it makes life a lot easier." There's nothing wrong with the language you're using to write, but there is something wrong with the instructions you were given and the tools you were handed.
Now, I'm still concerned about the popularity of Perl and the ability to find new contributors. Perl has a fairly big user base right now, but I don't know that it's growing in the same way that the Ruby and Python communities are growing. With my five-year view on things, that's a real concern to me.
Because the "problems of Perl" blog post was so popular, the subject does come up again and again, and so it is something that's on my mind from time to time. Perl actually has a lot of great attributes, but unless developers broadly realize that Moose is great and that they can use DBIx::Class and Catalyst for their web applications, and the Perl community welcomes them kindly and with the understanding that they do not already know everything, I'm concerned about the future of Perl.