
Why Objective-C is Hard - AshFurrow
http://ashfurrow.com/2012/03/why-objective-c-is-hard/
======
zoul
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.

~~~
dkarl
I couldn't disagree more. Objective-C is a product of the 1980s, when it kind
of made sense that your program would crash if you did this:

    
    
        [NSArray arrayWithObjects:@"Hello", @"World"];
    

Of course it crashes! You have to add a nil sentinel value to the end of your
list of objects, silly. And of course it compiles with only a warning, just
like when you leave out the @ that makes the difference between a C string
literal and an NSString. Those errors will crash your program as soon as the
code is run, but they compile as valid Objective-C. Things like that are just
a nuisance if you tell the compiler to treat warnings as errors, though. If
you really want to know why Objective-C is hard, why not trust the authorities
on Objective-C, namely Apple?

Where Apple tells you _you will screw this up_ is memory management. To start
with, there are four different memory management schemes: C memory management
for C objects, manual reference counting, automatic reference counting, and
garbage collection. You get to choose two, of which C will be one. Objective-C
originated as enhancements on top of C, and Objective-C programmers writing
Cocoa apps still have to rely on C APIs for some functionality, so you'd think
by now they would have provided a better way of managing, say, the arrays of
structs you sometimes have to pass to the low-level drawing functions. Nope;
everyone still uses malloc and free. Failure to make malloc and free obsolete
is hard to forgive.

From the other three memory management methods, pick one. (Different OS
versions support different ones.) Automatic reference counting (ARC) is the
latest and apparently the new standard, though manual reference counting is
still supported, and GC is still supported on Mac OS. Reference counting
requires a little bit more thinking than garbage collection. For example,
since the Cocoa APIs were written with reference counting in mind, some
objects, notably UI delegates, are held as weak references to avoid reference
cycles. You basically have to manage those objects manually: create a strong
reference to keep the object alive and then delete the strong reference when
you decide it's okay for the object to be collected. (I'm not sure, but I
think this is true even if you turn on GC, because delegate references remain
weak.)

All reference-counting systems have that problem, but at least they have the
benefit of determinism, right? When you pay that much attention to object
lifetimes, you get to piggyback other resource management on top of memory
management and kill two birds with one stone. (In C++ it's called RAII, and
it's the saving grace of C++ that almost completely makes up for C++'s other
warts.) However, according to Apple, this technique should not be used with
Objective-C:

 _You should typically not manage scarce resources such as file descriptors,
network connections, and buffers or caches in a dealloc method. In particular,
you should not design classes so that dealloc will be invoked when you think
it will be invoked._

Why not? Application tear-down is one issue, but that doesn't matter for
resources that are recovered by the OS when a process terminates. "Bugs" are
given as a reason, but I think they mean bugs in application code, not in the
Objective-C runtime. The main reason, then, is that if your Objective-C
programs leaked file descriptors and network connections as often as they
leaked memory, the world would be in a sorry state:

 _Memory leaks are bugs that should be fixed, but...._

Remember the "I don't mean to be a ___, but..." discussion?

 _Memory leaks are bugs that should be fixed, but they are generally not
immediately fatal. If scarce resources are not released when you expect them
to be released, however, you may run into more serious problems._

In other words, if you really need something to work reliably, you had better
use a different mechanism, because you don't want your management of other
resources to be as unreliable as your management of memory. That's a pretty
strong statement that you _will_ screw up memory management whatever your best
efforts.

So apparently Objective-C memory management is hard. That's what Apple thinks,
anyway.

