tigretigre.com

I've been doing a lot of work in Python of late. There's a lot to like about it. List comprehensions were a bit odd to work with at first, but they have certainly grown on me. Nice baked-in laziness capabilities. However, there's something essential about Python that bars it from ever becoming my tool of choice. I have several characteristics in common with Larry Wall, among them a love of linguistics. And just as that influenced his development of the Perl language, it impacts how I view other programming languages.

A recent discussion on Slashdot brought up the question of whether or not process is killing passion in the best software developers. The original post on which the Slashdot discussion is based made some good points, in particular that process easily runs amok and enslaves those whom it purports to help. The chorus of jeers from the Anonymous Cowards soon joined in to decry all manner of process.

"Don't Repeat Yourself! Ever! Really!"

I have what might be regarded as an extreme allergy to repetition. Once in a job interview I used my desire to "end repitition in our lifetime" (hereafter "ERIOL") sorta like a campaign slogan. (My interviewer pointed out the irony of using that phrase multiple times within the interview. Sadly the techniques I will discuss here are not available in everyday speech. However, lawyers use the "hereafter" trick above all the time in contracts to define shorthands to be used throughout.)

So you've built out your unit tests with mocks and everything is looking peachy. But the next thing you know you have to extend a class here or there, tweak a little functionality. Maybe the cases that you so carefully mocked are suddenly no longer valid. Or maybe a few assumptions crept in that never really are valid in the first place. If your test suite is comprehensive enough you'll certainly catch it eventually, but possibly only after a monstrous cascade of test failures that don't make it clear where the real problem is. How can you guard against this sort of class-mock drift?

Here's a situation I often find myself in: I'm writing two routines that share essentially identical structure and differ only on a few values. The obvious DRY approach is to put the common stuff in a single subroutine and the specific stuff in two wrappers. Simple enough.

Every now and then, you want to be able to do certain things if you're inside a transaction that you wouldn't otherwise do, or conversely do some things only if you're not inside a transaction. MySQL doesn't give you a simple way to do that. You might think just checking the value of @@autocommit would do it, but no such luck, because that doesn't work if the transaction was started with start transaction (or one of its aliases, e.g. begin).

I have a love-hate relationship with Perl's scoping model. It has quite obviously grown over time so it is kind of twisted and knotted like a tree. However, all those twists and knots make it easy to climb if you know what you're doing. So lets review the different types of scope:

I just recently read Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck. Very insightful and replete with wisdom derived of experience. What just struck me though was how many of the principles relate to my ongoing study and practice of the ancient Asian strategy game of Go. Maybe there's some shared Japanese philosophy behind it all that I just happened upon.