Friday, July 3, 2009

An Exercise in Blatant Bias

I came across an interesting blog post today that purports to be a comparison of Android and iPhone development. And it is a comparison. While the author makes absolutely no claim that he is unbiased, a more fitting and less misleading title would have been A Comparison of iPhone and Android Development by Somebody Who Really, Really, Really, Really Loves Java and Doesn't Want To Be Bothered Actually Learning How to Use the Language and Tools Used in iPhone Development. Okay, I admit that that would be kind of an unwieldy title, but I can imagine a lot of people coming to this blog entry and getting a skewed view of things, so I want to provide a counter-opinion. I don't want to get into a pissing match, but some of the accusations in this posting are indefensibly wrong and tell us more about the author than the things he is comparing.

Let me put up front that I know some people will interpret my response as an attempt to say that Xcode is "better" than other IDEs. That's absolutely not what I'm trying to say. "Better" is a subjective matter. My goal is simply to counter the notion put forward in this blog post that Xcode is "shockingly bad" or that Xcode "takes away from the flow of a developer". It does take away from the flow of a developer who insists on trying to use it as if it was Eclipse or Visual Studio, but that's a flaw in the developer, not the in IDE.

But just like the original posting, this is a biased post based on my own tastes and likes, but unlike the original author, I actually have a comparable amount of experience with both of the things I'm comparing.

I think it was Jeff Atwood who said "the only intuitive interface is the nipple", and that couldn't be more true. Everything we're used to doing in computer programs - the entire paradigm is learned. That's completely true for IDEs and programming languages as well. We learn to use them, and many of us coders spend so much time in our IDE that they become second nature for us to the point where we see the way we work as natural.

One of the most common complaints I see from new iPhone and Mac developers , especially those coming from Visual Studio or Eclipse (like the author of the post linked above), is that they hate Xcode because it's missing this or that feature or it "feels dated". Only the most obstinate and stuck-in-their-ways developers continue to make those claims after working with it full-time for a year or more, however, because the problem isn't with Xcode, the problem is they were trying to do things in Xcode the way they were used to doing them in some other IDE. They were trying to bring to bear all their learned knowledge about how to program in Java or C# or Visual Basic in another IDE with different conventions than are used in coding Objective-C using Xcode.

Now, I'm not trying to say that Xcode is perfect. No IDE is perfect, and they are constantly borrowing ideas from each other. One of Xcode's virtues, in my mind, is that they haven't adopted the kitchen sink approach of trying to implement any feature that anybody thinks up. They've historically had relatively a small, focused user base, and the Xcode team has created a scalpel, not a chainsaw. Xcode is written by some really smart engineers who have to use it every day for writing C, Objective-C, and C++. They aren't using it to write VB or C# and only rarely to write Java. They have different needs and different priorities than the Eclipse team or the Visual Studio team. But to claim that Xcode is "lacking" or "bad" does those developers a grave disservice. It does not try to be everything to everyone, that is true, but it is nonetheless a great IDE for the types of development that its user base does on a daily basis.

Here's the thing. If you are constantly missing some feature from Eclipse of Visual Studio, there's a really, really good chance you are working against the grain, trying to do something based on things you think you know from another language or application framework, or that you simply haven't discovered some piece of functionality in Xcode.

David Green, the author of this blog post, make the claim that Xcode (which he has been working with for "a few months") impedes developer productivity and that it is therefore "inferior" to Eclipse, a program he's worked with day-in and day-out for twelve years. Yes, that sounds like a fair basis for comparison. "This thing I just started using isn't anywhere near as good as this thing I've been using for years and know inside and out."

You can get some insight into the thought process behind this claim from this quote:

Java is a no-brainer. I have to say that it’s nice not to have to learn a new language to target mobile. Existing skillsets don’t come easy — so reuse of expertise is worth a lot.

Now let me put out there that I have worked with Java since about 1997, which would be, what, say... twelve years? It was my bread and butter for close to ten of those years. I've also got about ten years experience with Cocoa, Objective-C and Xcode(if you include its predecessor Project Builder). So, I have some basis for comparison and let me state that my opinion of the languages and the IDE is almost exactly the opposite of Mr. Green's when it comes to mobile development of GUI applications.

