Aug 21 2011

I recently started on a small ruby CLI application named currently. I had heard about a testing framework called cucumber, and when I stumbled across a CLI extension called aruba I got pretty excited. Could this be a fully featured, well-kept version of my own rspec everywhere? The answer is yes. And no.

While `aruba` does a pretty good job of handling a lot of CLI app testing cases, the `cucumber` language itself is piss-poor. Here is an example.

These are `aruba`-specific, but I think you get the idea: `the exit status should be` is a language construct. You must type it that way. The capitals at the beginning of ‘sentences?’ Language construct. I feel physically gross typing this out.

This whole thing reminds me of another language which was targeted toward a ‘business-readable domain-specific language’: COBOL. This is not a coincidence, the main `cucumber` page links to a page attempting to resurrect this idea. The problem with these kinds of approaches is they patch up a superficial part of programming and ignore the real things that are hard. Learning semicolons and parenthesis isn’t the hard part. Programming is hard because the computer never does what you think it’s doing, and it’s not as simple as trying to slather on an “English” layer.

Our brains don’t have the ability to follow all that goes on in a computer simultaneously. Thus, we have a poor mental model matched to a fast machine that can outfox our mental model very easily. This is the root of the difficulty in programming. All bugs flow from this cognitive impedance mismatch, and any language or methodology which doesn’t address this will be mediocre at best or actively detrimental at worst. Admittedly, I started learning programming a long time ago and can’t place myself in that kind of mindset now — perhaps the English approximations are useful for someone grasping the workings of the machine. But I fail to see why an experienced developer would create a tool for other experienced developers with this methodology selected.