11 ms·

Why Objective-C is Hard

209 points by AshFurrow 15y ago

sgonyea 15y ago
What lots of others have already mentioned. Also be aware, there is something called "Objective-C++" which is a superset of C++. The syntax is not "weird" unless you just don't know the language. Acclimation is part of the learning process. In my opinion, the syntax/language is pretty great. I enjoy ObjC greatly. My main beef with it is that it's less than portable. ObjFW attempts to solve this, and is a phenomenal framework already.
k-mcgrady 15y ago
I've only learnt 2 programming languages 'thoroughly'. Pascal and Objective-C. I find Objective-C a much simpler to understand language than Java for example. I have worked in Java (although not extensively) and it just seems messy to me. Objective-C is much more human readable and better structured in my opinion.
- AshFurrow 15y ago
  Yeah, I agree. It's a beautiful and expressive language. I guess I should have called the article "Why Objective-C is Hard to Learn"
tmcw 15y ago
Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.
- k-mcgrady 15y ago
  I think the verbose method names are a Cocoa design decision.
- ejames 15y ago
  It's because Objective-C methods are named according to the nouns that they return rather than the verbs they perform. For example, "[input stringByAppendingThing:thing]" rather than "input.append(thing)". Methods are actions, not objects, so the most concise description for a method is usually a verb. Describing it as a noun instead requires adding prepositions and turning verbs to the gerund '-ing' form. I realized this because I write both Ruby and Objective-C, and sometimes write basically the same thing in idiomatic forms of both languages. In idiomatic Ruby method-chaining, your code is a series of verbs with the relations between the actions defined by the '.' or the '()' signs, rather than by words such as 'to', 'from', 'with', or 'by' present in the name of the method.
  - chc 15y ago
    Eh, I think that's a little overbroad. The way it works is, methods whose purpose is returning something are named for what they return, while methods whose purpose is creating a side effect are named for what they do. So NSString has `stringByAppendingString:` because you're asking for a new string, while NSMutableString has `appendString:`, which is essentially the same as it would be in Ruby except with an allowance for Objective-C's static type system. What really creates the impression that Objective-C speaks in terms of nouns is that Cocoa tends to promote immutable objects more than Ruby does (e.g. the only way to get an immutable string or array in Ruby is to freeze a mutable one, while you'll almost never get a mutable array in Cocoa unless you create one yourself), so you probably do spend more time asking your objects for other objects than you do in Ruby. Although the verbosity can get overwhelming, I actually like this about Objective-C. In terser dynamic languages, I'm constantly having to confirm (either mentally or in the docs) which methods mutate and which return a new object. Cocoa's naming conventions mean I pretty much never have to do that.
    - glhaynes 15y ago
      Very well said. I think this also promotes a mindset of making methods that either mutate state or build and return an object. It's often very difficult to follow code that has lots of methods that do both.
    - 15y ago
- donmcc 15y ago
  The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with. With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conventions, I think it's more readable than Java or JavaScript.
  - bunderbunder 15y ago
    I've found it pays off at write time too. Having to say something about each parameter when naming a method really helps me to stop and think about what I'm doing every time I add to an object's interface. I'd like to think it ultimately leads to less bloat.
  - ctide 15y ago
    I actually find it much harder to read as a result of it's verbosity. For example, just yesterday I ran into a bug with these 2 lines: if ([[data objectForKey:@"released"] isKindOfClass:[NSNull class]]) { if ([[data objectForKey:@"posterUrl"] isKindOfClass:[NSString class]]) { They weren't right next to each other, and at a glance, I misread to assume they were doing the same thing. There's too much shit in the way of the actual differences (NSNull vs. NSString in this case) that I have a bad tendency to gloss over the details. Coming from ruby, the closest syntactical equivalent: if (data['released'].class == NilClass) { if (data['posterUrl'].class == String) { Is so much clearer to me when glancing through code. That doesn't even touch on how you'd actually write that sort of thing (data['released'].nil?) which is infinitely more concise than either example. I know this is a bit of a contrived example, and I certainly could find better ones. I just find the 120 character long method evocations to consistently blur the details for me, and this just happens to be the freshest instance. To be fair, I've only been doing iOS stuff for about a month. Does this trend reverse after you've been writing obj-c for a while?
    - AshFurrow 15y ago
      I've found after a while you get really used to the verbosity. I miss it when I return to other languages. For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.
- jcizzle 15y ago
  Selectors always describe exactly what the method does and what it needs. For example, stringByAppendingStringWithFormat: says "You will get a new string, by appending a format string to the receiver." There is also the mutable counterpart, appendStringWithFormat:, which is shorter because it doesn't return a new string, instead, appending directly to the receiver. Verbose selectors make Objective-C self-documenting at the cost of extra typing. But autocomplete solves this problem because you only ever have to type 2-5 characters to insert the method you want (once you are experienced enough to predict what autocomplete will spit out). Objective-C naming conventions form predictable patterns. Inexperienced programmers gripe because they have yet to figure out these patterns, good programmers love Objective-C because they understand these patterns and can therefore predict the name of a method and its arguments and great programmers write their own classes that use these patterns.
  - Cushman 15y ago
    Seconded. The first time you write a fully working method using a library you've never used in one shot without looking anything up will make you love ObjC.
    - eropple 15y ago
      I've done exactly as you say, and I still find Objective-C Perlesque in its obnoxiousness. I also manage to achieve that not-terribly-hard feat on a pretty regular basis with Java: intellisense (hi, IntelliJ!) and IDE-provided Javadocs do the same thing, too, and someone who isn't going to write good Javadocs isn't going to name things well.
- revorad 15y ago
  That's one of the things I'm finding most annoying about learning Obj-C. The weird thing is that these extra long names make the language less readable to me, because I have to mentally diff very similar looking long strings.
- btn 15y ago
  The design philosophy behind much of Objective-C is described in Brad Cox's book "Object-oriented programming: an evolutionary approach" [1]. Unfortunately, I don't have a copy handy to give you a quote. [1] http://books.google.co.nz/books?id=U8AgAQAAIAAJ http://books.google.co.nz/books?id=U8AgAQAAIAAJ
- xsmasher 15y ago
  It's a technical requirement. Parameter types are not part of the method signature, so you CAN NOT define both [string append:string] and [string append:int] methods. You must give them different names, like [string appendString:string] and [strig appendInt:int] , in order to give them different signatures.
stcredzero 15y ago
Unless you've played with other languages that support these features, like Ruby or Lisp, then this feels really weird. Don't worry! Lots of great things feel really weird the first time you try them, like broccoli or sexual intercourse. I find it really weird that there's no mention of Smalltalk, which is exactly where the weird syntax comes from. It's also where the notion of IntentionRevealingNames comes from, which the author wonders about. http://c2.com/cgi/wiki?IntentionRevealingNames http://c2.com/cgi/wiki?IntentionRevealingNames (That's the Ur wiki, BTW.) Thoughtful post but with less than stellar marks for research.
- deleted 15y ago
  [deleted]
