All Too Familiar

September 19, 2011

There was a post on The Guardian’s Technology Blog by Matthew Baxter-Reynolds last week. The piece couches itself as an overview of mobile platforms for the developer looking to get his or her feet wet.

Turning its attention to iOS, The Guardian cuts with broad strokes on Objective-C and Xcode (“horrendously, absolutely awful”), and then opines:

The fact is that if your day job involves sitting in Visual Studio writing C# applications, or building Java applications in Eclipse (which will be most of you — albeit not necessarily in Eclipse), when you fire up Apple’s Xcode and start building CocoaTouch applications in Objective-C you’re going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years.

Today, John Gruber replied:

Objective-C is different than C++ or Java. Xcode is different than Visual Studio or Eclipse, and Xcode 4 is very different from previous versions of Xcode. Baxter-Reynolds certainly wouldn’t be alone in saying that he doesn’t like these differences. But it’s curious to argue Apple developer tools and frameworks are deficient due to a lack of time put into them. In numerous ways, both linguistically and tools-wise, Xcode, Objective-C, and Cocoa/Cocoa Touch are the evolutionary descendants of the NeXT developer platform from 1989.

Both of them are right, and both of them are wrong. Baxter-Reynolds’ “horrendously, absolutely awful” comment is ordinary internet grandstanding (aka trolling). The iOS platform would not be where it is today if Objective-C and Xcode were horrendously awful. Part of the success of iOS is that it is the first great mobile development platform. I’d wager that Gruber is partially correct in thinking that Baxter-Reynolds’ viewpoint here is rooted in fear/dismissal of the unfamiliar.

Where Gruber is wrong, however, is in his own dismissal of Baxter-Reynolds’ argument as simple, again, fear of the unfamiliar. Before I landed my dream job writing Mac and iOS apps (at last!), I spent many years with Visual Studio writing C++ and later C#. And while Xcode has been improving by leaps and bounds, let me tell you: Microsoft has set the bar very high with Visual Studio.

Visual Studio excels in two areas: debugging and autocomplete. The Visual Studio debugger is blazing fast. Stepping through statements is super speedy, and the variables view would keep up without breaking a sweat. Xcode’s debugger has a tendency to take its time when stepping, and the variables view can be ridiculously finicky.

My perception is that part of this sluggishness has to do with gdb, and maybe lldb will help to improve this over time. If you’re thinking that debugger stepping speed is a petty thing, think again: just like responsiveness in iOS is clearly a big deal – something Apple has put a lot of energy into – so is responsiveness in a developer’s tools.

Xcode’s autocomplete has come a long, long way in the last couple years. However, it’s just not a fair fight against autocomplete with a strong typed language like C# or Java. Strong typing allows the IDE to provide fast, accurate autocomplete. With Objective-C’s dynamic typing, autocomplete becomes more of an art than a science. Additionally, the dot notation syntax of C# and Java give the IDE another leg up: the dot is the perfect cue to bring up autocomplete. Objective-C does not lend itself to this quite so easily.

As to the question of the amount of time put into Xcode versus Visual Studio, it’s worth pointing out that Apple’s Developer Tools team is almost certainly significantly smaller than Visual Studio team.

Xcode has come a long way, and it has one really amazing component – Instruments – that, as far as I know, Visual Studio doesn’t have anything close to (that isn’t a commercial add-on product). But Xcode is lacking in some key areas that can make a big difference in a developer’s perception of tool quality. I think it’s important that we, as proud Apple platform developers, are honest about that.