Log in

No account? Create an account
To The Side

Ooh, I Made Coding Horror :-D

A friend just pointed out this post, to me. :-) I'm honored to be showing up on Coding Horror. :-) It's funny, because I was just thinking of adding it to my aggregator the other day.

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.

Tags: ,



Re: Agree but maybe Perl isn't alone

There is no reason for new users to use perl. There is nothing one can do in perl (including the theoretical perl 6) that can't be done in other languages and with a much simpler syntax. Perl has over 400 (!!!) keywords. A language that complex is a burden to learn and keep current with and there is just no reason to do it. Both Ruby and Python are better in this regard, but once one steps out of the scripting languages you can see how truly powerful programming can be.


Re: Agree but maybe Perl isn't alone

Actually, there's a lot of things you can do in Perl that would be very hard to do in other languages. Perl is really among the top tier of languages in terms of flexibility. Moose is a great testament to this. The fact that something so fundamental as meta-object protocols and new object system extensions that run as deep as Moose's can be strapped on in what's basically a user-contributed add-on CPAN module that has nothing to do with the core speaks volumes.

One of Perl's many powers is its uncanny ability to evolve as necessary.

Also, your comment about scripting languages is rather naive. Why don't you go read this: http://www.perl.com/pub/a/2007/12/06/soto-11.html


Re: Agree but maybe Perl isn't alone

What on earth are you talking about? Your comment shows that you know Perl and little else. Did you CLOS was just an library in LISP before it was standardized? And it goes much further then Moose can. Did you know that Lisp, Smalltalk and others the operators themselves are defined in the language, so if you come up with a new operator (e.g. switch) you can make it and have the same status as a "built in"?

By today's standards Perl is not powerful at all and anyone who knows more advanced/powerful languages will see that (if you had made this comment in 1995 it would still have been wrong, but at least not so ridiculous looking). Just to give you a hint: look at reflection. The nearest thing Perl has to real reflection is that namespace hash table thing. Even obsolete-before-they-were-finished languages like C# can do better!

As for your link, I'm not impressed. I don't find Larry a very good speaker, as he seems to often not understand the subjects he is talking about. Even when the subject is perl (like the time he talked about how Lua has a primitive OO system, then when on to describe exactly what Perl itself has)!