gdubs 15y ago
Syntactic sugar (dynamic getter and setters using @synthesize, @property, allowing for dot syntax accessors) is not new. Nor is Garbage Collection. Garbage Collection is not available on iOS, but has been for a long time on OS X [edit: and as noted below, is actually being deprecated in favor of ARC]. Objective-c 2.0 came out in 2006. Blocks, at this point, are not really new either. So, I think it's incorrect to say that Apple is 'adding' these things. If a newcomer checked out the online documentation for contentStretch they would find: "Defines portions of the view as being stretchable. This behavior is typically used to implement buttons and other resizable views with sophisticated layout needs where redrawing the view every time would affect performance." There's also a lot of good arguments as to why dot syntax is often NOT what you want to do. For instance, a someCALayer.frame will give you the frame of that layer based on its anchor point, position and bounds. However, you can't do myLayer.frame = someRect [edit: as pointed out below, you can do this -- but the results may not be what you expect]. The introduction of the 'simpler' dot syntax, in that example actually makes things harder for a new programmer. So, I don't agree that syntax is why Objective-C is hard. Intimidating because of syntax, perhaps. But, once someone begins coding (IMHO) it can be one of the easiest languages. My school taught Pascal in the intro to comp sci class. I found it incredibly difficult (well, maybe dull is a better word). I then self-taught myself actionScript (late 1990's). I then self-taught myself Objective-C, and I have to say it really just took a Big Nerd Ranch guide and I was off and running. It takes years to become fluent, but I really think that when someone grasps the basics of Objective-C, over time it is one of the most intuitive languages.
- jonhendry 15y ago
  GC is deprecated as of 10.8, in favor of ARC.
  - gdubs 15y ago
    Just to be clear, I was referencing the point in the original article where it said that apple was 'adding Garbage Collection' to make the 'code expressed in Objective-C simpler'.
- AshFurrow 15y ago
deleted 15y ago
[deleted]
phatbyte 15y ago
I don't think Objective-C is hard at all. If you understand OO or come from a OO language you can pick it up pretty fast, like in a day or two. Cocoa on the other hand requires much more learning curve. Also apple could improve their documentation. I'm currently working on a OSX app, and Objective-C has been a breeze, with the new ARC is even more easy to work with.
- objclxt 15y ago
  Really? If you compare Apple's documentation to Android's...they're worlds apart. Here's a good example: I'm an iOS developer, and have been since pretty much day 1 of the platform. I recently actually started playing around with the Android SDK, and environment. I followed Google's supplied tutorial for creating a tabbar app, and asked one of the Android devs who works with me to come take a look at the finished result. "Oh", he said, "that's deprecated now. We don't do tab bars like that any more. We use fragments instead". And sure enough, when I looked closely, Eclipse was telling me what I'd done was, in fact, deprecated and Google recommended a different approach. Except I'd followed their main tutorial for Android, step by step. Compare this with Apple, who have consistently updated their documentation for each API release. How Google could possibly think it's a good idea to deprecate a major platform feature for fragments (a good thing) and not update one of the most popular tutorials on their site to reflect this (the 'Hello Views' tutorial) is beyond me.
  - phatbyte 15y ago
    I never really worked with Android so I can't speak for it. But I completely agree with you on the updated documentation, I just feel that sometimes I get a little lost when I trying to learn how to use a class or framework.
  - dpifke 15y ago
    Why does a comment about Apple's documentation need to turn into a holy war versus Android? The parent said that Apple "could improve" their documentation, not that it was worse than Google/Microsoft/IBM/whomever.
radiowave 15y ago
I think it's very largely a question of what you're used to. I don't know much about Objective C, but given my knowledge of Smalltalk, the use of keywords to identify arguments seems entirely natural. But then I've never really understood why people think it's acceptable for languages to insist that you do this: myfunction("First argument","Does this one really go second?","Is there even a third?")
mahyarm 15y ago
I love the flexibility and breadth of things you can do with objective-c/c++. It's downsides mostly come from syntax, container class getting/setting is way too verbose, same with string operations. If there was a special syntax for just string and container classes, large swaths of my code would be smaller. UIKit view controller classes are also not flexible enough, and crap out in a lot of custom multithreaded operations when they shouldn't. I could reproduce the same behavior with my own classes (animations, transitions, view control, etc) using just basic UIView classes and it would work significantly better.
- zxoq 15y ago
  Beta version of XCode has dict[@1] or dict[@"key"] for accessing members. Makes NSNumber and objectForKey old news. It's great. :)
igorgue 15y ago
You know what I really dislike about Objective-C is that is really inconsistent with properties and messages, at one point I said out loud: JUST PICK ONE! Coming from Python this is a big thing for me, I like when there's only one right way to do things. P.S. My only experience with Objective-C is with the iOS SDK.
- wvs 15y ago
  You may already know this, but properties are just sugar for messages and instance variables. Their only difference is a shorter syntax. (...plus some extra runtime data, but you don't usually notice that.)
jamesu 15y ago
Anything you do not understand is inherently hard. The only thing i would say is uniquely hard about Objective C is getting your head around some of the APIs, but then again that can apply to any language.
- mirkules 15y ago
  To me the hardest thing is the seemingly arbitrary CG functions in Quartz2D and why they're so interspersed throughout the code. If I'm writing within the UIKit most of the time, and then have to make my own UIView for some custom drawing, I have a hell of a time remembering how, and always have to reference my earlier code, which I usually find on StackOverflow or somewhere else. Example, let's draw a line and an ellipse in drawRect: CGContextRef ctx = UIGraphicsGetCurrentContext(); //CGMove the point somewhere? //CGLineTo something //CGDrawEllipseInRect or something //stroke or fill? CGFillSomething maybe? //do i need to end the context? Maybe it's a mental block on my part, but I can _never_ remember how to do this and always have to look it up, probably because it's not part of the standard UIKit and not used on daily basis. I guess I would just like to see the Quartz stuff conform more to UIKit naming conventions (but because it's based in C, I understand why it's not)
siavosh 15y ago
I spend half my day in iOS development and the other half on a Java web stack. I love the RESULT of Obj-C+Cocoa Touch, you can achieve amazing user experience. But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues? Java isn't much better either, why all this boiler plate, and still concurrency nightmares. I've done a handful of side projects with django and that's better, but I still think if I showed my teenage self what I'm programming in, he'd wonder if there was ever any real progress. I guess what I'm saying is after all these years I want to work on a higher level, as a result I've started to play with Clojure and functional languages. Whether I'm idealizing functional/clojure life, I'll soon find out, but the appeal is very high to spend my time dealing with problem complexity, not language/framework ones.
- aaronblohowiak 15y ago
  Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.
  - mirkules 15y ago
    A word of caution with ARC -- you still have to release certain things manually, for example CGImageRefs with CFRelease if you're doing any sort of image manipulation.
    - aaronblohowiak 15y ago
      Those aren't Objective-C objects, but I get your point. ARC does not relieve you of thinking about memory, it just makes it easier.
      - AznHisoka 15y ago
        ARC to me is scary... I got over the huge learning curve, and the nuances of autoreleasing, and retaining, and it seems like now I gotta unlearn all of that??? And not to mention some third party libraries/source code don't support ARC. To me, I'm gonna hold off using ARC as long as possible.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
iamgilesbowkett 15y ago
is it fair to TL;DR this as "Objective-C is only hard if you've never used Smalltalk"? or is that overly glib?
zoul 15y ago
People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months. What’s much more important is the conceptual complexity: the number of language features and the way they fit together. A second important thing is the standard library. Objective-C is a pleasant language by both these metrics, since there are just a few language constructs above the C level, they fit together well without creating dark corners, and Cocoa is a very mature and well thought-out framework. The iOS Objective-C ecosystem does take some time to master, but so does every modern SDK, since the libraries are always huge. Programming is hard and if somebody is scared by minus signs in front of method names, evil spirits will suck his soul out by the time he gets to thread synchronization.
- phatbyte 15y ago
  I couldn't agree more. Everything is "hard" on the first couple of times, but the only recommendation I say to people is to stop worrying about the language, and go create stuff, get into that mindset of creating something, even if it's just a simple app. that will allow us to research and ask things around, and that's when you learn and progress. Nobody achieves anything by bitching around how hard this and that is.
  - AshFurrow 15y ago
    You're right - I should have called it "Why Objective-C is Hard to Learn"; all of the issues I enumerate are surmountable with enough experience and experimentation.
- mogui 15y ago
  agreee totally with you, it is isn't hard at all
- unicron 15y ago
  I've put together a few things with Objective C over the years dating back to OSX 10.1 (yuck PB sucked then) to iOS. Most ended up being ported to Java or C#. The syntax IS absolutely horrible if you ask me as it results in crazily verbose ways of expressing stuff. Everything is "too meta" and there are very few first class parts of the language. It still FEELS like it's hacked together with C macros (which was what it originally was). Add to that the reference counting implementation (when GC is not enabled which you can't do on iOS) and it's just painful. Also the lack of any decent threading abstraction - ick. I think there is a lot of hype around it. It's not where we should be in 2012. Android does better with bastardised Java if you ask me.
outworlder 15y ago
I might be just me, but I've always found Objective-C's syntax very nice (compared to, say, C++). It might be verbose, but you have a clear separation between C and Objetive-C. If it doesn't contain "[]" or "@", my brain can just parse it as C code.
- deleted 15y ago
  [deleted]
cwbrandsma 15y ago
I find Objective-C hard as well, but it has more to do with the nature of the message passing syntax that objective-c has. For instance, for the life of me I CANNOT get calls to NSNotificationFactory right the first try, and there are no compiler hint to help you...it just doesn't work for some reason. There are other items like that. Not much help when the app crashes, lack of Namespaces (class name collisions), etc. Then throw in all the fun of submitting an app to the store. Working with iAds and In App Purchases will make you want to hurt something.
augustl 15y ago
Hard is OK. Over time, you become better at it, until it's no longer a problem -- it's a relative thing. Not saying easy is bad, but hard isn't _that_ big of a problem. Example: I find Russian very hard to speak. That doesn't mean Russian IS hard, I just don't know russian. And some languages are harder (more stuff to learn) than others. See http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
dustineichler 15y ago
I'm going to disagree. Objective-C is an ASNI C derivative language. Programming for me at least isn't knowing the syntaxual elements of a language but leveraging paradigms I know to exist from one language to the next. Objective-C while looks different, is really no different than most languages. It definitely shouldn't be your first language, maybe not even your 2nd choice, but if you have a conceptional knowledge of programming languages and you're keen on diving into the deep end, there's enough resources out there you're not going to drown. I love Objective-C for many reasons, but then again I equate programmatic choice to personalities. If that makes sense. Point being, don't be deterred. iOS SDK is something else all together, but like anything worth learning, learn by doing. What you should probably decide for yourself is if this article makes it seem harder than it is. His conclusion about Automatic Reference Counting is on the money, but that's about it. "When learning Objective-C, it's not just a language or a framework or a runtime or a compiler, it's all of these things". No is not. These are different. If anyone is considering learning this language, there's a bunch of unsolved problems that frequently include writing new libraries. Cheers.
ja27 15y ago
It's not that bad. A little verbose, but it's not like switching from C to Lisp or Prolog.
rsbrown 15y ago
You had met at "... like broccoli or sexual intercourse". Great read, well written.
batista 15y ago
Forget the fact that we're not even talking about methods, really, we're talking about messages (a distinction I'm not going to make) and you refer to selectors like the one above as performAction:withTwoParameters:. Most people don't care anymore. Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is basically 99% "Smalltalk in square brackets". Nobody complains that Smalltalk has a strange syntax, even small kids seem to use Squeak just fine. [object performAction: param1 withTwoParameters: param2] not that different to: object.performAction(self, param1, withTwoParameters=param2) in Python, or any language with named parameters. The syntactic differences are superficial. You don't even have to know about selectors and messages to understand the gist of what that invocation will do. "OMG, method parameters have a name" --well, big effin' deal. Ever seen C++ (especially the recent standard)? Or the beast with 1000 features C# has become? Obj-C compared is leanness personified. The ACTUAL source of complexity in programming in Objective-C is the huge Cocoa (et al) API. But a huge API, especially nicely documented as Cocoa is, and with such breadth and nice MVC design, is a GOOD THING. This tightly-coupled codesign is unique to Objective-C. There are other languages that run on .Net, such as Iron Python. Lots of language use the JVM besides Java, like Clojure. Even Ruby and Rails are two distinct entities and projects. The only significant effort to use a different language with Cocoa/Cocoa Touch and the Objective-C runtime, Mac Ruby, was a project largely backed by Apple before they abandoned it. Actually, there are several efforts besides MacRuby to use another language with the Objective-C runtime: Nu (Lisp like), F-script (Smalltalk like). But the main difference here is that the Objective-C runtime is a very simple runtime, not a full VM, so the comparison to CLR and Java is not that apt. For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5. In general, not that good of an article...
- SeanLuke 15y ago
  withTwoParameters is actually part of the method signature. It's not a keyword identifier. So [object performAction: param1 withTwoParameters: param2] is roughly equivalent to object.performActionwithTwoParameters(param1, param2)
algoshift 15y ago
Nah. Not hard. Different. People have a natural inclination to resist the new. My guess is that a competent programmer with OO experience should be comfortable with Objective-C within a week or two of study.
bobstobener 15y ago
Not looking for trouble here but writing an iPhone app should be no more difficult than creating a Keynote presentation, imho. If Apple is the leader in document development (Keynote, etc), why can't they do the same with writing apps. Look at what they've done with the complexities of video editing. Where is the consumer grade development app for iPhone?
thought_alarm 15y ago
The entire article is about how Smalltalk syntax is different from C syntax, something that any reasonably competent programmer gets over very quickly. And he gets it wrong. The article is a complete waste of time.
glaurent 15y ago
I know Objective C, C++, Java and have basic knowledge of C#. Of all these I'd rate Objective C as the easiest to learn and to handle. It's much more forgiving and easy on the programmer, and the syntax is trivial. You seem to make a big case of the message passing syntax, but your example is very poorly chosen. Rather than 'performAction:withTwoParameters:' it should be 'performActionWithFirstParameter:andWithSecondParameter:' as are most Cocoa methods. Named parameters may seem verbose but they are much more readable than 'performAction(param1, param2)'. If Objective C is a "large" language, I wonder what you'd call C++ or C#. Huge ? Humongous ? If you think Cocoa is large and complex, the C++ Standard Library or the Java library will make you weep.
- Deinumite 15y ago
  Actually the C++ STL is known for being pretty small... that also depends on if you even count the C stuff that C++ includes.
- cageface 15y ago
  The C++ standard library is actually quite small. Check Herb Sutter's keynote at Going Native 2012 for an entertaining visualization of its size compared to the Java or C# standard libraries: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
  - glaurent 15y ago
    Compared to the Java and C# libs, yes, the C++ std lib is small. In terms of complexity and ease of use, it's a different picture.
    - cageface 15y ago
      The IO libraries are kind of a mess but I don't find the algorithms and containers significantly more difficult to use than similar implementations in other languages.
scrod 15y ago
>However, they're also adding to the language in ways that makes the code expressed in Objective-C simpler: >Synthesizing properties >Dot-syntax for accessing getters/setters >Garbage Collection >Blocks (closures) >Automatic Reference Counting >Weak references Sorry, but none of these things make the language any simpler — they all add yet another style of doing things that only raises the bar and the learning curve for new developers when reading existing code, in precisely the same way that C++ and Perl have done. And this is true even of garbage collection (which, by the way, is deprecated in 10.8), because it needs to coexist with other frameworks and code that might not be garbage-collected, and more importantly because all heap-allocated C buffers consequently require their own low-level wrappers (e.g., NSAllocateCollectable, objc_memmove_collectable, etc.).
AznHisoka 15y ago
Before I took the jump to learn Objective C and iPhone development, I dreaded the huge learning curve needed. Now that I'm on the other side, I LOVE the fact it intimidates people :)
imaginaryunit 15y ago
Minor point that has always bugged me: why doesn't Cocoa have native implementations of tree data structures?
- astrange 15y ago
  http://ridiculousfish.com/blog/posts/array.html http://ridiculousfish.com/blog/posts/array.html
dgallagher 15y ago
It's best to think of Obj-C method call syntax as a sentence, written in english, which happens to also be computer code. If you name your methods and variables succinctly and explicitly, the language is extremely readable and documents itself (assuming you know english). Obj-C was the first language I learned after Python. I remember the 2nd month in, it went from being difficult to read, to extremely easy. Obj-C code can be written terribly, like this: NSString *someString = @"hello what's up?"; NSMutableString *anotherString = [NSMutableString stringWithString:@"I have more to say, don't I?"]; NSArray *stringArray = [NSArray arrayWithObjects:someString, anotherString, nil]; NSUInteger stringArraySize = [stringArray count]; Messy Obj-C code! Human eyes like simplicity, like right angles, and columns. Same code, more readable: NSString *someString = @"hello what's up?"; NSMutableString *anotherString = [NSMutableString stringWithString:@"I have more to say, don't I?"]; NSArray *stringArray = [NSArray arrayWithObjects:someString, anotherString, nil]; NSUInteger stringArraySize = [stringArray count]; Takes an extra few seconds of typing, but goes miles.
- redthrowaway 15y ago
  The same is true of most programming languages. Simple things like layout improve readibility, and thus productivity, immeasurably.
- cageface 15y ago
  If you use the new AppCode Obj-C IDE, you can get formatting like the latter for free.
JVIDEL 15y ago
I know this is a short article meant to explain the basics but I don't like how under the History section it makes no mention of NeXT or Stepstone which were the creators of ObjectiveC.
kln 15y ago
Rather than performAction:firstParameter withTwoParameters:secondParameter which is kind of confusing. You should name it performActionWithTwoParametersFirst:firstParameter andSecond:secondParameter if you insist on calling your method performAction
andr3w321 15y ago
For me the most annoying thing about learning xcode/objective-c is apple tries to force you into buying a Mac.
- prodigal_erik 15y ago
  That's a deficiency of the iOS platform, not the ObjC language. It's just that ObjC is brittle and tricky enough that there's no longer much reason to learn it unless you're working on iOS (or possibly MacOS, if you think that'll stay relevant), though GNUstep is portable if you really want to.
cageface 15y ago
Really the only thing that makes Obj-C the language hard is that the C layer pokes through often enough that you really do need to understand C as well and C presents a lot of pitfalls to a new programmer.
cmelbye 15y ago
I personally love the syntax of Objective-C. I find it very readable. I wish I could use it more often.
pjmlp 15y ago
I don't understand all these comments about Objective-C being hard. Maybe it is because I am programming computers since the Z-80 days, or because like it is expected in my country I did a good earned CS degree. If you think using a language like Objective-C is hard, maybe you should not be programming at all.
julik 15y ago
Well, from my limited experience with Objective-C a few things made it hard. The first is the traditional Cocoa pattern of a method that does useful things, which looks like this: - (void)beautifullyNamedMethodFor { void* ugly_ptr_type; // and around 45 more CFObscurePtrRef* .. = CFObscureObsoleteFunction(NULL, NULL,.....); // 56 arguments // to the callback omitted for brevity ...*....(*foo)...->(*x++); // and so one - with 45 lines of NULL ptrs passed as void* to CF calls // juggled and incremented ad absurdum until your eyes bleed. } So on the surface it's a beautiful Smalltalkish thing, while down below it's usually all hairy C, pointers and null-terminated strings and Core Foundation callbacks right out of MacOS 7 (especially if you want anything useful to be done that is not in Cocoa by default). This always seemed to me to be a deception in a way. Another pet peeve of mine is the same agony of choice that is object variables (pointers versus values). When I want to return something or declare a variable, even when I am in the rose-tinted-glasses Cocoa world of beautifully-named methods, classes and keyword arguments I still have to put the dreaded death star in front of just the right things (and to remember NOT to put it in front of exactly proper other things). So I guess for me the most problematic Objective-C part is the one that has to do with C (because it adds a level of complexities on top of C). The "Objective" part is actually very nice, once you get used to the call syntax and the brackets.
jinushaun 15y ago
The only item I agree with is the last item: Objective-C is a nebulous term because it's so intrinsically tied to Apple and Cocoa/UIKit. The syntax? You pick it up within a week. Message passing versus method invocation? An important, but subtle distinction. So what makes Obj-C hard? For me, it was Apple's gigantic MVC-style framework. Rewiring my brain to grok Obj-C was nothing compared to grokking Foundation Kit, UIKit and AppKit. Growing up with C++, C# and Java, you get used to a particular way of doing thing. APIs are designed and interacted with in a certain way. Apple's API feel completely different. From building strings and making network connections to working with images and animations. Apple's version just feels different.
hboon 15y ago
Objective C isn't hard. Ruby isn't hard. Building a great app is hard. Building and running a great service is hard. Building and running a great company is hard. Most commonly used programming languages aren't hard.
xiaoma 15y ago
Is MacRuby truly abandoned? If so, then I'm saddened. I just started experimenting with it recently and found it to be the answer to everything that frustrated me about obj c.

209 points by AshFurrow 15y ago

What lots of others have already mentioned. Also be aware, there is something called "Objective-C++" which is a superset of C++. The syntax is not "weird" unless you just don't know the language. Acclimation is part of the learning process. In my opinion, the syntax/language is pretty great. I enjoy ObjC greatly. My main beef with it is that it's less than portable. ObjFW attempts to solve this, and is a phenomenal framework already.

k-mcgrady 15y ago

I've only learnt 2 programming languages 'thoroughly'. Pascal and Objective-C. I find Objective-C a much simpler to understand language than Java for example. I have worked in Java (although not extensively) and it just seems messy to me. Objective-C is much more human readable and better structured in my opinion.

AshFurrow 15y ago
Yeah, I agree. It's a beautiful and expressive language. I guess I should have called the article "Why Objective-C is Hard to Learn"

tmcw 15y ago

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

k-mcgrady 15y ago
I think the verbose method names are a Cocoa design decision.
ejames 15y ago
It's because Objective-C methods are named according to the nouns that they return rather than the verbs they perform. For example, "[input stringByAppendingThing:thing]" rather than "input.append(thing)". Methods are actions, not objects, so the most concise description for a method is usually a verb. Describing it as a noun instead requires adding prepositions and turning verbs to the gerund '-ing' form. I realized this because I write both Ruby and Objective-C, and sometimes write basically the same thing in idiomatic forms of both languages. In idiomatic Ruby method-chaining, your code is a series of verbs with the relations between the actions defined by the '.' or the '()' signs, rather than by words such as 'to', 'from', 'with', or 'by' present in the name of the method.
- chc 15y ago
  Eh, I think that's a little overbroad. The way it works is, methods whose purpose is returning something are named for what they return, while methods whose purpose is creating a side effect are named for what they do. So NSString has `stringByAppendingString:` because you're asking for a new string, while NSMutableString has `appendString:`, which is essentially the same as it would be in Ruby except with an allowance for Objective-C's static type system. What really creates the impression that Objective-C speaks in terms of nouns is that Cocoa tends to promote immutable objects more than Ruby does (e.g. the only way to get an immutable string or array in Ruby is to freeze a mutable one, while you'll almost never get a mutable array in Cocoa unless you create one yourself), so you probably do spend more time asking your objects for other objects than you do in Ruby. Although the verbosity can get overwhelming, I actually like this about Objective-C. In terser dynamic languages, I'm constantly having to confirm (either mentally or in the docs) which methods mutate and which return a new object. Cocoa's naming conventions mean I pretty much never have to do that.
  - glhaynes 15y ago
    Very well said. I think this also promotes a mindset of making methods that either mutate state or build and return an object. It's often very difficult to follow code that has lots of methods that do both.
  - 15y ago
donmcc 15y ago
The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with. With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conventions, I think it's more readable than Java or JavaScript.
- bunderbunder 15y ago
  I've found it pays off at write time too. Having to say something about each parameter when naming a method really helps me to stop and think about what I'm doing every time I add to an object's interface. I'd like to think it ultimately leads to less bloat.
- ctide 15y ago
  I actually find it much harder to read as a result of it's verbosity. For example, just yesterday I ran into a bug with these 2 lines: if ([[data objectForKey:@"released"] isKindOfClass:[NSNull class]]) { if ([[data objectForKey:@"posterUrl"] isKindOfClass:[NSString class]]) { They weren't right next to each other, and at a glance, I misread to assume they were doing the same thing. There's too much shit in the way of the actual differences (NSNull vs. NSString in this case) that I have a bad tendency to gloss over the details. Coming from ruby, the closest syntactical equivalent: if (data['released'].class == NilClass) { if (data['posterUrl'].class == String) { Is so much clearer to me when glancing through code. That doesn't even touch on how you'd actually write that sort of thing (data['released'].nil?) which is infinitely more concise than either example. I know this is a bit of a contrived example, and I certainly could find better ones. I just find the 120 character long method evocations to consistently blur the details for me, and this just happens to be the freshest instance. To be fair, I've only been doing iOS stuff for about a month. Does this trend reverse after you've been writing obj-c for a while?
  - AshFurrow 15y ago
    I've found after a while you get really used to the verbosity. I miss it when I return to other languages. For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.
jcizzle 15y ago
Selectors always describe exactly what the method does and what it needs. For example, stringByAppendingStringWithFormat: says "You will get a new string, by appending a format string to the receiver." There is also the mutable counterpart, appendStringWithFormat:, which is shorter because it doesn't return a new string, instead, appending directly to the receiver. Verbose selectors make Objective-C self-documenting at the cost of extra typing. But autocomplete solves this problem because you only ever have to type 2-5 characters to insert the method you want (once you are experienced enough to predict what autocomplete will spit out). Objective-C naming conventions form predictable patterns. Inexperienced programmers gripe because they have yet to figure out these patterns, good programmers love Objective-C because they understand these patterns and can therefore predict the name of a method and its arguments and great programmers write their own classes that use these patterns.
- Cushman 15y ago
  Seconded. The first time you write a fully working method using a library you've never used in one shot without looking anything up will make you love ObjC.
  - eropple 15y ago
    I've done exactly as you say, and I still find Objective-C Perlesque in its obnoxiousness. I also manage to achieve that not-terribly-hard feat on a pretty regular basis with Java: intellisense (hi, IntelliJ!) and IDE-provided Javadocs do the same thing, too, and someone who isn't going to write good Javadocs isn't going to name things well.
revorad 15y ago
That's one of the things I'm finding most annoying about learning Obj-C. The weird thing is that these extra long names make the language less readable to me, because I have to mentally diff very similar looking long strings.
btn 15y ago
The design philosophy behind much of Objective-C is described in Brad Cox's book "Object-oriented programming: an evolutionary approach" [1]. Unfortunately, I don't have a copy handy to give you a quote. [1] http://books.google.co.nz/books?id=U8AgAQAAIAAJ http://books.google.co.nz/books?id=U8AgAQAAIAAJ
xsmasher 15y ago
It's a technical requirement. Parameter types are not part of the method signature, so you CAN NOT define both [string append:string] and [string append:int] methods. You must give them different names, like [string appendString:string] and [strig appendInt:int] , in order to give them different signatures.

stcredzero 15y ago

Unless you've played with other languages that support these features, like Ruby or Lisp, then this feels really weird. Don't worry! Lots of great things feel really weird the first time you try them, like broccoli or sexual intercourse. I find it really weird that there's no mention of Smalltalk, which is exactly where the weird syntax comes from. It's also where the notion of IntentionRevealingNames comes from, which the author wonders about. http://c2.com/cgi/wiki?IntentionRevealingNames http://c2.com/cgi/wiki?IntentionRevealingNames (That's the Ur wiki, BTW.) Thoughtful post but with less than stellar marks for research.

deleted 15y ago
[deleted]

gdubs 15y ago

Syntactic sugar (dynamic getter and setters using @synthesize, @property, allowing for dot syntax accessors) is not new. Nor is Garbage Collection. Garbage Collection is not available on iOS, but has been for a long time on OS X [edit: and as noted below, is actually being deprecated in favor of ARC]. Objective-c 2.0 came out in 2006. Blocks, at this point, are not really new either. So, I think it's incorrect to say that Apple is 'adding' these things. If a newcomer checked out the online documentation for contentStretch they would find: "Defines portions of the view as being stretchable. This behavior is typically used to implement buttons and other resizable views with sophisticated layout needs where redrawing the view every time would affect performance." There's also a lot of good arguments as to why dot syntax is often NOT what you want to do. For instance, a someCALayer.frame will give you the frame of that layer based on its anchor point, position and bounds. However, you can't do myLayer.frame = someRect [edit: as pointed out below, you can do this -- but the results may not be what you expect]. The introduction of the 'simpler' dot syntax, in that example actually makes things harder for a new programmer. So, I don't agree that syntax is why Objective-C is hard. Intimidating because of syntax, perhaps. But, once someone begins coding (IMHO) it can be one of the easiest languages. My school taught Pascal in the intro to comp sci class. I found it incredibly difficult (well, maybe dull is a better word). I then self-taught myself actionScript (late 1990's). I then self-taught myself Objective-C, and I have to say it really just took a Big Nerd Ranch guide and I was off and running. It takes years to become fluent, but I really think that when someone grasps the basics of Objective-C, over time it is one of the most intuitive languages.

jonhendry 15y ago
GC is deprecated as of 10.8, in favor of ARC.
- gdubs 15y ago
  Just to be clear, I was referencing the point in the original article where it said that apple was 'adding Garbage Collection' to make the 'code expressed in Objective-C simpler'.
AshFurrow 15y ago

deleted 15y ago

[deleted]

phatbyte 15y ago

I don't think Objective-C is hard at all. If you understand OO or come from a OO language you can pick it up pretty fast, like in a day or two. Cocoa on the other hand requires much more learning curve. Also apple could improve their documentation. I'm currently working on a OSX app, and Objective-C has been a breeze, with the new ARC is even more easy to work with.

objclxt 15y ago
Really? If you compare Apple's documentation to Android's...they're worlds apart. Here's a good example: I'm an iOS developer, and have been since pretty much day 1 of the platform. I recently actually started playing around with the Android SDK, and environment. I followed Google's supplied tutorial for creating a tabbar app, and asked one of the Android devs who works with me to come take a look at the finished result. "Oh", he said, "that's deprecated now. We don't do tab bars like that any more. We use fragments instead". And sure enough, when I looked closely, Eclipse was telling me what I'd done was, in fact, deprecated and Google recommended a different approach. Except I'd followed their main tutorial for Android, step by step. Compare this with Apple, who have consistently updated their documentation for each API release. How Google could possibly think it's a good idea to deprecate a major platform feature for fragments (a good thing) and not update one of the most popular tutorials on their site to reflect this (the 'Hello Views' tutorial) is beyond me.
- phatbyte 15y ago
  I never really worked with Android so I can't speak for it. But I completely agree with you on the updated documentation, I just feel that sometimes I get a little lost when I trying to learn how to use a class or framework.
- dpifke 15y ago
  Why does a comment about Apple's documentation need to turn into a holy war versus Android? The parent said that Apple "could improve" their documentation, not that it was worse than Google/Microsoft/IBM/whomever.

radiowave 15y ago

I think it's very largely a question of what you're used to. I don't know much about Objective C, but given my knowledge of Smalltalk, the use of keywords to identify arguments seems entirely natural. But then I've never really understood why people think it's acceptable for languages to insist that you do this: myfunction("First argument","Does this one really go second?","Is there even a third?")

mahyarm 15y ago

I love the flexibility and breadth of things you can do with objective-c/c++. It's downsides mostly come from syntax, container class getting/setting is way too verbose, same with string operations. If there was a special syntax for just string and container classes, large swaths of my code would be smaller. UIKit view controller classes are also not flexible enough, and crap out in a lot of custom multithreaded operations when they shouldn't. I could reproduce the same behavior with my own classes (animations, transitions, view control, etc) using just basic UIView classes and it would work significantly better.

zxoq 15y ago
Beta version of XCode has dict[@1] or dict[@"key"] for accessing members. Makes NSNumber and objectForKey old news. It's great. :)

igorgue 15y ago

You know what I really dislike about Objective-C is that is really inconsistent with properties and messages, at one point I said out loud: JUST PICK ONE! Coming from Python this is a big thing for me, I like when there's only one right way to do things. P.S. My only experience with Objective-C is with the iOS SDK.

wvs 15y ago
You may already know this, but properties are just sugar for messages and instance variables. Their only difference is a shorter syntax. (...plus some extra runtime data, but you don't usually notice that.)

jamesu 15y ago

Anything you do not understand is inherently hard. The only thing i would say is uniquely hard about Objective C is getting your head around some of the APIs, but then again that can apply to any language.

mirkules 15y ago
To me the hardest thing is the seemingly arbitrary CG functions in Quartz2D and why they're so interspersed throughout the code. If I'm writing within the UIKit most of the time, and then have to make my own UIView for some custom drawing, I have a hell of a time remembering how, and always have to reference my earlier code, which I usually find on StackOverflow or somewhere else. Example, let's draw a line and an ellipse in drawRect: CGContextRef ctx = UIGraphicsGetCurrentContext(); //CGMove the point somewhere? //CGLineTo something //CGDrawEllipseInRect or something //stroke or fill? CGFillSomething maybe? //do i need to end the context? Maybe it's a mental block on my part, but I can _never_ remember how to do this and always have to look it up, probably because it's not part of the standard UIKit and not used on daily basis. I guess I would just like to see the Quartz stuff conform more to UIKit naming conventions (but because it's based in C, I understand why it's not)

siavosh 15y ago

I spend half my day in iOS development and the other half on a Java web stack. I love the RESULT of Obj-C+Cocoa Touch, you can achieve amazing user experience. But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues? Java isn't much better either, why all this boiler plate, and still concurrency nightmares. I've done a handful of side projects with django and that's better, but I still think if I showed my teenage self what I'm programming in, he'd wonder if there was ever any real progress. I guess what I'm saying is after all these years I want to work on a higher level, as a result I've started to play with Clojure and functional languages. Whether I'm idealizing functional/clojure life, I'll soon find out, but the appeal is very high to spend my time dealing with problem complexity, not language/framework ones.

aaronblohowiak 15y ago
Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.
- mirkules 15y ago
  A word of caution with ARC -- you still have to release certain things manually, for example CGImageRefs with CFRelease if you're doing any sort of image manipulation.
  - aaronblohowiak 15y ago
    Those aren't Objective-C objects, but I get your point. ARC does not relieve you of thinking about memory, it just makes it easier.
    - AznHisoka 15y ago
      ARC to me is scary... I got over the huge learning curve, and the nuances of autoreleasing, and retaining, and it seems like now I gotta unlearn all of that??? And not to mention some third party libraries/source code don't support ARC. To me, I'm gonna hold off using ARC as long as possible.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

iamgilesbowkett 15y ago

is it fair to TL;DR this as "Objective-C is only hard if you've never used Smalltalk"? or is that overly glib?

zoul 15y ago

People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months. What’s much more important is the conceptual complexity: the number of language features and the way they fit together. A second important thing is the standard library. Objective-C is a pleasant language by both these metrics, since there are just a few language constructs above the C level, they fit together well without creating dark corners, and Cocoa is a very mature and well thought-out framework. The iOS Objective-C ecosystem does take some time to master, but so does every modern SDK, since the libraries are always huge. Programming is hard and if somebody is scared by minus signs in front of method names, evil spirits will suck his soul out by the time he gets to thread synchronization.

phatbyte 15y ago
I couldn't agree more. Everything is "hard" on the first couple of times, but the only recommendation I say to people is to stop worrying about the language, and go create stuff, get into that mindset of creating something, even if it's just a simple app. that will allow us to research and ask things around, and that's when you learn and progress. Nobody achieves anything by bitching around how hard this and that is.
- AshFurrow 15y ago
  You're right - I should have called it "Why Objective-C is Hard to Learn"; all of the issues I enumerate are surmountable with enough experience and experimentation.
mogui 15y ago
agreee totally with you, it is isn't hard at all
unicron 15y ago
I've put together a few things with Objective C over the years dating back to OSX 10.1 (yuck PB sucked then) to iOS. Most ended up being ported to Java or C#. The syntax IS absolutely horrible if you ask me as it results in crazily verbose ways of expressing stuff. Everything is "too meta" and there are very few first class parts of the language. It still FEELS like it's hacked together with C macros (which was what it originally was). Add to that the reference counting implementation (when GC is not enabled which you can't do on iOS) and it's just painful. Also the lack of any decent threading abstraction - ick. I think there is a lot of hype around it. It's not where we should be in 2012. Android does better with bastardised Java if you ask me.

outworlder 15y ago

I might be just me, but I've always found Objective-C's syntax very nice (compared to, say, C++). It might be verbose, but you have a clear separation between C and Objetive-C. If it doesn't contain "[]" or "@", my brain can just parse it as C code.

deleted 15y ago
[deleted]

cwbrandsma 15y ago

I find Objective-C hard as well, but it has more to do with the nature of the message passing syntax that objective-c has. For instance, for the life of me I CANNOT get calls to NSNotificationFactory right the first try, and there are no compiler hint to help you...it just doesn't work for some reason. There are other items like that. Not much help when the app crashes, lack of Namespaces (class name collisions), etc. Then throw in all the fun of submitting an app to the store. Working with iAds and In App Purchases will make you want to hurt something.

augustl 15y ago

Hard is OK. Over time, you become better at it, until it's no longer a problem -- it's a relative thing. Not saying easy is bad, but hard isn't _that_ big of a problem. Example: I find Russian very hard to speak. That doesn't mean Russian IS hard, I just don't know russian. And some languages are harder (more stuff to learn) than others. See http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

dustineichler 15y ago

I'm going to disagree. Objective-C is an ASNI C derivative language. Programming for me at least isn't knowing the syntaxual elements of a language but leveraging paradigms I know to exist from one language to the next. Objective-C while looks different, is really no different than most languages. It definitely shouldn't be your first language, maybe not even your 2nd choice, but if you have a conceptional knowledge of programming languages and you're keen on diving into the deep end, there's enough resources out there you're not going to drown. I love Objective-C for many reasons, but then again I equate programmatic choice to personalities. If that makes sense. Point being, don't be deterred. iOS SDK is something else all together, but like anything worth learning, learn by doing. What you should probably decide for yourself is if this article makes it seem harder than it is. His conclusion about Automatic Reference Counting is on the money, but that's about it. "When learning Objective-C, it's not just a language or a framework or a runtime or a compiler, it's all of these things". No is not. These are different. If anyone is considering learning this language, there's a bunch of unsolved problems that frequently include writing new libraries. Cheers.

ja27 15y ago

It's not that bad. A little verbose, but it's not like switching from C to Lisp or Prolog.

rsbrown 15y ago

You had met at "... like broccoli or sexual intercourse". Great read, well written.

batista 15y ago

Forget the fact that we're not even talking about methods, really, we're talking about messages (a distinction I'm not going to make) and you refer to selectors like the one above as performAction:withTwoParameters:. Most people don't care anymore. Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is basically 99% "Smalltalk in square brackets". Nobody complains that Smalltalk has a strange syntax, even small kids seem to use Squeak just fine. [object performAction: param1 withTwoParameters: param2] not that different to: object.performAction(self, param1, withTwoParameters=param2) in Python, or any language with named parameters. The syntactic differences are superficial. You don't even have to know about selectors and messages to understand the gist of what that invocation will do. "OMG, method parameters have a name" --well, big effin' deal. Ever seen C++ (especially the recent standard)? Or the beast with 1000 features C# has become? Obj-C compared is leanness personified. The ACTUAL source of complexity in programming in Objective-C is the huge Cocoa (et al) API. But a huge API, especially nicely documented as Cocoa is, and with such breadth and nice MVC design, is a GOOD THING. This tightly-coupled codesign is unique to Objective-C. There are other languages that run on .Net, such as Iron Python. Lots of language use the JVM besides Java, like Clojure. Even Ruby and Rails are two distinct entities and projects. The only significant effort to use a different language with Cocoa/Cocoa Touch and the Objective-C runtime, Mac Ruby, was a project largely backed by Apple before they abandoned it. Actually, there are several efforts besides MacRuby to use another language with the Objective-C runtime: Nu (Lisp like), F-script (Smalltalk like). But the main difference here is that the Objective-C runtime is a very simple runtime, not a full VM, so the comparison to CLR and Java is not that apt. For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5. In general, not that good of an article...

SeanLuke 15y ago
withTwoParameters is actually part of the method signature. It's not a keyword identifier. So [object performAction: param1 withTwoParameters: param2] is roughly equivalent to object.performActionwithTwoParameters(param1, param2)

algoshift 15y ago

Nah. Not hard. Different. People have a natural inclination to resist the new. My guess is that a competent programmer with OO experience should be comfortable with Objective-C within a week or two of study.

bobstobener 15y ago

Not looking for trouble here but writing an iPhone app should be no more difficult than creating a Keynote presentation, imho. If Apple is the leader in document development (Keynote, etc), why can't they do the same with writing apps. Look at what they've done with the complexities of video editing. Where is the consumer grade development app for iPhone?

thought_alarm 15y ago

The entire article is about how Smalltalk syntax is different from C syntax, something that any reasonably competent programmer gets over very quickly. And he gets it wrong. The article is a complete waste of time.

glaurent 15y ago

I know Objective C, C++, Java and have basic knowledge of C#. Of all these I'd rate Objective C as the easiest to learn and to handle. It's much more forgiving and easy on the programmer, and the syntax is trivial. You seem to make a big case of the message passing syntax, but your example is very poorly chosen. Rather than 'performAction:withTwoParameters:' it should be 'performActionWithFirstParameter:andWithSecondParameter:' as are most Cocoa methods. Named parameters may seem verbose but they are much more readable than 'performAction(param1, param2)'. If Objective C is a "large" language, I wonder what you'd call C++ or C#. Huge ? Humongous ? If you think Cocoa is large and complex, the C++ Standard Library or the Java library will make you weep.

Deinumite 15y ago
Actually the C++ STL is known for being pretty small... that also depends on if you even count the C stuff that C++ includes.
cageface 15y ago
The C++ standard library is actually quite small. Check Herb Sutter's keynote at Going Native 2012 for an entertaining visualization of its size compared to the Java or C# standard libraries: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
- glaurent 15y ago
  Compared to the Java and C# libs, yes, the C++ std lib is small. In terms of complexity and ease of use, it's a different picture.
  - cageface 15y ago
    The IO libraries are kind of a mess but I don't find the algorithms and containers significantly more difficult to use than similar implementations in other languages.

scrod 15y ago

>However, they're also adding to the language in ways that makes the code expressed in Objective-C simpler: >Synthesizing properties >Dot-syntax for accessing getters/setters >Garbage Collection >Blocks (closures) >Automatic Reference Counting >Weak references Sorry, but none of these things make the language any simpler — they all add yet another style of doing things that only raises the bar and the learning curve for new developers when reading existing code, in precisely the same way that C++ and Perl have done. And this is true even of garbage collection (which, by the way, is deprecated in 10.8), because it needs to coexist with other frameworks and code that might not be garbage-collected, and more importantly because all heap-allocated C buffers consequently require their own low-level wrappers (e.g., NSAllocateCollectable, objc_memmove_collectable, etc.).

AznHisoka 15y ago

Before I took the jump to learn Objective C and iPhone development, I dreaded the huge learning curve needed. Now that I'm on the other side, I LOVE the fact it intimidates people :)

imaginaryunit 15y ago

Minor point that has always bugged me: why doesn't Cocoa have native implementations of tree data structures?

astrange 15y ago
http://ridiculousfish.com/blog/posts/array.html http://ridiculousfish.com/blog/posts/array.html

dgallagher 15y ago

It's best to think of Obj-C method call syntax as a sentence, written in english, which happens to also be computer code. If you name your methods and variables succinctly and explicitly, the language is extremely readable and documents itself (assuming you know english). Obj-C was the first language I learned after Python. I remember the 2nd month in, it went from being difficult to read, to extremely easy. Obj-C code can be written terribly, like this: NSString *someString = @"hello what's up?"; NSMutableString *anotherString = [NSMutableString stringWithString:@"I have more to say, don't I?"]; NSArray *stringArray = [NSArray arrayWithObjects:someString, anotherString, nil]; NSUInteger stringArraySize = [stringArray count]; Messy Obj-C code! Human eyes like simplicity, like right angles, and columns. Same code, more readable: NSString *someString = @"hello what's up?"; NSMutableString *anotherString = [NSMutableString stringWithString:@"I have more to say, don't I?"]; NSArray *stringArray = [NSArray arrayWithObjects:someString, anotherString, nil]; NSUInteger stringArraySize = [stringArray count]; Takes an extra few seconds of typing, but goes miles.

redthrowaway 15y ago
The same is true of most programming languages. Simple things like layout improve readibility, and thus productivity, immeasurably.
cageface 15y ago
If you use the new AppCode Obj-C IDE, you can get formatting like the latter for free.

JVIDEL 15y ago

I know this is a short article meant to explain the basics but I don't like how under the History section it makes no mention of NeXT or Stepstone which were the creators of ObjectiveC.

kln 15y ago

Rather than performAction:firstParameter withTwoParameters:secondParameter which is kind of confusing. You should name it performActionWithTwoParametersFirst:firstParameter andSecond:secondParameter if you insist on calling your method performAction

andr3w321 15y ago

For me the most annoying thing about learning xcode/objective-c is apple tries to force you into buying a Mac.

prodigal_erik 15y ago
That's a deficiency of the iOS platform, not the ObjC language. It's just that ObjC is brittle and tricky enough that there's no longer much reason to learn it unless you're working on iOS (or possibly MacOS, if you think that'll stay relevant), though GNUstep is portable if you really want to.

cageface 15y ago

Really the only thing that makes Obj-C the language hard is that the C layer pokes through often enough that you really do need to understand C as well and C presents a lot of pitfalls to a new programmer.

cmelbye 15y ago

I personally love the syntax of Objective-C. I find it very readable. I wish I could use it more often.

pjmlp 15y ago

I don't understand all these comments about Objective-C being hard. Maybe it is because I am programming computers since the Z-80 days, or because like it is expected in my country I did a good earned CS degree. If you think using a language like Objective-C is hard, maybe you should not be programming at all.

julik 15y ago

Well, from my limited experience with Objective-C a few things made it hard. The first is the traditional Cocoa pattern of a method that does useful things, which looks like this: - (void)beautifullyNamedMethodFor { void* ugly_ptr_type; // and around 45 more CFObscurePtrRef* .. = CFObscureObsoleteFunction(NULL, NULL,.....); // 56 arguments // to the callback omitted for brevity ...*....(*foo)...->(*x++); // and so one - with 45 lines of NULL ptrs passed as void* to CF calls // juggled and incremented ad absurdum until your eyes bleed. } So on the surface it's a beautiful Smalltalkish thing, while down below it's usually all hairy C, pointers and null-terminated strings and Core Foundation callbacks right out of MacOS 7 (especially if you want anything useful to be done that is not in Cocoa by default). This always seemed to me to be a deception in a way. Another pet peeve of mine is the same agony of choice that is object variables (pointers versus values). When I want to return something or declare a variable, even when I am in the rose-tinted-glasses Cocoa world of beautifully-named methods, classes and keyword arguments I still have to put the dreaded death star in front of just the right things (and to remember NOT to put it in front of exactly proper other things). So I guess for me the most problematic Objective-C part is the one that has to do with C (because it adds a level of complexities on top of C). The "Objective" part is actually very nice, once you get used to the call syntax and the brackets.

jinushaun 15y ago

The only item I agree with is the last item: Objective-C is a nebulous term because it's so intrinsically tied to Apple and Cocoa/UIKit. The syntax? You pick it up within a week. Message passing versus method invocation? An important, but subtle distinction. So what makes Obj-C hard? For me, it was Apple's gigantic MVC-style framework. Rewiring my brain to grok Obj-C was nothing compared to grokking Foundation Kit, UIKit and AppKit. Growing up with C++, C# and Java, you get used to a particular way of doing thing. APIs are designed and interacted with in a certain way. Apple's API feel completely different. From building strings and making network connections to working with images and animations. Apple's version just feels different.

hboon 15y ago

Objective C isn't hard. Ruby isn't hard. Building a great app is hard. Building and running a great service is hard. Building and running a great company is hard. Most commonly used programming languages aren't hard.

xiaoma 15y ago

Is MacRuby truly abandoned? If so, then I'm saddened. I just started experimenting with it recently and found it to be the answer to everything that frustrated me about obj c.