learning to Program on the iPhone – a “Microsoft developer’s” POV

The blog post by Jesse Ezell complaining and to some extent bad-mouthing the iPhone development environment was making the rounds on twitter today. I was in an all-day meeting, so it made perfect reading material for when I just needed to zone out of the current conversation for a bit. (I don’t know how anyone really expects to really focus on a conversation among 7 people for 7 hours in a single day. I think we did pretty well though – at least in terms of “getting stuff done”.)

Anyway, the “in a meeting” venue was probably good, as I couldn’t just slap down the iPhone and start raving about how this guy is myopic, unwilling to learn, and just plain wrong a few counts. The comments on his blog weren’t horrifically nasty, I was pleased to see. A few snide comments about him not understanding how to invoke the code completion mechanism – but really pretty tame. He corrected his post, actually, with the detail of how to invoke it.

So having to shove the content into the back of my head for a day before writing anything about it, I came away with some different observations:

First – there’s a whole world of programmers out there who don’t bother to learn frameworks first, but just expect to dig in with code completion and a few examples and see what works. It’s not a bad way to get hacking into something, but I’d hardly say it’s a good way to quickly learn to be an effective programmer in any setup. Jesse’s clearly used to the Visual Studio environment and metaphors, and well – the iPhone programming frameworks isn’t the same beast. I can shake my head at the first, but why he expected anything different just confuses me. If you were used to Objective-C and the frameworks and went to Visual Studio .NET programming C#, I hope you wouldn’t expect the same kind of tooling and environment.

Second – the code completion in Xcode is good, but he’s very right in that Visual Studio kicks ass in this feature when working with C# or Microsoft “understood” frameworks. (Note that interesting languages like python and ruby need not apply to this “great” feature of Visual Studio). It’s one of the reasons that I’m so interested to see what happens with CLANG out of the LLVM project. You can read the details on what clang does yourself, but for a dirty synopsis imagine a compiler-level view of code analysis.

The real win with clang and the future is that this information is available outside of clang – to, say, an IDE that would happen to build it in. Now you’ve got an IDE that isn’t using crazy regex insanity to do some code completion (very effective, that insanity – lots of systems use it for syntax highlighting) – but real, in depth parse tree understanding. Allow it to see across multiple files and think of the potential wins for dead code finding and potential common errors. That sounds to me like the engine of some serious IDE goodness. Xcode doesn’t have that now – but Apple’s tools engineers are intimately involved with the LLVM and clang project… Maybe even Jesse would think that’s pretty cool – assuming he stands the test of time and sticks with the iPhone development platform that long.

Third – even though everyone wants to be able to develop for the iPhone in their own idiosyncratic way, why do people think that Apple is going make it available? News to folks: ain’t gunna happen. They’ve got more than enough interest with a ready-made base of skilled developers (anyone having done some Objective-C Mac development work in the past few years) to knock out great applications. Add on top of that the iPhone, while a impressively powerful system, isn’t as powerful as the desktops that we currently drive to 110% CPU utilization running Flash or Silverlight. Face it – those pretty abstractions rely on having some CPU to burn. The iPhone has some – but not that much – to burn. Good thing the Objective-C runtime is pretty darn efficient! Fortunately, it was developed and hammered into shape back in the even-more-resource-constrained Motorola 68000 days.

Finally – why Jesse doesn’t think that freeze-dried objects for a user interface is the bomb is completely beyond me. I guess he wants to screw with the auto-code that a comparable Microsoft interface would normally generate. His comments along these lines (As far as I could tell, the interface builder doesn’t really store the interface in a useful form … the IDE appears to put the UI in some kind of resource file instead of generating something you can hand modify later) just re-iterates that he doesn’t really know how to “work with the framework”. Sounds like he’s fighting the framework every step of the way. Maybe that’s common in Visual Studio land, but even there I don’t think so.

I hope Jesse gets over the chip on his shoulder but I guess time will tell. In the meantime, fighting the frameworks and methodology for doing development on the iPhone will not help you. If you’re coming from another environment, take a deep breath and come at it expecting to learn something new. Who knows, you might even like it.