Yoz Grahame's Unresolvable Discrepancy

I came here to apologise and eat biscuits, and I'm all out of biscuits

TPTOTA

Posted: August 14th, 2006 Comments Off

(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:

  1. You figure that the API designers have Probably Thought Of This Already, and you’re right
  2. 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.

For a perfect example, take a look at the Dojo Toolkit for Javascript. I was using Dojo’s very lovely io.bind for some Ajaxy to-ing and fro-ing with the server, upon which I hit a snag with the way IE rudely insists on caching the output of most of those calls. I wondered if there was some simple technique for bypassing this problem, and a single Google search was all it took to show that it really couldn’t be much simpler. Dojo is still a way from perfect, and the documentation reflects the immaturity of the rest of the package, but so far it’s really terribly nice to work with.

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.)

And breathe.

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.


Comments are closed.

Archive

The complete list of posts lives here.

yoz's bookmarks

  • (fab) - a pure javascript DSL for building async web apps
    Beautifully simple microframework for building node.js apps.
  • They Don't Make Computer Manuals Like They Used To
    Scans of the silliest bits of the Franklin Ace manuals from the early 80s, with lots of extra employee reminiscence in the comments. As one comment says, "It’s always nice to know of companies who never forgot they were composed of people."
  • Small Basic
    Microsoft's beginner basic for kids and adults. Publishes to Silverlight for embedding in web pages. (via joel foner)
  • Fighting the Derail Since March 2009 - How to Discuss Race and Racism Without Acting Like a Complete Jerk
    A short and very worthwhile guide (via @charliejane)
  • JavaScript grid editor: I want to be Excel « Eltit Golb
    "A short list of my favorite JavaScript grid components." Decent overview of the good stuff.
  • IS THE SINGULARITY HERE YET?
    It's the page source that makes it.
  • IEEE Spectrum: IEEE Standards Board Member to Rejoin Iggy Pop and The Stooges
    Bizarre fact of the day: James Williamson, guitarist for The Stooges, went on to become VP of Technology Standards at Sony. (via reddit's "amazing facts" thread)
  • Plupload - A tool for uploading files using Flash, Silverlight, Google Gears, HTML5 or Browserplus
    "Allows you to upload files using HTML5, Gears, Silverlight, Flash, BrowserPlus or normal forms, providing some unique features such as upload progress, image resizing and chunked uploads." (via dion almaer)
  • UKI — Simple UI Kit for complex web apps
    "Uki is a fast and simple JavaScript user interface toolkit for desktop-like web applications. It comes with a rich view-component library ranging from Slider to List and SplitPane." Early days, but already very impressive and super-fast
  • Speed Tracer - Google Web Toolkit - Google Code
    "Speed Tracer is a tool to help you identify and fix performance problems in your web applications. It visualizes metrics that are taken from low level instrumentation points inside of the browser and analyzes them as your application runs." Chrome extension from Google.

yoz on twitter

    follow me on Twitter

    Meta

    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org

    Content licensed under the Creative Commons (Attribution - Share Alike) | Theme based on Clean Room by Columbia, MO Web Design