For starters, Java is absolutely not a no-brainer. In fact, Java is a really, really poor choice for embedded development. Oh, I know Java has been pushed as a great choice for embedded devices for years, but it's just not.

Mobile devices are constrained resource devices. The overhead for Java runtime's memory and processor overhead is non-trivial on such a device. And "existing skillsets" may not come easy, but reuse of expertise is no good if the cost for doing so is to make poor choices. You've certainly heard the cliché "if your only tool is a hammer, every problem looks like a nail"? Well, re-read the quote above and tell me that it's not simply a restatement of that cliché as an axiom. He's stating "Java is better because I know it better", nothing more. I know both languages, and Java is a better choice for many tasks, but there's really no way you can claim that it's better for writing a GUI application on an embedded device. Or, for that matter, for writing any GUI application period.

On the other hand, Objective-C is a great choice for writing GUI applications for an embedded device. It has a runtime that provides a lot of dynamic functionality with considerably less overhead. Objective-C has far better introspection than Java and greater flexibility in terms of passing objects of different types through a responder chain without filling up your code with typecasts or constant use of godawful generics (a much-lauded hack to get around a fundamental flaw with strongly-typed static languages like Java when it comes to designing GUI applications).

Some other gems from this blog post:

One thing that really became clear to me is that Objective-C, though it may have been visionary for its time, is really a language of the '80s. Certain issues such as split header and implementation files and violation of DRY are really time-wasters, and not small ones at that.

I honestly had the opposite complaint about Java. I hated that there was only a single file per class. I hated that Java deprived me of the ability to do lots of cool things by separating out the implementation from what is advertised to other classes. I hated, for example, having to use static final variables and hated having to incur the overhead of a method call for tiny bits of functionality that could have been expressed in a precompiler macro or static inline function in another language. That's not to say that Java's approach is bad, just to say that just because it was thought of later doesn't make it inherently better. Its saves a little typing and a small amount of project clutter, but it comes at a price. Personally, I prefer having more flexibility and a few more files in my project.

Split header and implementation files provide extra functionality and the cost is relatively trivial. Navigating between header and implementation files can be accomplished with a configurable key binding. I switch back and forth regularly between header and implementation files. The key command becomes second nature after a little while and it becomes completely a non-issue. I can't even see how this would be an issue worth mentioning if you had spent a few minutes reading about Xcode's key bindings.

As far as DRY, must I really do 5 things to declare a property??

ZOMG! I have to release memory! And type in more than one place! Run for the hills!

For the record, I can implement a single property in about 20 seconds using Xcode codesense and key bindings to navigate between the header and implementation files. For those who don't type as fast, check out the excellent Accessorizer. Personally, I can't create Java getters and setters in Java using Eclipse noticeably faster.

Another thing to realize is that Objective-C has a garbage collector, and it's quite a good one at this point, but Apple has intentionally chosen not to support it on the iPhone. This isn't about a shortcoming in the language, it's about a conscious decision made to provide a better user experience. Forcing developers to take responsibility for memory means that well-written applications will be more efficient and use less memory. Sure, there's a risk of memory leaks, but there are ways to track those down, and garbage collection comes with a price. On a device like a mobile phone, that is a non-trivial price even if the garbage collector is pristine and doesn't have any memory leaks itself.

Java has a similar problem with properties, though not quite so bad — and the IDE helps you write your getter/setter.

Gosh, it's too bad we don't have anything like that in Xcode. It'd be nice if we had maybe a Design menu, or maybe some text macros for Objective-C. Or at very least, an extensible scripting architecture with provided scripts to help us write our accessors and mutators. It would be even better if we had a persistence framework that completely obviated the need for data model classes at all.

And for those who didn't catch on to my sarcasm in that last paragraph, we do have all of those with Xcode. There is a design menu with tools that help you design data model classes. Under the edit menu, there is menu item called "Insert Text Macro", with several common macros for all the languages Xcode supports, and there's also an Applescript menu with such gems as "Place Accessor Defs on Clipboard".

