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

But I’d agree with most of your criticisms – the long method names smack of an ‘IDE-only’ language (Interface Builder has been around almost as long as ObjC) – I can accept the point of view that the method names say exactly what they do, which is a big argument that experienced obj-c developers will use. I’m also a big fan of named parameters in calls, but . . . well your example says it all.

It’s a bit like comments and constants – the idea behind them is to increase code clarity, but I’ve seriously seen a programmer code constants for ONE,TWO,THREE, etc, all the way up to TEN, and reference the numbers by name, because they only understood ‘numbers should be constants’ not ‘well named constants add to code clarity’.

Which is a roundabout way of saying that for simple cases, as in the above, the shorter code is clearer, even without all the extra type information.

There was an attempt to modernise the syntax at one point, but it died, because existing developers didn’t embrace it, and any new developers only had old-style literature to refer to.

Personally – I have high hopes for increasing first-class support of other languages against the Cocoa runtime – i.e. Ruby / Python / Smalltalk / Nu / fscript. You’re still going to have the issues with the length of the Cocoa method names, but you get to work with an ‘OO only’ language rather than OO extensions.