Ashley just pointed out a recent blog entry from Wil Shipley, the niche famous author of Delicious Library, titled Frozen in Carbonite. In a nutshell he’s lamenting the lack of good APIs from Apple for some of their more fundamental but less buzzy APIs – Quicktime, the keychain & security stuff, etc. Note that I said good APIs, not explicitly Objective-C ones… while Wil has gone direct to Objective-C, his complaint is more a pragmatic one than idealist; the current C APIs take too much work. And, importantly, lack useful generic types – such as the NS-collections in Cocoa – which inherently reduce how much work and brain-space is required to use these APIs.
It’s a pretty common outcry, and even while many of the responses to that post are surprisingly hostile and/or defensive, very few disagree with the main point. Nearly everyone agrees that it’s a pain having to use these C APIs, even if they are sometimes quite well written (the Keychain API, for example). Everyone wants a nice happy bindings-compatible, KVC/KVO blob that magically wraps all these APIs into five lines of code or less. And everyone’s always issuing a call to arms – hackers of the world unite! – to fill the void with 3rd party solutions.
As someone who’s done and been doing that for some three years or so now with my Keychain Framework project, I have unfortunately a somewhat forlorn attitude on this. I didn’t have any high ideals when I set out to write the Keychain Framework; I simply wanted to use the Security framework in my Cocoa app, and as a pretty green developer I really wanted to stick to what little I knew (Cocoa) and keep away from that obsolete C stuff; that’d be obsolete in a few years anyway. So I thought.
My intention was to write a groovy little framework for my own use, then get on with the real work. Fast forward to the present; I put the code up on Sourceforge once it was relatively mature – well, one or two methods mostly worked – and have been tinkering with it since. It’s been of use to others – at various times it’s been part of Cyberduck, Photon (the author of which I noticed has copy-pasted out some code and made no attribution), and from memory Fire and/or Proteus – I can never remember which. So it’s been useful to someone other than me. And those are just the ones I can see on Google’s CodeSearch – dozens of people have contacted me over the years about it.
My hope with putting the code on Sourceforge, aside from simply getting it out there, was to get a bit of this “open source community” that was going around at the time. You know the deal – idiot A posts code to Sourceforge, then thousands more make it not suck and bring minute fame and fortune to the original author, as despotic ruler of this newly formed kingdom of whatever. Sadly (or not, perhaps), that didn’t happen. People send me the occasional bug fix – usually just the changes required to get it compile when I’m being particularly lazy about what’s in CVS – and plenty of thanks, but thus far no one has jumped up and actually significantly developed the framework, aside from myself.
Maybe there’s no demand. Given that any MacOS X program which handles authentication, authorisation or cryptography is going to have to go through the Security framework (or worse, OpenSSL), you’d think there would be…
Anyway, at WWDC this year Aaron Hillegass (of Big Nerd Ranch fame, among other credits) issued a very similar call to arms for student developers, to contribute to his “Bonzo” framework, his vision of a utopion “Misc” framework to do all that annoying glue work that the existing APIs require. Sadly, even a celebrity such as he couldn’t muster an army; as he laments in his blog over here, he received just five submissions. Whoopee. I’m sure they’re great, but quality only displaces quantity by so much…
So another rally falls by the wayside. I spoke to Aaron a little later on that day, and mentioned that at least half his suggested problem areas already had good solutions – heck, my Keychain framework knocked out quite a few all by itself – and yet I didn’t submit anything to the Bonzo framework. For two reasons – 1) I already have it all up on Sourceforge, and 2) I didn’t have the time. I wish I could say it was the former which was the prime… (remind me sometime to pen my “I’m already living four lives, I don’t need another one” rant)
So, why are there so many generals and no soldiers? I dunno; I just wanted to whine about it.
Ah-ha, no, I won’t be that mean. :) I’m not sure, but I’ll take a punt nonetheless. There’s a few factors I can see that seem to have significant influence:
- NIH (Not Invented Here). This is largely self-explanatory; far too many developers prefer to develop their own solutions to problems, rather than use an existing one (and more importantly, get in on the development of an existing one). In a lot of ways this is egomaniacal, but it can also be reinforced by situations where, for one reason or another, you do use some 3rd party solution, and end up having to do more work just to glue it in. I’ve been there – usually in a work environment where the motivation for using the 3rd party framework comes from up the hierarchy, backed with the sound justification “because” – and it’s disheartening.
- Style. I wish this wasn’t so pathetically petty, but I mean code style. Where-you-put-your-curly-braces kind of style. This is more egomania, plain and simple. I’d wager that any vaguely-experienced developer will have conflicted with someone else over code style. I’m told that in “the real world” you have big formal thousand page documents which specify exactly where the curly braces go, and You Must Follow This. I’ve actually worked in one place where there was a “coding style”, of sorts – hard wraps at 80 columns. That didn’t bother me much; I was paid for those tens of hours it took to manually reformat my code prior to each CVS check-in, so it’s much the same to me.
I remember in our group project at uni most of the group (not including me, obviously) wanted to mandate a particular code style. This push was driven partly by those who weren’t even going to do any coding. My response to that was more or less some colourful expletives, and ignorance of whatever “standard” style we supposedly adopted. Unbelievably, my code still worked with everyone else’s. Must have been dumb luck.
If you can’t handle someone putting their curly braces in a different spot to what you prefer, you should be flipping burgers, not bits.
So, now that I’ve finished that little rant, the point: In terms of 3rd party code, I’ve seen a lot of people being hesitant (myself include) in using and modifying it because of a severe clash of styles. Such clashes do force your brain to shift a gear, and can slow productivity, but in the grand scheme of things it’s an insignificant loss. The pragmatist would get over it and do what he needs to… far too many people don’t. Or worse, they write nasty shims and macro wrappers to restyle it (I myself am guilty of this, albeit a long time ago). The important thing to do, as a writer of a 3rd party API, is to make sure you use common conventions and classes (e.g. Cocoa collections), to minimise this paradigm gap. - Bad education. The standard academic course takes you through coding from “hello world” up to, maybe, something half-way interesting like a GUI app that’s basically some kind of database. You never really do anything original; it’s always just reinventing the wheel. Who hasn’t had to write a linked list class in C++ for uni? How often do you write your own generic collection class in real life? And in [undergrad] academia you very rarely use real 3rd party APIs… where’s the course having you play with OpenSSL, or X11 (properly; GTK or KDE or QT or something)? At my uni, and at least one other than I know of, the only exposure you get to significant 3rd party libraries are using those created by the lecturer, which almost always are just shit. They’re a really big discouragement, and leave strong scars on young, impressionable minds.
And then there’s the standard advice to newbies… “go out on your own and write your own app from scratch”. People, we’ve got motivated, excited, talented (albeit green) kids here, who have no real-life concerns and way too much free time… why oh why are we wasting this opportunity having them write their own crappy clone of some random app?! We should be attaching them to existing open source projects, saying “here you go, here’s an existing project with plenty of room for improvement, testing, documenting, etc”. That’s mentoring, as opposed to the former approach, which encourages unnecessary independence and disparity. - Curiosity. Let’s face it, many coders are hackers, and hackers are just too darn curious for their own good. “You’ll never properly understand how something works if you don’t do it yourself, at least once”. This often drives entirely academic forays into an area, which while fascinating for the forager, and quite useless for the world at large if these efforts aren’t original. Hackers need to find ways to satisfy their curiosity while contributing directly to existing efforts, not duplicating them.
