Buddy Burden

This is part 12 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at how to start putting it all together.

Last week I talked about the trade-offs of DWIM, and wondered if it might be time to try to make sense of all the various parts and perspectives.  Thus, this is the end of the beginning.¹  This is the convergence of all my reminiscences.

Within the past year, I started a new job, again.  This is something that many of us programmers do on a semi-regular basis.²  When you first start a new job, you spend a few days or a few weeks or a few months figuring out what’s going on.  Part of this is learning new concepts, new vocabulary: even if you’re working in an industry you’ve worked in before, every company accretes its own terminology over time, words and ideas that only make sense to the people who work there.  But a big part of it is learning the codebase.  This may have been growing for years—sometimes a decade or more—and it may have been touched by dozens of hands, but still there will be patterns, consistency even in the inconsistencies.  Once you’ve been working there a while, you will know this codebase in a fundamental and almost inexplicable way—there will still be plenty of code in it that you’ve never seen before, but, when you finally do see it, it’ll feel familiar.  Codebases build up character.  It’s not always a good character, but you learn to recognize it, and live with it, and even feel fond of it, in a weird sort of love-hate way.

The amount of time it takes you to get to this point varies for everyone, and isn’t really a function of how smart you are or how good you are.  I’ve known people who picked up a codebase very quickly but were massively destructive in it.  Likewise, I’ve known people who took months to become effective but then were invaluable ever after.  But what is nearly always invariant is that you will spend probably weeks, maybe months, in your learning phase, but you will spend years in your Getting Shit Done phase.  As will the next guy to come along, and the next, and the next.

When I write code that is concise and idiomatic, sometimes I am criticized.  I hear people say that I should keep it simple; otherwise, new employees will have difficulty understanding it.  To which my response is: so what?  From a business perspective, what’s more cost-effective?  Having a new employee struggle with my code for a few weeks? or having a seasoned employee easily maintain it for a few years?

This is actually something that Larry pointed out a long time ago, although he being who he is and I being who I am, he said it a lot more succinctly than I just did:

You learn a natural language once and use it many times.  The lesson for a language designer is that a language should be optimized for expressive power rather than for ease of learning. It’s easy to learn to drive a golf cart, but it’s hard to express yourself in one.³

Of course, there’s a crucial difference in what Larry said vs what I just said: Larry was talking about the language itself.  I’m talking about code written in the language.  But I contend that the principle can be extended.  Some while ago in this series,⁴ I drew an analogy to the dense technical language found in PhD theses.  Those papers are hard for people outside their particular fields to read.  Because they’re not optimized (to steal Larry’s turn of phrase) for outsiders.  They’re optimized for people who already know what all those big words mean.  And every field has its own language.  Medicine, law, mortgage banking, law enforcement, stock market analysis, golfing, art criticism, web site design, statistics, warehouse management, or playing D&D: all those things have terms that mean specific things to insiders and fly right over the heads of everyone else.  Why is that?

Because people invent words.  This is what we do, to faciliate communication.  We create a new term, that no one else but us will understand.  Anthropologically, some people believe that we do this in order to bond those in the know, to differentiate Us from Them.⁵  I don’t subscribe to this point of view.  I think the point is, you may have to look up this term the first time you see it, but, forever after that, you’re going to know exactly what is meant when you see that word, without anyone having to waste time explaining it.  Technical langauge (jargon) thus increases efficiency in communication.  The cost is a small window of ignorance.  The payoff is a lifetime of concision and precision.  That’s a pretty decent ROI.⁶

So I’m all about inventing new syntax.  New syntax is a little tough for people to grasp the first time they see it, but, once they look it up and understand it, it makes everything so much easier, both for me to express and for them to read.  And even the initial shock can be softened somewhat if you make the syntax look familiar, in the same way that Perl has always borrowed syntax from other langauges, so it looks and feels a bit homey to C coders and shell coders and awk coders and C++ coders and Smalltalk coders, all at once.  So that, when people look at your new syntax, they won’t know exactly what it means, but it will still seem vaguely familiar, so they can make a decent guess at it.  This is just like when you encounter a new word in your reading: you may need to consult a dictionary⁷ to understand the full denotation and connotation, but most likely you can make a pretty good guess based on the context.  And we all know that Perl is all about context.

In this way, new syntax actually makes code easier to read, after an initial learning curve.  Does it contribute to Perl’s reputation for inconsistency and difficulty?  Sure.  Just witness the bashing the Python folks give us.  But the point is, they’re missing the point.  The point is, consistency is overrated.  If everyone talked the same—worse, if every piece of literature was written in the same style, with the same limited vocabulary (for fear of accidentally using a word that someone might not know)—it would be harder to get our points across, not easier.  Inconsistency across the spectrum of possible programs you may write makes it possible for this codebase to be inconsistent with that one, even while it is entirely consistent with itself, and, since those two codebases are for entirely different audiences of entirely different coders working in entirely different industries, the fact that they’re entirely different from each other is a great blessing.

When I think about all the modules I want to write for CPAN one day (my dream modules, I mean: the ones that I hope to get around to one day but don’t know if I’ll ever find the time or inspiration), they’re all declarative syntax modules.  “Declarative,” meaning that I declare exactly what I mean instead of having to cobble together bits and pieces to try to imply what I mean.  As I mentioned before, this:

    package Foo;
    use Moose;

is not declarative.  This:

    class Foo
    {
    }

is declarative.  And, while I understand that there are people who dislike declarative syntax, I don’t really understand why.  It’s difficult for me to comprehend that saying exactly what I mean can ever be bad.  It’s sort of like when people describe themselves politically as being anti-progressive.  I sort of know what you’re saying, but then what does that make you? pro-stagnation?⁸

Hopefully this makes me make better sense: why I feel as I do about smartmatching, why I’m comaintainer and evangelist of Method::Signatures, why I’m willing to overlook the warts of Devel::Declare, why I consider modules such as Future and Bread::Board::Declare to be the future of Perl.⁹  But also hopefully it strikes a chord in some of you, reading this.  Perhaps some parts of Perl will now make more sense to you than they did before; perhaps some parts that you’ve always liked, you’ll now better understand why you like them.  Maybe I’ve given you new tools to help explain Perl to others and help them understand why they should like it as much as we do.  If I’ve done any of these things, I’m happy; if I haven’t, I apologize for wasting your time.  But none of that was my primary goal when I started writing this (it was just a nice side benefit).  It’s been an exploration that forced me to write down my own thoughts on why I’ve chosen Perl and stuck with it so long, and, by forcing the thoughts into verbal form and then releasing them into the world, it’s made them real in a way they weren’t when they were just half-formed thoughtlets in my head.  In that regard, it’s been successful.

Next week, in the final installment, I’ll go where I’ve feared to tread before: my thoughts on the future of Perl.