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,”¹ 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.¹

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.²  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.³  TMTOWTDI is closely linked to context, which we covered pretty thoroughly.  But what about DWIM?

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

This week we look at Getting Shit Done.

Last week I pointed out that one reason I stick with Perl is because it keeps evolving, so I never seem to get ahead of it.  But that’s not the reason I switched in the first place.  And that reason is still just as true today as it was 17 years ago: Perl is the language that Gets Shit Done.

Programming in C++ was fun, and I talked a bit about some things I missed in it.  But I also mentioned the big problem with coding in C++: you’re always writing libraries.  C++ is a very high-level low-level language.  That is, it makes it easy to code just about any data structure or algorithm you can think of.  Which is pretty awesome.  If you want spend your life coding data structures and algorithms.

Whereas, in Perl, it’s also easy to write all those things ... except that you never have to.  ‘Cause, in Perl, they’re already written.