But, in the vast majority of situations, you don't need to actually write your setters and getters. I don't care if your IDE creates them for you, 95% of the time, those are still code clutter. I'd much rather have a property with a synthesize statement and possibly a release call than tons of cruft in my code.

We also have Core Data, which lets you design data model classes visually without ever creating an Objective-C class. Or you can create a custom subclass, but you only need to put in your custom functionality - no setters or getters unless they do something non-standard.

Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial. @synthesized getters and setters for properties with retain should not be called in these methods. So many conventions and rules to remember!

Let me translate this: "Objective-C annoys me because it doesn't use the same patterns that Java uses and it is therefore bad". Implementing correct init and dealloc methods is non-trivial? How in the world could you possibly say that? If you understand the memory management contract (a whopping four whole rules), it's both trivial and intuitive. It only seems confusing if you haven't bothered to learn one of the fundamental aspects of the language you're using, and if you haven't, well, that's really not Xcode's fault, it's yours.

Objective-C’s imports and forward-declarations (@class) are a pain

What he calls a "pain", I call "more flexible". Forward declarations and header imports are more powerful and flexible than java's import mechanism, and if you understand what they are doing, they're really not difficult or time consuming.

With iPhone on the other hand, finding the functionality that I needed was painful. Classes and methods are poorly organized

Another translation: I kept looking for functionality as if I was working in Java and didn't find things where I expected them. Personally, I find Xcode's documentation browser (especially the new one coming in Xcode 3.2 under Snow Leopard) to be more intuitive and feel like it's designed perfectly for the needs of a knowledgeable Cocoa Touch programmer. It's not surprising that it's not designed to meet the expectations of a programmer learned from using another language, other frameworks, and a different IDE.

And here are some more complaints about the "shockingly bad" Xcode:

A decent window/editor management system. XCode and it’s associated tools (debugger) like to open lots of windows. Want to open a file? How about a new window for you! Very quickly I found myself in open-window-hell. The operating system’s window management is designed for managing multiple applications, not multiple editors within an IDE. It’s simply not capable of providing management of editors in an environment as sophisticated as an IDE.

Good point. It's just too bad there's no preference for changing to a single-window, or limited-window layout, huh? Oh, wait… there is, isn't there?

A project tree view that sorts files alphabetically. Really!

Oh, god, no. Please no. You're trying to use the project tree to do the detail panel's job. Just click the node of the tree you want, then in the detail panel, sort the part of the tree you've selected however you want, alphabetically, by code size, whatever. This gives you all the power of Eclipse's horrible project tree, but let's you only work with the section of the hierarchy you are currently interested in. Believe me, this is not a shortcoming in Xcode, this is a shortcoming in the way you're working.

iPhone app developers are given a pretty good UI builder. It does a great job of showing the UI as it will actually appear. It’s flexible and can model some pretty sophisticated UIs, so I was impressed. I found that using it was a little tricky — I had to read the documentation two or three times before I could really figure out how to use it properly.

Oh no - he had to read the documentation! No developer should ever have to do that. Anyone who damns Interface Builder with faint praise like this doesn't fully understand it and thinks it's just a form builder like they've used in Eclipse or VS.

Okay, I'm done. Now I'm being a little rough on the guy. He's giving an honest opinion thinking he's helping others, and that should be lauded. The problem is he's making claims that are not just a little biased, they're outright unsupportable. Calling Xcode "shockingly bad" because you haven't taken the time to learn how it works is just ignorant.

Okay, maybe a few more quotes, because there are so many good ones.

We may see a shake-up in the mobile market, with at least 18 new Android handsets being released this year. Until that happens, iPhone will remain a market leader and developers will have to put up with XCode and Objective-C.

The iPhone "will remain a market leader" until "18 new Android handsets" are released? Did you seriously write that with a straight face? You honestly think it's the number of handsets that is holding Android back? Seriously?

But at least he finished off with a great quote:

Sure, the iPhone is great — but can you install a new Linux kernel?

