This is part 13 (and the final installment) of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at what comes next.
I suppose at the end of any long rumination on the past, it’s only natural to think about the future. I’ve tended to avoid pontificating on Perl’s prospects for a number of reasons, not the least of which is that I don’t have any special knowledge to share. I’m not an author of Perl books, a contributor to the Perl core, or even a particularly prolific creator or maintainer of CPAN modules.1 I don’t have any inside knowledge of Perl from hanging out with Larry, or the folks that run the Perl Foundation, or the current Pumpking (nor any past ones, for that matter). I’m just a regular Joe JAPH—admittedly one who has made his living off Perl for 17 years, well enough to support a nice house in southern California and a complement of five humans, three cats, one guinea pig, and a tank full of tropical fish, snails, and shrimp—but just a working schmoe nonetheless, whose opinion isn’t any better or smarter or wiser or more likely to be true than yours. So, you should definitely not listen to me.
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.1 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.2 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.
In the meantime, if you’re interested in a rerun, I was just talking to a co-worker about my (much shorter) series on agile development over on my ="http://baref…
This is part 11 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at trade-offs in expressivity.
Last week I told a story about a CS professor who was inexplicably afraid of recursion. Other than the obvious moral of “don’t be afraid of things that use underlying complexity to make your external code simpler,”1 what exactly does this have to do with Perl?
We’re programmers. Nearly every single decision we make involves a trade-off of some sort. This way will be more efficient, but harder to maintain. This algorithm will be faster, but use more memory. This piece of software is more widely used, and therefore easier to find people to work on it, but feature-wise it sucks ass and can’t hold a candle to this other piece of software, which is dead brilliant but almost entirely undocumented and nobody’s ever heard of it. If we upgrade, we risk introducing bugs and downtime from weird backcompat issues; if we don’t, we risk becoming outdated, insecure, and left behind in the marketplace. There’s always some trade-off, and it’s our job to pick one. We don’t always pick the right one. In fact, most of the time there isn’t really a “right” one. What seems right may end up being wrong, and what’s actually right today may end up becoming wrong tomorrow. But we do the best we can. And when the benefits outweigh the consequences, that doesn’t make the consequences go away. It just means we have to learn to live with them.
This is part 10 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at DWIMmery.1
Last week we talked about the awesome productivity of Perl without really asking why it’s so good at it. For one answer to that, we’ll need to look at a new spectrum.
There are several different spectra in Perl. In fact, one of the coolest things about Larry is that he’s not only given us a cool language to play with; he’s also given us cool new ways to think about the languages we play with. Along one spectrum we have the tripartite concept of laziness, impatience, and hubris. This series has only touched on these indirectly: laziness drives the language be legible, impatience drives it to be productive, and hubris drives it to be closer to a natural language.2 Along another spectrum, we have the orthogonal concepts of manipulexity and whipuptitude, which we just discussed last week.
But there’s another spectrum to look at, which includes the twin concepts of TMTOWTDI and DWIM.3 TMTOWTDI is closely linked to context, which we covered pretty thoroughly. But what about DWIM?