The first commenter's explanation of why OpenGL and OpenGLES differ is a fantastic example. JWZ simply never bothered to learn enough about the subject in the first place, but comfortably speaks about the "defining characteristics" of it.

Reminds me of a similar hubbub when he proclaimed that CSS is bullshit and decided to stick with table-based markup, this because CSS (in April of 2003), required a span inside of a h1 to replace his table-soup (to mark up just a headline), when he'd prefer just a h1. http://jwz.livejournal.com/193866.html

Being talented in programming is simply not a binary situation, which JWZ shows quite well: he might be really good at some things, I really don't know, but he is also really ignorant in some of the other things he rants about with confidence.

Basically this is saying that JWZ, or any other programmer, is as good as the APIs he memorized and has similar shelf life.

The point JWZ is making, and I think most developers past a certain number of years would sympathize with, is that a well designed API should just make sense to a decent developer. It should follow some common sense and accepted conventions that fit your past experience and allow you to figure it out the way travelers find their way around a well designed airport, or a good mechanic approaches a new engine (before software messed these up too..)

Of course it's always possible to just send developers to RTFM in order to do every minor task. If that's the criteria, all APIs are equally great as long as they have some docs, and software developers are not architects or mechanics or chefs, but well paid employees at a fast food franchise, cooking your McMuffin per the updated company manual.

The problem is that JWZ doesn't seem to consider this possibility at all; his seemingly shallow experience with OpenGL is enough for him to assume a position of insight, and his obvious conclusion is that some incompetent buffoon must have been in charge of the API which he does not feel familiar with.

Being great in any field of programming ought to teach you that things are rarely that simple. I simply think that ranting about things which you really aren't that familiar with is a trait that doesn't fit a purported expert in the field — or a purported expert in the field should be able to recognize the things he/she isn't one in.

It's 2010, and we're still innovating on how you pass color components around. Seriously?

Actually, in the first example, the MacOS code looks like the API designed by clueless interns that don't get OO. It's the same classic mistake of passing in an X and a Y instead of a Point Object from the 1st generation Java GUI library. The iPhone code does the right thing. Instead of passing around un-encapsulated data, pass around Objects instead!

    const CGFloat *rgba = CGColorGetComponents([fg CGColor]);
    CGFloat a = rgba[4]; //Crash!

    typedef struct {
        CGFloat r;
        CGFloat g;
        CGFloat b;
        CGFloat a;
    } UIRGBAColor;
    
    //...
    
    UIRGBAColor rgba = [fg rgbaComponents];

In the Point example, the API that respects encapsulation would remain the same between the 2D and 3D versions, along with any code using it. The API with un-encapsulated data would have to change at every single place in the code where a Point was passed.

(In other words, the implementation details of Point have leaked out into the system at perhaps 100's of places. Avoiding this and decoupleing ourselves from implementation is precisely why we have encapsulation in OO.)

How this applies to color is left as an exercise to the student.

This is what I'd like to hear. Cocoa has NSPoint, which is exactly what you're talking about, for points. And NSColor is already a kind of the basic object for colors. Do you really need more primitive types for this?

(Please note that I don't intend to argue, I'm asking for a better solution. Thanks!)

I still don't get the point.

Apple seem to like doing this to force developers to become familiar with a new platform. It's much the same as not providing a command line for the original Mac, hence preventing text-based programming, or indeed not allowing cross-platform dev tools to be used for apps that will be sold on the app store.

From a design perspective, I can understand why they do this. They want apps on their platform to be lovingly crafted, just as they themselves have laboured over their products. But still, it can be frustrating for devs.

Not true. Stephenson even talks about this in In The Beginning Was The Command Line. It was called MPW and provided a very Unix-like experience (Makefiles and so on). The rival was THINK Pascal, and then later CodeWarrior, which were IDEs.

And umm, of course programmers should be discouraged from falling into habits of older platforms. Otherwise the web would look like an IBM 3270 :-)

P.S. demallien is completely right. S.O.P. was to hang your code from the GUI event loop (skeleton samples provided).

I remember seeing a terminal emulator for the early Macs that allowed hooking to corporate mainframe apps. It made me very sad.

I've been working with Cocoa for years. It took me just an afternoon to port a graphics and audio application from Mac OS X to Cocoa Touch. Granted, it's a pretty simple application [1] designed for maximum cross-platform compatibility by being written in C. But jwz's Dali Clock is even simpler with the same portability goal...

In my experience the changes made in UIKit are perfectly reasonable given the constraints of the platform. In many places Apple has managed to substantially improve the experience of mixing plain-C CoreFoundation and Obj-C Cocoa by lowering the historical "impedance mismatch" between the two that still persists in AppKit. There's nothing wrong with doing an API cleanup when the opportunity for a break with the past presents itself.

[1] http://lacquer.fi/2020

What he found was that similar functionality was implemented with an arbitrarily different interface. UIKit is not exactly the same as AppKit (I think it's a little bit cleaner) and breaks AppKit code even for features that are supported on both sides.

If you're used to stable APIs and expect strong justification for changing an interface, especially when there is no apparent change for features supported or efficiency, going from AppKit to UIKit is like having someone flick vinegar off of their finger tips into your eyes.

And if you're used to being able to develop software (using other open source software) on a computer you paid for and run it on a device you paid for without having to pay again and sign a contract limiting your freedom, then it's like getting a right hook to the abdomen.

Most of AppKit just doesn't make any sense in a single-task, single-window system. They could have kept some of the classes, but what would be the point? A tiny minority of Mac apps are as simple as jwz's clock. Everything else would need rewriting anyway.

This makes no sense in the context of the examples cited. Elsewhere, maybe.

I'm only 30 now, but I'm starting to get crusty when shit changes for the sake of changing shit :)

But more, I'm disappointed that we haven't spent the effort that goes into reinventing these things every ten minutes on something more productive. There are plenty of simple things in my everyday programming work that could be automated to take less time, given the right language tools or libraries or development environment, but where it is still faster in practice to do everything the "hard" way than the "easy" way. How am I ever going to code up all my pet project ideas in a single lifetime at this rate? ;-)

http://en.wikipedia.org/wiki/Jamie_Zawinski

Additionally:

"Resist complaining about being downmodded. It never does any good, and it makes boring reading."

http://ycombinator.com/newsguidelines.html