I’m going to try to sound more like Andy Rooney ((I include this link because I think this already marginal reference will become incomprehensible in ten years.)) up here on this blog. Also, how about I indicate when the boooring technical notes begin and end with technical and interesting.

This is one of my favorite xkcd comics. It really speaks to my experience. Usually I can pull away before I’ve finished registering for comments. Sometimes I’m halfway through a closely reasoned argument when I realize how perfectly pointless and non-personal-goal-advancing my actions are. Then, in the worst case scenario, there I am mixing it up with the other comment-warriors. Here’s me windmilling my way through a post about dolphin killing on Japanprobe. This used to be the url for a pitched brawl in which I interjected a few uninformed comments. Etcetera.

Anyway, I thought I’d write this post at a more meta level to dissuade myself from commenting elsewhere. So here goes (technical):

Have you ever noticed that Objective-C is really, really weird? Like, they just took all the C- and C++- style conventions and changed them? Me too. And on top of that it’s compiled and you do memory management and the engineers make APIs that have objects called NSCamelCasedFactoryMethodObjectFacilitator ((Yeah, I’ve got their number all right.)). Okay, so then someone makes a script-y dynamic thing for managing the Objective-C stuff, good idea. And when designing this scripting interface they make the following language syntax design decisions:

Finally, the instruction separator is a dot, like in English sentences:
myString := ‘hello’.

The following example shows how to send a message to an object:
myString class

See, this is funny, because it’s completely different from every other programming language (( Actually, these are pretty interesting design decisions. The := assignment syntax is wack, but probably necessary for named arguments or something. The dot on the end is okay, but you’re moving the OO-messaging operator into the generally useless semicolon position. By using the space for messaging, you’re now saying “subject verbs(args)” instead of “subject.verb object, args” (in Ruby you can omit the parens for a function). )). That is all.

Umm, but there is a somewhat interesting take-away. Both Apple and Microsoft have designed really sucky APIs (in terms of intuitability rather than functionality) , compared to which GTK is fairly sane (it gets a bit clunky when dealing with “GtkIter” operations). But the MacOS developers follow Apple’s improvements of this API, cooing over the increased simplicity afforded by the new NSMakesYourToastRegistry. It’s the same with new C#/ Windows API developments. So (this is actually the interesting part) the lesson is that when people work within a “closed” development system, they lose their sense about good and bad design! ((So I sort of believe that. Mainly I’m bitter because I can’t get some code to work on MacOS.))

Here’s the idea. Closed development systems don’t get good feedback and don’t have good change mechanisms, so even very good engineers (probably Apple’s are some of the best) end up working in the dark a little. It gets all culty, because there’s an elect that makes the design decisions and a laity that passively learns the new scripture. And everyone’s straining so hard to understand what the design class hath laid down that they’re no longer perceiving the design objectively. And proprietary lock-in helps, because it leads to fatalism (“what can I do, switch to Windows?”). There are all these weird little island communities where the natives are effectively locked-in to a platform because they’ve already invested the energy to understand its weird design. This isn’t even necessarily a proprietary vs. opensource thing. There are strange over-designed opensource projects that aren’t particularly open because of this class division (and most opensource projects rely on only 1-3 main contributors, it seems). All I’m saying is that bad APIs / development languages happen when designers aren’t being influenced in the right way by the end-user developers, and I’m speculating that this has to do with particular attitudes and processes associated with proprietary code and also a kind of design elitism. I mean, doesn’t Objective-C code (as code) suck?