What would it take for you to consider them “UNreasonably unstable?” It also sounds like a state of mind.

James:

I love Objective-C and the square brackets. I’m sure someone may be able to prove this definitively, but for every pair of square brackets you use in ObjC, you would have had a pair of parentheses in C, C++, C# and Java.

One thing I really like about ObjC is the labels on the methods. For example,

+ (NSColor *)colorWithCalibratedRed:(float)red green:(float)green blue:(float)blue alpha:(float)alpha

When using Xcode, you will be guided through each labeled argument, where you can confidently fill in each one correctly. This is clearly superior to the standard argument list of the C/C++/C#/Java function or method. While you can argue that the author of a method/function MAY supply descriptive dummy parameters, you are at the mercy of the suppliers of frameworks whether you have to refer to documentation excessively. The practice in the Cocoa world has been well-established as excellent. It is not REQUIRED to label ObjC methods, but I have yet to see an example of one that is not.

[Andrew says] You raise some good points. I don’t agree completely about the argument passing stuff – I didn’t mention it in my original post, but the use of C casting operators to declare types is another one of those annoying cognitive shifts I dislike.

Apple embracing and extending C# and Mono would be pretty nifty and would go a LONG way towards bringing more developers to the platform, and probably dramatically increase the quality of the tools at the same time.

This isn’t an inherent problem in fat binaries. It’s an issue with the suckiness of Apple’s implementation of ld. If you’re compiling things for windows x64, you’re still going to have to compile and link more than once.

The complaints you state are common with any 32-bit/64-bit hybrid system without mentioning the benefits. Such as smaller overall file sizes (localizations and resources like images don’t have to be duplicated) and a much, much better user experience like not having to worry if a binary is for one architecture or another.

As for Shipley’s code, I chose it because it had the mixture of C and Smalltalk-isms I think are typical in Objective C, not because it was or wasn’t a sterling example of best practices.

The example shown is also an evil hack. His example isn’t typical because most people using both would never dereference pointers like that. If you remove the dereferences and add error checking, it’d be far more typical.

I had a reason to try some client app development again last year and while I appreciated Objective C and Cocoa, it just felt like stepping back in time compared to the advances in server-side development.

Sadly, the Cocoa bindings for most scripting languages are incomplete and reasonably unstable (I’d contribute, but it’s not my field). I’ve also looked at Microsoft’s situation, and had a play with things like SharpDevelop, Delphi and a trial of MSVS 2005 and developing GUI apps on Windows still seems streets ahead of OS X in terms of choice.

I guess if you can get ‘into’ Objective C then OS X gives you the best of every world.. but if you want language choice, it’s poor. I’d rather knock up a Web app to run locally!

When I first came across it I loved the dynamism for constructing user interfaces. It was the first time I’d come across a real seperation between UI definition and code (nib and objective-c file) in a desktop environment. It felt leaguees ahead than Microsofts code generation approach (which its nice to see them moving away from with xaml).

Two things I dislike about the current Objective-C:

1) Memory management. The reference counting method is little better than C style new and free. And it suffers from the same amiguity in terms of who actually is responsible for doing things like incrementing the ref count etc. Sure there’s a convention but convention goes wrong.

2) The messaging syntax. Maybe I’m being picky but I really find all the square brackets an eyesore.

Its intersting what you say about Microsofts approach being simpler. In some ways it is but it feels to me like C# is the first citizen of .net and all the others are just kinda along for the ride.

[Andrew says] I completely agree that C# is the first citizen of .Net, but that doesn’t really make Microsoft’s strategy any more complicated imho.

Secondly, how are fat binaries not scalable? IIRC, on tiger 31 separate archs were supported (but that was a limitation of the devtools generating them, not the OS reading them).

[Andrew says] On fat binaries: simply that the idea of having to compile & link 2 or 3 times (which is the story today) sucks as a developer. Dong it 4 times, or 5 times, or whatever is even worse. Then there is the problem of increased application size – Flash Player for Mac is now twice as big a download as it used to be.

As for Shipley’s code, I chose it because it had the mixture of C and Smalltalk-isms I think are typical in Objective C, not because it was or wasn’t a sterling example of best practices. Besides, it was too long for my purposes even without the error checking.