Ugly Perl: A Lesson in the Importance of Language Design

First, read David McLaughlin's Ugly Perl: A lesson in the importance of API design, and the comments. The piece itself isn't short, but it's worthwhile. The most important high level concept is near the start:

What we took away from that evaluation process is that, more than choice of programming language, more than choice of development paradigm and more than choice of development methodology, good API design is the single most important factor in how developers perceive the quality of code. Introducing the code review process to our team only confirmed this: almost every review I've taken part in has revolved around naming conventions and style rather than performance or implementation.

David's choice of jQuery as an example illustrates that point nicely. Solving a problem in an elegant way is sometimes compelling enough that people will switch technologies, even if there are other drawbacks. (I admire how little effort it takes to deploy a PHP application, and how little code you have to write to create a CRUD application in Ruby on Rails. There may be big flaws in both approaches beyond that point, but each technology solves one problem in an elegant way.)

The opposite argument also applies. A solution which looks clunky may turn off people:

package MyDatabase::Main;
use base qw/DBIx::Class::Schema/;
__PACKAGE__->load_namespaces;

1;

One of my favorite modules is CLASS. It's really simple and really stupid, but look how much prettier that code sample is:

package MyDatabase::Main;
use CLASS;

use base 'DBIx::Class::Schema';
CLASS->load_namespaces;

1;

Okay, I also replaced the bletcherous qw// syntax with something less syntactically noisy, but isn't CLASS easier to read than __PACKAGE__? What if my class patch had been accepted?

class MyDatabase::Main is DBIx::Class::Schema
{
    use CLASS;
    CLASS->load_namespaces;
}

None of this is rocket science. It's barely any work modifying the Perl 5 parser (at least once you accept that sometimes adding features is worth the pain of telling people with 15 year old code that they have to add a single line to make it forward compatible). The changes themselves are very simple. They're surface changes. They're just syntax. The guts of Perl don't have to change at all.

Yet what a difference a little bit of syntax makes. As the first commenter on Unshortening URLs with Modern Perl wrote, "Modern Perl looks sexy!"

David's absolutely right that beauty and elegance are important to APIs. How much more important are they to languages. In my mind, that's what makes iterating languages so important: how else can you help people write beautiful code?