And the answer is, actually, yes. But who in their right mind would want to? Linux zealotry notwithstanding, the Mach kernel is better, and truth be told, most people - even most developers - don't want to waste time having to compile and install new kernels anyway.


fbronner said...

Well said...

I have almost no experience with Eclipse, and I have acquireed a lot of experience in the last 5 years with Visual studio...Before that I used to program in Delphi.

One thing I noticed when I moved to VS, was that they are doing things quite differently then Delphi. I still believe Delphi has a better IDE then VS, and will always think so because I have spent quite a number of years with both. When I started programming on OS X 7 years ago (as a hobby), I found that the IDe is totally different not just in functionality but also in design and creation process.

It took me about 2 years programming occasionally with XCode before I managed to get my head around their way of thinking (remembering, my day job I was learning to use VS :-). But once the light turned on in my head, I have started to love it as much as I used to love Delphi. Yes, it is a very different IDE then what I was used to do. But it reminds me a lot of Delphi, not in the way they work. But that they are both VERY good tools for the language and the thought process necessary to use their platform.

So whenever you switch to a new tool, give it time.. Learn to really use it the way it was meant to use, not your way...You would not try to hammer a nail with a screwdriver...don't think Java when you are doing objective-c...

And enjoy each one for their strength...After all, they usually pay your bills...

Jeff LaMarche said...

Eclipse is a good IDE. There are things about it I don't like, but overall, it's a really good IDE for doing Java, and it's passable IDE for many other tasks, like QT programs. I'm not trying to make the point that Eclipse is bad, just that you can't compare two things if you haven't taken the time to really learn them both well and you can't have an informed opinion about an IDE after dabbling for a couple of months.

I'm a big fan of using the right tool for the job. Languages are easy to learn once you grok the concepts.

AlBlue said...


Whether or not the blog post was biased, and arguments about language distinctions beside, it's true to say that IDEs do have strengths and weaknesses over each other. Eclipse's mylyn support is very popular and its plug-ins for other SCMs than SVN have a much larger range.

In addition, XCode is a Mac-only platform, whereas Eclipse is a cross-platform IDE. In fact, having the ability to code Objective C on non-Mac platforms (possibly using GNUStep) would bring the language to a wider category of people. That's got to be a good ambition to have.


Dave Mitchell said...

Hi Jeff,

After a long long day, this post made me chuckle :)



Aaron said...

One thing Xcode lacks, as of 3.2, is a usable single-file find dialog. I'm incensed that Apple changed one of the most critical pieces of any development tool, and replaced it with something that doesn't seem to work with case-insensitive searches.

Visual Studio's find dialog sucks (and I should know: I was part of the team that owned it and the rest of the core for 3 years). Eclipse's find dialog sucks. Xcode 3.1's find dialog sucked. BUT: at least I could find what I was looking for in all three. Not so much in the newest version of Xcode.

Incidentally, Jeff, if you know how to force Xcode to revert back to the old find dialog, or how to force the new find 'strip' to do case insensitive search I'd be eternally grateful.


LKM said...

There's really no denying that Xcode lacks a lot of convenient features other IDEs like IntelliJ IDEA offer. Refactoring is still not up to snuff, for example, and writing implementations for header files or keeping header files and implementation files in sync should be less work than it is.

And I also think that header files are somewhat annoying. My source file list is basically twice as long as it could be, while half the files add no semantic information. I would prefer to not have them. By the way, if they're important to you, you can approximate them in Java using interfaces.

I think a lot of Mac and iPhone programmers are too reluctant to acknowledge the weaknesses of Xcode and Objective-C. While both are great, it's important to accept that they are not unequivocally best in class anymore, the way NeXT used to be. Not accepting this makes us look somewhat biased, and probably doesn't really help convince programmers from other platforms that they should check out Mac and iPhone programming.

Jeff LaMarche said...


I don't disagree one bit. My sole purpose was to point out that the blog post wasn't doing a real comparison, it was just a rant that Xcode wasn't Eclipse being passed off under the guise of a comparison.


I'm not a big fan of the new find dialog myself, at least when using single-window mode. I have not found a way to get it back tot he old way. I would suggest that if we all open bug reports on that feature, maybe they'll put it back.


