Log in

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: ,


I don't really understand the technical details, but kickass for getting recognized!
Hahaha, thanks. :-)

Any chance on getting a summary of the advantages of moose over python's oo system?

The big advantages are type checking, simple automatic creation of attributes and accessors, "roles" (much like Java's Interfaces), automatic creation of constructors, a modular system for creating defaults for attributes, "type coercion" where you can specify ways to change one type into another (for example, a string into a DateTime object) automatically when supplied to your constructor or setters, the ability to have method modifiers like "before" and "after" that run code before or after the superclass's or subclass's method, ways of "modifying" a subclass method from the superclass, and a kick-ass introspection system.

I might be missing some things, but I think that covers it pretty nicely.



Interfaces? Pah!

Roles are at least ten times as awesome as Java interfaces. See my "Composable Units of Object Behavior" weblog for more.

Re: Interfaces? Pah!

Hahaha. :-) Yes, Moose's Roles are definitely cool. :-) I just used Interfaces as the closest example that most people would understand.



Uh... besides "before" and "after" pretty much *every* modern typed OO language has what you're describing.

The absolute best OO system on the planet at the moment is Lisp's CLOS (where :before and :after came from).

I suspect Ruby could do everything mentioned here as well except for the typing part (which could easily be written as least as good as this).
Modern typed OO language. But even for things like Java, type validation is painful for custom types--I have to create whole new classes for them. With Moose it's easy.

CLOS was one of the primary inspirations for Moose, yes.

Ruby cannot do everything mentioned there, at least not as easily or as simply as Moose.



So you mean: has some features of CLOS but not all, and one has use perl to get it? No sale here. :)
It's inspired partly by CLOS, and partly by type theory and a paper on Roles., I believe.



Agree but maybe Perl isn't alone

I agree, it is difficult to figure out what best practices are in Perl. Unless you are listening and hanging around the right Perl spots. I think that happens when you have a language that is flexible and has been around a long time. It changes as the community gets smarter and more innovated.

I think Perl community is trying to figure that out and trying to make so it can evolve as styles and techniques change. But it is a tough problem to solve without putting on fuzzy pink handcuffs.

I'm not sure I would say that won't happen (isn't happening now) in the Ruby and Python communities. I see it all the time on the ruby mailing lists. "How do I do X?" then there are about a half dozen responses that come back. With different techniques (all different) but nobody worries about the "right" way... yet. Ruby might have rails for some stuff, but it has the problem of what language version, interpreter implementation, libraries, gems, packaging system, and many other things that I don't get. Basically it has many of the same problems as Perl but it doesn't become quite so obvious until your standing there. This doesn't mean that Ruby (or any others) are bad and you should choose Perl, it just means that these are complex problems for languages (all languages). I see it in javascript land all the time too.

As for the Perl community and finding contributors, in the last Perl survey most Perl coders have been Perl coding for +10 years, I think starting up another project has to be of value to them since most of them don't need more resume building experience like younger languages. Since I have a hard time believing there are lots (I'm sure there are some but not the majority) of Ruby or Python coders with that much experience. It is a lot like the Perl and Java open source boom of late 90s for some of these other languages. Also, I think the number of existing tools that exist is very high causing many people's needs to be pretty low.

Just my $.02

Re: Agree but maybe Perl isn't alone

I appreciate the $0.02. :-)

The problems you mention for Ruby are mostly just the fact that it's newer in its popularity than Perl is.

For Python, in my experience, I'd take easy_install over the cpan command line any day, although perhaps I haven't used easy_install enough to see any of CPAN's advantages.

JavaScript has its own set of practical problems, yes.

If most Perl coders have been coding for +10 years, that indicates that Perl is (a) not a choice for new programmers or (b) is not gaining enough new users.

I agree that it's unlikely there are many Python coders with 10+ years experience, though I don't think that's as important as how many there are with 1+ years of experience, since that's about how long it seems to take most people to become professionals at a language.



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)!
As I told before on CodingHorror.com I don't think that a customer cares about your code. Usability and functionality - here is the key. Anyway I had to rewrite code of my software Sitemap Writer when I changed it into Pro http://www.sitemapwriter.com/ After this, anytime I start a new project I pay attention on my code. It shouldn't be ugly and must be easy to be transformed.



Nice words about Moose.

Actually, there is a Moose implementation for JavaScript now called Joose: http://code.google.com/p/joose-js/

Shameless plug :)


Re: Joose

That is awesome!!!