(Warning: Happy tale that rapidly turns into a demented language-war rant.)
Based on recent experience doing more extended web dev work than I have for a while, I propose the acronym TPTOTA (pronounced tip-toe-ta), which stands for They’ve Probably Thought Of That Already. It is a virtuous consequence of decent API design by those who are actually using their API in plenty of everyday practical work, and extend their API design to solve regularly-encountered problems without compromising the API’s existing clean lines. It means that when you (the API user) encounter a fairly common task or problem in the API’s subject domain, these two lovely things happen:
- You figure that the API designers have Probably Thought Of This Already, and you’re right
- You go looking in the single most obvious place for the solution, and it’s there
… both of which allow you to relax with an Ovaltiney sigh of relief, solve the given problem in one swift move, and spend the rest of the day playing Dicewars.
Beware, however, of APIs which loudly proclaim their TPTOTA-ness yet leave you hanging. A great example: PHP. When talking to friends of mine who are fans of the language, I’d often hear praise along the lines of: “If there’s a basic bit of code you need, you just go looking, and the chances are it’s built-in already!” Well, no. Maybe I’ve just been incredibly unlucky, but in such cases I usually end up spending hours looking through a ludicrously-overgrown pile of inconsistently-named-and-signatured functions to turn up sod all. Case in point: I wanted to remove all null/zero values from an array. (At least, PHP calls it an array. I call it a hash, in more than one sense.) There are built-in array functions numbered like unto a billion. Half of them have a name starting with array_. Half (a different half, but not entirely different) take an array as first argument and single value as second, with the other half taking the reverse. To predict which order a function will use, flip a coin; it’s about as reliable a method as any.
Presumably this is all to help users write as little code as possible, but I’d rather they made it easier to write the stuff they don’t already have functions for. In order to perform the described operation, I used (as you would in most other languages) the filter – sorry, the array_filter function. And how to you provide the custom value-testing code? No, not as a function pointer or an anonymous function or a pure code block: you do it by creating a new function separately and then supplying the function’s name in a string. Hey, why don’t we just cut the compiler’s balls off while we’re at it? (After some exploration it turns out that you can supply an anonymous function with a special command that – and I am not making this up – takes the entire supplied function code as a string. Oh, PHP just loves eval, it’s the fast-and-loose hot playmate that it runs around with instead of that staid old compiler who just complained about such behaviour and kept wanting to know what the language was actually, like, doing. GAH.)
Just so you can be sure: I’ve had a postponed blog entry cooking for, oooh, a couple of years now about why PHP has thoroughly beaten Perl in the web development marketplace, and all the things it got right that Perl didn’t. PHP is, for most, a perfectly usable language that gets stuff done and with which you can sling web apps together pretty fast, and most of the time I get on with it just fine. It’s just that the committee-designed car-crash illustrated above, like some others, is the kind of stain that makes me throw things and scream.