"There's really no denying that Xcode lacks a lot of convenient features other IDEs like IntelliJ IDEA offer."

I didn't deny that there are features in other IDEs that we don't have. I do, however, think that the bulk of those features aren't particularly valuable in the Cocoa workflow and given the choice between the kitchen-sink approach, and a more conservative approach to adding new features, I prefer the latter.

Your project has twice as many sources as it needs? I'd say that Java projects have half as many as they should have. :) Seriously, though, there's a lot of power that comes from the fact that the headers are processed by the pre-compiler. It's really not hard to organize your project so that the extra files are a non-issue. Especially with iPhone projects, where a big application is going to have maybe a few hundred classes.

"I think a lot of Mac and iPhone programmers are too reluctant to acknowledge the weaknesses of Xcode and Objective-C. While both are great, it's important to accept that they are not unequivocally best in class anymore, the way NeXT used to be. "

Perhaps. But maybe, just maybe those "weaknesses" and missing features don't impact us substantially on a day-to-day basis. Not every feature has value to every developer, and a lot of the cruft in VS and Eclipse (even features I use in those IDEs) just don't add much value to the way I work in Cocoa. I agree that we're not unequivocally best of class, and I'm pretty sure I never made that point. In fact, I think I made exactly the opposite point early on in my post.

But, the rant I'm responding to didn't talk about refactoring, for example, which has gotten better of late but still trails behind other IDEs (on the other hand, I rarely need more than what we have now to be perfectly honest - maybe once a month this affects me). Instead, this rant focused on things that were, for the most part, provably wrong or else the by-product of ignorance. The post was spreading misinformation because the author was entrenched in his way of doing things. The author was expecting a new platform, language, and IDE to conform to his expectations developed from long experience using a completely different platform, language, and IDE and when it didn't, he labeled it bad. Not "not as good", not "missing a few features I'm used to". He labelled it "shockingly bad".

Chris said...

I'm definitely in the "it's all relative and based on what you're used to" camp, but I have would have a really hard time justifying Objective-C's split header/module and copious violations of DRY as anything but an annoying artifact from the 80's.

