[...]while the sites we link to below are completely unrelated to ours, we think they are worth a read, so have a look[...]…

I’ll have to check it out!

With MacRuby, Apple is making ruby a real option for writing Cocoa apps. They’ve rewritten the ruby runtime so it uses the ObjC runtime. All ruby objects are ObjC objects (NSObject), and can be passed between ruby and objc without conversion, and you can use Cocoa, callbacks, everything. But with ruby syntax.

MacRuby includes HotCocoa that gives you nice ruby ways to do many of the common things in Cocoa, like instantiating GUI objects, etc, using shorter method and constant names, easy defaults and ideomatic ruby constructs.

Ruby and ObjC play very well togther, but ruby syntax is just so much more pleasant.

stringWithFormat vs. stringByAppendingString is purely a readability issue. As far as efficiency goes ObjC is compiled and good ol’ g++ handles the efficiency part.

As far as the article goes, I think JavaScript syntax can be far more annoying than ObjC. Anon functions and closures get pretty ugly (like regex ugly).

Long names: I kind of agree about the meaningful names, but my personal opinion is that shorter names would have been better for the most commonly used items. Also, the fact that type/usage information is tacked onto every argument sometimes adds unneeded (IMHO) words.

For example, instead of stringByReplacingOccurancesOfString:withString, I would prefer something like replace:with. I know it doesn’t fit the convention of adding type and usage information to the names/arguments, but it’s not like that convention is universally followed in the first place. At the very least, couldn’t it be stringByReplacing:with?

For less commonly used classes/methods, I am fine with longer names.

As for dabbrev (and code hinting in general), it’s a life-saver, but it doesn’t help when you have a long common prefix for method names (e.g., ‘stringBy’ or ‘dictionaryBy’ or ‘NSMutable’). Maybe I am a lazier typist than most. :-)

I, too, find myself using stringWithFormat where I should probably use stringByAppendingString, but I’m bothered by the fact that I would choose one over the other over readability as opposed to picking the best method for the job. (come to think of it, stringWithFormat might be more efficient in this case, since the stringByAppendingString method would require an intermediate string to be created.. hmm…)

(defun objc-wrap-brackets (&optional count) (interactive “*p”) (backward-up-list count) (insert “[") (forward-sexp +1) (save-excursion (insert "]“)) (just-one-space))

> Long names For typing them: M-x dabbrev, for reading: I agree. However, I prefer meaningful names over arc’s or perl’s line noise.

> Strings and collections [NSString stringWithFormat: @"The file %@ could not be found", filename];

> Frankenstein – Not 100% object-oriented Well, that’s what you get if you tack on stuff to C. Ways to add new syntactic abstractions would be nice to have, I agree.

@JulesLt, as a former member of the ANSI C++ Standards Committee I’ll say that we worked very hard to allow all C programs to have equivalent meaning in C++ because we valued compatibility. We didn’t even drop support for implicit int until the ANSI C committee dropped it! However, one of the guiding principles for C++ was “as close to C as possible but no closer” and the strictness of the C++ type system meant there had to be some incompatibilities (as well as some syntactic clarifications, as I recall – it was a decade ago).

Joshua/Jules: Totally agree about the positives of Objective C. I love how dynamic it is, although as far as I can tell, it is not much different than ActionScript 3 in its balance of dynamic/static typing.

I also love using categories. Being able to extend classes in this way (similar to C# 3.0 or Ruby).

Moke.e.boy: OMeta? Never heard of it. What does it do?

Us Python programmers are still asking for “c++” rather thatn “c += 1″ thank god it’s not as ugly as your example…

Wouldn’t OMeta solve all these problems? Mini, domain specific languages….

monk.e.boy