The quotes are from the "Practical Memory Management" section of Apple's
memory management programming guide:
[https://developer.apple.com/library/mac/#documentation/cocoa...](https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/memorymgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW1)

~~~
stream_fusion
> You should typically not manage scarce resources such as file descriptors,
> network connections, and buffers or caches in a dealloc method. In
> particular, you should not design classes so that dealloc will be invoked
> when you think it will be invoked.

Do they propose an alternative mechanism to handling resources other than
reference counting? As you state, RAII breaths life into c++, given how well
it works for all types of resources.

It sounds like the above statement is possibly being made in anticipation of
the introduction of garbage collection, which would make piggybacking resource
destruction non-deterministic. Whereas, it could also be interpreted as a very
strong reason to favor manual (maybe automatic) reference counting, and eschew
GC entirely. I don't know objective-c very well, but I wonder if the use of GC
has generated these arguments against it from within the OSX developer
community.

~~~
dkarl
That's an interesting hypothesis, but I can't find any source to confirm or
contradict it offhand. The part I took the quotes from only mentions that the
order of dealloc'ing objects in a collectable object tree is undefined, as is
the thread on which dealloc is called. Both of those are easy to keep in mind
while implementing dealloc, though. If a resource has to be freed from a
particular thread, then dealloc can schedule it to be released on the right
thread using GCD. The non-deterministic order of dealloc'ing would rarely be a
problem for releasing resources. After all, if a resource is only used via a
particular object, and that object is dealloc'ed, then clearly it's okay to
release that resource! Perhaps there are complicated cases where resources
have to be released in a particular order, but that's no reason to give up
RAII for simple cases.

------
siavosh
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.

~~~
batista
_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?_

Because Objective-C targets everyday desktop apps and mobile apps. In that
space, manual memory management still wins the day.

For example, in Windows and Linux DESKTOP those kind of apps are ALSO made in
C++ or C.

Java and C# are for the web server and the CORPORATE desktop (in-house apps).

Not many major end user apps outside the enterprise are made with either. Not
any famous, widely used ones, anyway. Azureus, maybe, and a few dozen more.

~~~
_delirium
There's also Minecraft, one of the best-selling videogames of 2011. :)

~~~
pooriaazimi
Nothing, not even a Flash video makes my MacBook Pro hotter than 5 minutes of
Minecraft...

~~~
unicron
That's because your MacBook Pro is poorly designed. I had the same problem
with mine. One reason I sold it - impossible to sit with it on my lap.

Another example: <http://www.youtube.com/watch?v=5AZzPZ0kjyk>

I now had a ThinkPad X220 which is roughly the same CPU as the MacBook Pro and
has twice the memory and it never even gets warm.

------
stcredzero
_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>

(That's the Ur wiki, BTW.)

Thoughtful post but with less than stellar marks for research.

------
tmcw
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.

~~~
ejames
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
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.

~~~
ahlatimer
The guidelines for Ruby are to add a bang (!) to any methods that mutate the
object rather than returning a new one. That's not strictly followed, though,
but for most of the commonly used standard library bits, you can be fairly
certain that that is the case.

~~~
chc
In practice, even in the standard library, this isn't followed often enough to
rely on. Here's a (possibly incomplete, since I'm writing this on the fly)
list of bangless mutating methods just from Array:

    
    
      pop
      push
      shift
      unshift
      <<
      clear
      replace
      delete (and friends)
      keep_if
    

As an even more extreme example, IO contains precisely one bang-method,
despite the fact that probably 75% of IO's instance methods are destructive.

The general rule seems to be that if there's a mutating and non-mutating
version of the same method, the mutating one will get a bang, but when there's
a mutating method with no counterpart, it _might_ get a bang but probably
won't.

~~~
Argorak
The guideline is: if your method does something that the programmer should
think twice about or shouldn't use without proper knowledge (e.g. didn't read
the docs), use !. An incomplete case of usages:

    
    
      - There is a safer alternative (e.g. mutating vs. non-mutating or skipped validation)
      - It should only be called once in a process (e.g. Padrino.start!)
      - It is non-reversible (many statemachine libraries use action! as the way to invoke state transitions, which might not be reversible)
    

This doesn't mean that every method needs to be suffixed by ! if it does
something destructive. `delete` in the context of an ORM is standard, so it
doesn't have a bang. The whole point of `pop` is to manipulate the receiver:
no point in warning about it. IO is always destructive, so ! doesn't make
sense either.

------
phatbyte
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
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.

~~~
dpifke
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.

~~~
286c8cb04bda
_> The parent said that Apple "could improve" their documentation, not that it
was worse than Google/Microsoft/IBM/whomever._

Do you have any examples of big libraries where "they could improve the
documentation" is untrue? I can't think of any offhand.

