Alex headshot

AlBlue’s Blog

Macs, Modularity and More

ObjectivEClipse

2009, conference, eclipse, eclipsecon, iphone, mac, objectivec

I've been doing a bunch of iPhone development recently, and what struck me is how little XCode seems to have evolved since its initial inception (and it wasn't that much of a leap over Project Builder before it, either). People wax lyrical about Mac development tools, so it's interesting to see where XCode is when positioned against other languages and tools that support them. You can either read the rant, or jump to the bottom where the interesting bit is.

Back in University, I bought a NeXTstation, also affectionately known as my friends as 'a very black and very expensive way of checking my e-mail'. Not only was it a great computer (pity I could only afford the black-and-white model) but the software became the forerunner of the Macs that I work with today. Even though it only had 8Mb (my graphics card probably has more than that now!) and a 68040 on board (same as the trusty Amiga) it was the software that drove great things (not to mention the intertubes). Like the Mac that followed, Nextstep had it all under the control of one supplier, so provided magneto-optical drives, audio conferencing and everything postscript, so faxing and printing was built-in.

Nextstep left many legacies in today's Mac development kits; from the NS in NSObject to the AppKit framework that realised there was more to life than a main() method. But arguably its most important contribution is that of the development environment, which made developing, debugging and deploying applications a breeze; and free, which in the days of yore was considered unheard of. After that, I went down the Java path as it took off and my (then) company with it.

Scan forward to the present day, and what do we have? Well, other than a name change and some fancy new tools for doing analysis graphically with DTrace, basically the same tools I was working with over ten years ago. Even Interface Builder hasn't changed that much, except the astute will have noted that NIBs (Nextstep Interface Bundles) have been renamed XIBs (XCode Interface Bundles) and gone all XML on us.

Project builder has now been renamed XCode and ... well, that's pretty much it. OK, it's got Subversion support which Project Builder didn't have when it was first created; but then subversion didn't exist when Project Builder was first created either. But other than a few template differences - and more distinctly the ability to compile against different platforms (like the iPhone) - it's pretty much the same hunk as it always used to be. One might argue that it's got more functionality; but actually, that's been added by the additional frameworks (CoreData, GrandCentral etc.) rather than the tools themselves.

And developing in project builder XCode is ... painful. Which is a shame, because it was the first developer IDE I ever used, and ever since I've been moving onto bigger and better tools. About the only thing that came close to Project Builder and Interface Builder was Visual Age for Java; a much maligned and misunderstood tool due to its lack of a filesystem. Ultimately, that was what killed it — HelloWorldians were used to 'javac HelloWorld.java' and simply couldn't think in terms of classes. Even now, its direct descendant Eclipse supports a tree-based file view of your system by default (with its inability to scale much past about 20 files; Mylyn of course cuts down your project's view to about 20 files, which is why it's so popular). Those who are In The Know go to the class browser, which provides a VAJ-like view (and if you find the button, you can even make it hide everything outside the current method ... but that really is showing my age). Ironically, Mylyn doesn't tend to work so well with the class browser if only because it suffers far less than the pseudo-infinite tree of files ...

So, coming back to XCode, I expected ... well, not to have to go back ten years. PB XCode has an annoying habit of not knowing whether it's a project-based or window-based application, and seems to have slept the last millenium without hearing of the concept of tabs or simply the ability to have two files open at once in the same window side-by-side. (Emacs users, please laugh now.) It has an annoying concept of 'grouping' files (think directories but that bear no resemblance to the filing system) and an utter inability to appreciate that maybe, just maybe, Foo.h and Foo.m might be related and present them in some kind of unified node in the tree that you could flip between (c'mon! Stick a fancy flip-over animation to go between the interface and the implementation! You can do it for a dashcode widget; why not the source for that widget?).

The auto-complete is a joke. Guess which key you press? Well, congratulations if you thought Tab or Space or (heaven forbid) waiting 500ms for the box to automatically pop up. Nope, it's ESC, probably the most uselessly available key on the keyboard and with absolutely no escaping involved. (Aha, but it escapes your typing, I hear you cry ...) And even though Objective-C is a beautiful and typed language*, pressing Escape brings up every frigging possible selector in the known universe. I mean, nine out of ten targets are fully typed, and the ones that aren't (id) are usually used directly from a [Foobar alloc] call; it's a fairly safe bet that the initializer you want to run is from the Foobar class. *OK, so it's got typed and untyped objects, and it's possible to send any selector to any object; it mightNotRecognize it, but you can send anything to anyone (or to no-one, but that's nil-picking).

Refactoring? Hyperlink browsing? API documentation in a nice little pop-up hover box* when you mouse over a method? Pah. Documentation is for wusses, and for people who really absolutely want to download the complete set of 150Mb every week when someone updates a typo at Apple. (Do you know, the downloads contain not only the documentation, but source code (formatted as HTML), source code in a ZIP and source code in a DMG. Maybe it wouldn't be a 150Mb download if you didn't send the same stuff in three different - and incompatible - formats.) And let's not get into the craptastic solution of having to register just to see the iPhone documentation - it's not like the GoogleBot is ever going to sign up to develop iPhone applications, is it? No, far better that people can't find out how to do things via the intertubes. *OK, it has the research assistant. But the research assistant is always down at the pub and failing to notice what you want or being in any way useful. It's late for meetings, comes back smelling of alcohol, and bringing his mate Clippy with him.

So, what to do? Well, it just so happens that I've done the odd bit of playing around with Eclipse, implemented my own language parser and the like in the past; and I'm fairly au-fait with both Java (which is what the majority of Eclipse is written in) and Objective-C. Wouldn't it be nice if there were a way of developing Objective-C applications in Eclipse? To be able to use whatever storage provider you wanted instead of 'that one' and 'that other one'? If hyperlinking really was hyperactive and documentation was a pleasure instead of a pain? A world in which your Objective-C was really objective instead of obstinate and XCode didn't make you cross while you coded?

I propose that we create ObjectivEClipse. It could be based on CDT but with bindings to format and display Objective-C code. We could export bindings to Mylyn, stuff it in Git or Hg, and even build composite projects containing web content or other language plugins (AppleScript, I'm thinking of you). It's going to take time, it's going to take effort, and it's going to take people. Only people with all of the above need apply. Register your interest here, or in bug 68083, and let's have a beer at EclipseCon. Whilst it would probably make sense to start work in an incubation component of CDT (not the least of which is using Eclipse's infrastructure to host EPL'd code), I think we need to build up a suitable base of interested people and some demo code before we can think of doing that. In the meantime, I've created ObjectivEClipse at Google Code so those who want to play, can.

See you at EclipseCon!