I've been using Visual Studio for years and VS2008 is the closest I've found to a really good IDE (particularly for C# and web development). I'm warming up to Xcode and IB and I blame most of my complaints on inexperience and unfamiliarity.

I think the things that makes if feel dated to me is that way back in the late 80's, NeXT came to my university and demonstrated their amazing new system for developing object oriented GUI-based apps in NeXTStep. This was was a few years before Visual Studio (or Visual Basic or even a decent version of Windows). Since then, there have been many new languages, amazing innovations in GUI design, new programming paradigms and technologies.

But when I fired up Xcode and IB for the first time, I almost immediately recognized it as being very similar to what we were demoed 20+ years ago. Spruced up and with some new features and speed and more libraries, but still Objective-C and MVC through NIB files.

alanquatermain said...

What the original article reminded me of the most was the frequent lessons from children's program 'Ni Hao Kai Lan.' In just about every episode everyone's learning something and one of them decides it's too hard & it's taking too long, so throws down their tools and sulks. Right now one of the characters did just that with some roller blades because it wasn't as easy as running.

And to put my own oar into the IDE wars, I'd have to admit that I hardly had any problems switching from VS/Metrowerks/IntelliJ etc. to Project Builder 9 years ago. They all seemed similar enough. And going through a couple of tutorials showed me everything I needed to know about how to use these tools. I mean, they're different tools aren't they? Why should we expect them to be the same as something else?

As for interface builder— it works really nicely and does exactly what you need. Something else might have a newer/different way of doing things, but just because it's newer doesn't make it better. I'll admit that I don't know of any of these new GUI design things which are better than IB, but the only ones I've heard of are more or less the same— producing XML descriptions of the layout and contents of a window/view. If anything, I've heard more stories of other toolsets implementing the same approach that IB has used since the late 80's.

Frizull said...

Great article. Having just started developement for the iPhone, I face some of the same difficulties of learning a new language.

Although your article was a great read, the real value (to me at least) were the links and comments you made regarding each "pitfall" Mr Green fell into. The "memory management contract" link was very valuable, for instance. Same thing could be applied to other comments, such as where to find the "single-window, or limited-window layout" preference.

This would turn the article into a great starting point for people having the same issues.

Thank you for all the hard work.

Mike Weller said...

Can anyone say "owned"?

MattBD said...

The part about the number of handsets for Android is a perfectly valid point. At present, Android is limited to two handsets (the G1 and the Magic) and they have relatively low market penetration. As Android comes to more phones, it will be available on more and more networks and from more and more handset manufacturers, so it's more likely people can get the Android phone they want that's right for them.
By comparison the iPhone is one handset (you could call it more, but they differ only in capacity, which is only an issue if people have enough music for a bigger one to be worth it), made by one maker, and in most countries it's only available on one network. While it could easily come to more carriers, what if someone has poor coverage from a specific carrier in their area that just happens to be the one that offers the iPhone? Or what if they don't like the tariff that carrier offers? If you want an iPhone it's tough, but with plenty of Android phones on the market then that's going to be a much more viable option. The iPhone is something of a one-size-fits-all device, while there will be an Android phone to suit most people.
Let's face it, no phone, however great, is going to be ideal for everyone on the planet, is it!
Plus, there's only one company contributing directly to iPhone OS development. While iPhone OS does make use of open-source technologies, so it does benefit from improvements to those technologies, it's utterly dependent upon Apple to develop the operating system. With the Open Handset Alliance consisting of some 50 members, that's a lot of contributors who will all be developing improvements for Android. That's where the difference will matter - if there's a load of handset manufacturers and other companies working on Android then it will improve at a much faster rate than Apple can manage on their own. For now Apple have an advantage because they had a head start over Android, but that won't last forever.
Finally, on this point - do people seriously think that other handset manufacturers are just going to roll over and die? Of course not! They're going to fight tooth and nail to hold on to every last customer that they have. Android is a great way for them to do that, so for that alone handset manufacturers are embracing it. A lot of people seem to naively assume that the likes of Motorola or Nokia are just sitting on their hands while Apple grabs market share off them. In actual fact, we can probably expect more phones that rival or even surpass the iPhone in many ways - the Palm Pre is a fantastic phone, and without the threat of the iPhone Palm probably wouldn't have produced it.

Yes, the blog post does come across as somewhat biased, but hey, we're all biased about something or other. I'll admit here that I own an HTC Magic and I love it to bits. However, I also own an iPod Touch so I think I'm in a reasonably good position to make a balanced judgement over the merits and disadvantages of each. My preference is for Android, but iPhone OS is great too. But then there are some really great things that Android can do that I couldn't see the iPhone having in a million years, such as Android Scripting Environment, which lets you run scripting languages such as Python, Lua and Ruby on the phone, and even write programs there and then on the phone and use them to add new functionality with ease(OK, that's not going to be that much use to the average user, but for geeks it's awesome).

K. A. Barber said...

It seems to me our argument here is futile.

I prefer VS but have programmed using Eclipse, XCode and a half dozen other IDEs great and small.

I consider myself a hardcore C++ developer but I also use Java and since 2005 Objective-C regularly and take pleasure in developing in other languages every chance I get.

Everyone here with any experience at all will have a similar story substituting there personal experiences.

IMHO, we are here arguing because, hate it or love it, Apple has provided a great platform, a great set of development tools/libraries, and a great market place. Great enough to bring players from other platforms to develop for and scrutinize.

I remember having/reading the same types of arguments around C++ , Java and its earlier IDEs, Qt, .NET, SOA, Web 2.0 and other technologies/computer languages. Thank god for variation. We would other wise have nothing interesting to talk about.

You gotta love it. Oh and long live zealotry etc.....

SquidBot said...

I agree with most of your points, and much of the original article is wrong. One thing he does bring up though that I agree with is that the XCode debugger is sub-par. Primarily this is because it is a thin wrapper over GDB and brings with it all the limitations GDB presents. I was VERY excited at WWDC to hear that they are working on replacing the GDB based debugger. I think when that happens, it will be difficult to find anything to critique XCode on versus other tools. said...

I like to thank you for this wonderful post.

I read the same blog post as you did a couple of days ago and it made me a little angry too. I thought a lot of the post, but it certainly wasn't a 'versus'.

I was so 'angry' (-angry is a bit of a strong word, but I think we've felt the same thing after reading it) at the guy that I decided not to reply on his post because I've made it a rule not to reply on such posts, they're just bad for my heart.

So again, thank you. I fully agree.

Paulo said...

I went through a similar process as David Green did, cursing Objective-C for being so unlike-C in the object oriented syntax, and Apple for not allowing iPhone developers to use Java (or any other language for that matter except C, C++, and AppleScript)

Indeed it's all a matter of personal preference and background, but for us that prefer the Java way of doing things the closer that we can get to it is to use C++ (or Objective-C++), which at least has an object oriented syntax that is less alien to us Java programmers.

Objective-C has some good features though, once we get past the strangeness. For us that have a Java background there is a new Apress book coming out called "Learn Objective-C for Java Developers". A few alpha chapters are already available for download at their website.

easco said...

I feel compelled to point out that, should you wish to organize the files in your project tree alphabetically, you can do so by simply selecting a group and choosing "Sort > by Name" from the Edit menu.

Having said that, however, most of the times sorting the project list alphabetically is not what I want. Still, if you HAVE to have your project files sorted that way, it's possible to do so :-)

igoles said...


About the scripting thing that you said, well you can actually run LUA in your iPhone if you're really interested, I know a game developer that's using it as a high level scripting language for his Game Engine.


DadGuy said...

While I agree with virtually everything you say in this post, you omit anything that he may have gotten right. So unfortunately this blog post comes off asvery similar to what he's doing -- "I know better than you and this is why x sucks". I wish you would have pointed out the things he got right as well as the things he got wrong. Would have been much more informative rather than argumentative. :/

David Green said...

Thanks for the thoughtful response to my article. It's great to see differing opinions and while I don't agree with every point you've made, there's no doubt that with more experience with XCode my comparison would have been somewhat different.

I stand corrected on some points (such as the windowing issue). I do feel however that I've got some valid complaints. For example, if the multi-window issue is so bad, why doesn't XCode default to the single window setting? Also, why does content assist provide me with suggestions that are outright wrong and fail to provide so many other valid suggestions?

I find it interesting that many people have read my article as an inaccurate rendition of truth that must be refuted, rather than as a rendition of my personal experience. It's also strange to me that critics of my article seem to have missed many of the positive aspects of iPhone development mentioned in the article.

There's no doubt that developers are passionate about their platform and tools of choice. If we don't discuss and compare the differences then how will we ever improve?

AlBlue said...

By the way, I've dropped ObjectivEClipse 0.2, which has Mylyn support. Clearly, it's still very early days and not able to come anywhere near to replacing Xcode yet, but it does show the kind of innovation that can happen to provide a different kind of IDE experience.

Magnum said...

filling up your code with typecasts or constant use of godawful generics (a much-lauded hack to get around a fundamental flaw with strongly-typed static languages like Java when it comes to designing GUI applications).

Point taken, but for the record, C/C++/Java have terrible static type systems. It's not strongly-typed static type systems that are at fault here, but rather the crappy C/C++/Java type systems. SML, Haskell, Ocaml, Scala, and others give you both stronger compile-time guarantees and more flexibility.

Your frustration isn't with static typing, but with the terrible C/C++/Java type systems. In the same way, dynamically typed languages shouldn't all be judged by Perl and PHP.

mihirsm said...

To me, comparing Java and Objective-C is like comparing apples and oranges. Both languages were designed and developed for a very different audience of applications.

I can live with what Xcode has to offer as of now but would love to see more features.

What really hurt me was your article was full of sarcasm. I have read many of your publications and I really respect you for all the knowledge you have. You are veteran and rookies like me look up to you. Would not have hurt to make your point respectfully and professionally. Their opinion carries value just like yours.

Sarcasm is just so third world.