(This is not snark. I'm honestly interested if you do.)

APIs are perpetually under-documented, in my experience, so the parent
comment's observation is essentially an empty statement.

------
dustineichler
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.

------
outworlder
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.

------
dgallagher
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.

~~~
cageface
If you use the new AppCode Obj-C IDE, you can get formatting like the latter
for free.

------
gdubs
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.

~~~
AshFurrow
I'm not saying that the information isn't available - I'm only saying that to
someone new to the framework, it's hard to know what you don't know yet.

As a concrete example, you actually _can_ do myLayer.frame = someRect. The
results might not be what you expect, especially if the CALayer exists in a
hierarchy already and if the anchor point isn't the centre of the layer, but
how would you know that if you hadn't experimented already?

~~~
gdubs
Right, it won't cause a crash -- just unpredictable results. My point was more
that dot syntax doesn't always equate to easier coding;

In this particular case though, who would be playing with the CALayer class
without ever having touched the documentation? The overview of view geometry
(frame, anchor point, bounds, position) is second only after the Core
Animation introduction in the docs. And it's pretty clear: when you get a
frame from a layer, it is an implicit function of the anchor point, position
and bounds -- but the frame itself is not stored (when you set it).

So, if you're using dot syntax to store properties throughout your code, and
then you use it on the frame property, a casual reading of the code might lead
someone to think that you could retrieve that value later and have it be the
same.

(Here's what Joe Conway says about the dot-notation syntax:
<http://weblog.bignerdranch.com/?p=83> )

~~~
AshFurrow
>> who would be playing with the CALayer class without ever having touched the
documentation?

How many hackers out there always read the entire manual before playing
around? I'd wager most.

I agree that Objective-C is slightly schizophrenic about the dot-syntax, but I
would argue that dot-syntax for getters and setters is easier for a newcomers
to learn.

~~~
gdubs
I'm not saying one has to read the manual before playing around, but some
things are simply not explorable with at least a little bit of introduction.
You had to read _somewhere_ that [NSObject alloc]init] was how to create a new
object; you didn't just guess at it. Similarly, how far would someone get
creating a CALayer, and adding it to a view without ever looking at the docs?

If someone is having a hard time learning Objective-C, maybe the real
suggestion is to start by reading at least a bit of the manual.

------
thought_alarm
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.

------
radiowave
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?")

------
jamesu
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
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)

------
julik
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.

------
augustl
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>

------
bobstobener
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?

------
k-mcgrady
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
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"

------
jinushaun
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.

------
glaurent
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.

~~~
cageface
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...](http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-
Beyond)

~~~
glaurent
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
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.

------
mahyarm
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
Beta version of XCode has dict[@1] or dict[@"key"] for accessing members.
Makes NSNumber and objectForKey old news. It's great. :)

------
cwbrandsma
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.

------
pjmlp
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.

------
kln
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

------
cageface
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.

------
algoshift
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.

------
JVIDEL
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.

------
AznHisoka
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 :)

------
hboon
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
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.

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

~~~
prodigal_erik
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.

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

~~~
astrange
<http://ridiculousfish.com/blog/posts/array.html>

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

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

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

------
batista
_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
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)

~~~
batista
_withTwoParameters is actually part of the method signature. It's not a
keyword identifier._

Sure, but it's not like that distinction is really important for the
programmer. For most intends and purposes, he can just think of those as
keyword identifiers

\--or, better, as a kind of keyword identifiers that also have to be present
whenever referring to the method.

Not that big of a deal.

~~~
SeanLuke
> Sure, but it's not like that distinction is really important for the
> programmer. For most intends and purposes, he can just think of those as
> keyword identifiers

(I'll use lisp conventions, it's what I'm used to)

What you're saying is for coders, saying

    
    
        (doit x y :withFloat 5 :key "string")
    

has no important distinctions with

    
    
        [foo doit:x:y withFloat:5 key:"string"]
    

But keywords have defaults if they're missing. And furthermore you can have
them in any order. So to implement the equivalent of the Lisp method above,
I'd have to implement _all_ of the following methods in Objective-C

    
    
        doit::withFloat:key:
        doit::key:withFloat:
        doit::withFloat:
        doit::key:
        doit::
    

That's just for two keywords. What happens when you have ten?

------
igorgue
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
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.)

------
scrod
> _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.).

------
sgonyea
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.

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

