<?xml version="1.0" encoding="UTF-8" standalone="yes"?><oembed><version><![CDATA[1.0]]></version><provider_name><![CDATA[Important Shock]]></provider_name><provider_url><![CDATA[https://importantshock.wordpress.com]]></provider_url><author_name><![CDATA[Patrick Thomson]]></author_name><author_url><![CDATA[https://importantshock.wordpress.com/author/importantshock/]]></author_url><title><![CDATA[Five Things that Suck About Objective-C and&nbsp;Cocoa]]></title><type><![CDATA[link]]></type><html><![CDATA[<p>Things have been quiet here in this blog. Too quiet. As such, I&#8217;m keeping the name-five-things-you-hate-about-a-language-you-like ball rolling, having seen it rolled with zest and vigor by <a href="http://use.perl.org/~brian_d_foy/journal/32556?from=rss">brian d foy</a>, <a href="http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python">Titus</a>, <a href="http://www.jacobian.org/writing/2007/mar/04/hate-python/">Jacob Kaplan-Moss</a> and <a href="http://gnuvince.net/?p=373">Vincent</a>.</p>
<p>Without further ado:</p>
<p><strong>Five Things that Suck About Objective-C/Cocoa:</strong></p>
<ol>
<li>  <em>Syntax for NSString literals</em>. For the uninitiated, in Objective-C code enclosing <code>"insomnia"</code> in simple double-quotes creates a C-style char[] string; if you wish to use the far more powerful and versatile Objective-C NSString class, you must add an @ (making <code>@"insomnia"</code>). Backwards-compatibility with C is a good and useful thing, but why require more keystrokes to do the most commonly-used thing? I myself last weekend puzzled over a wonderfully non-specific &#8220;invalid reciever&#8221; error for a long time before realizing that I forgot an @ when sending strings to an <code>arrayWithObjects:</code> method. Aside from that, why use the @-sign as a prefix for NSStrings when it&#8217;s used in a plethora of other places, such as <code>@interface</code>, <code>@implementation</code>, <code>@end</code> and <code>@selector</code>? Though 90% of my @-key-presses in Textmate are prefixes to NSStrings, I can&#8217;t have a keypress of @ automatically expand to @&#8221;&#8221; &#8211; there are too many other things to do with the poor little @-sign. The oft-neglected | (pipe or vertical bar, I&#8217;ve heard both) character is far less disruptive to the flow of typing.</li>
<li><em>reallyLongAndCamelCasedMethodNamesGetAnnoying</em>. I refer specifically to the lovely <code>NSWorkspace</code> method <code>openURLs: withAppBundleIdentifier: options: additionalEventParamDescriptor: launchIdentifiers:</code><br />
And ObjC method names can be concise yet informative &#8211; take for example NSString&#8217;s <code>compare: options: range: locale:</code>. I must admit, this complaint is not entirely valid, especially considering Textmate/XCode&#8217;s fancy code completion.</li>
<li><em>No operator overloading</em>. Come on, guys &#8211; why reject this crucial part of Smalltalk heritage? I, for one, am sick of writing <code>objectAtIndex</code> and <code>objectForKey:</code> as compared to Python&#8217;s []. Though Smalltalk allows one to define new operators, I&#8217;d be perfectly happy to settle for a few overloadable operators (string concatenation is <em>desperately</em> needed).</li>
<li><em>Mysterious helper methods. </em>I didn&#8217;t know of the existence of <code>NSHomeDirectory()</code>, <code>NSTemporaryDirectory()</code>, or <code>NSClassFromString()</code> until very recently. True, this is my fault, but I think that F-Script&#8217;s idea of storing all of these methods in a singleton System object is excellent, and much more in line with Objective-C&#8217;s Smalltalk heritage. (Actually, I have a half-finished ObjC class that makes <code>NSBeep()</code> and all those other miscellaneous C functions into class methods; if there&#8217;s any interest, I&#8217;ll finish and release it. I suppose that makes this complaint invalid. Oh well.)</li>
<li><em>File management is a mess.</em> Essential code is scattered throughout <code>NSWorkspace</code> (in all its brain-dead glory), <code>NSFileManager</code>, <code>NSFileHandle</code>, <code>NSPipe</code>, <code>NSDirectoryEnumerator</code>, and <code>NSData</code> &#8211; few things are as infuriating as hunting down the correct class that does exactly what I want. (Actually, no. Finding a better solution after thirty minutes of hacking around some perceived inadequacy is worse.</li>
</ol>
<p>So there you have it. To be honest, it took me quite a while to write this, mainly because Objective-C is such a great language and Cocoa is such a great set of libraries. I suppose that the imperfections in a consistently useful and friendly toolkits stand out, and in retrospect I sort of feel guilty for my picky attitude. After all, it could be <a href="http://en.wikipedia.org/wiki/Swing_(Java)">much, much worse</a>.</p>
]]></html></oembed>