
In defence of Objective-C - chubs
http://splinter.com.au/in-defence-of-objective-c
======
5hoom
Does Objective-C really need defending?

After doing a couple of projects with it I've found it to be a really
beautiful language from a code formatting point of view.

The whole 'overly verbose' thing is probably just because you are encouraged
to give your methods and arguments good _descriptive_ names, and often when
you do need short variable names for some maths calculations or something it
will be while inside a method block using good old C style anyway.

I don't know, it's flexible, (arguably) attractive and it runs fast.

Yay Objective-C! :)

~~~
chubs
Wow - this is fantastic! I'm glad i submitted this now, just reading the
comments here is very heartening. I was beginning to think i was the only guy
in the world who liked obj-c :) (i work in a c#/java predominaated environment
where most people troll me about obj-c all day!)

~~~
5hoom
I'd always considered myself a C++ guy before picking up obj-C, but looking at
the result I get from the two I'm finding I'm just a lot faster with obj-C.

Now I have no desire to incite a language flamewar (to each their own blub!),
so I will leave it at that ;)

------
mquander
_For example, to filter an array is lovely:_

    
    
      filteredArray = [allRecords filteredArrayUsingPredicate:
        [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]];
    

A four-word name for _filter_ and filtering for equality by using a string
formatting DSL are not really on my list of lovely things. I'm sure
Objective-C does something well but this guy is not pointing it out.

~~~
glenra
Yeah, I found that line hideous - ridiculously unintuitive and hard to read
compared to the equivalent in say, ruby.

Maybe the whole essay would have been better framed something like: "Objective
C: not quite as bad as Java!"

~~~
jasonlotito
Just curious, for comparison: what would the equivalent be in Ruby?

~~~
rbxbx

        filteredArray = [allRecords filteredArrayUsingPredicate:
            [NSPredicate predicateWithFormat:@"someField == %d",   someFieldFilterValue]];
    

in ruby:

    
    
        all_records.select {|r| r.some_field == some_field_filter_value}
    

in clojure:

    
    
        (filter #(= % some-filter-value) all-records)
    

in haskell:

    
    
        filter (\someField -> x == someFilterValue) allRecords

~~~
icodestuff
Let's be fair, in Objective-C, this could be actually more like

    
    
      NSIndexSet *indicies = [allRecords indexesOfObjectsPassingTest:^ (id obj, NSUInteger idx, BOOL *stop) { return [obj someField] == someFieldFilterValue; }];
      filteredArray = [allRecords objectsAtIndexes:indicies];
    

rather than what the article had in mind.

EDIT: oh, someFieldFilterValue was an integer, wasn't it. Fixed.

------
DrJokepu
I don't think these are the real problems with Objective-C.

To quickly address this issues, before discussing the real problems: "Ugly" -
get over it, "Verbose" - get over it, "Memory Management" - Obj-C memory
management is in fact super simple as long as you follow some really simple
rules, especially with ARC.

Now the real problems I have:

1\. Lots of unnecessary code. With the old runtime, you had to modify your
code at four (!) places to introduce a new property in a class. With the new
runtime, that has decreased to three, with ARC, to only 2, but that's still
one more than what should really be necessary (@synthetize should go).

2\. The whole header file thing. I know that Obj-C is a descendant and strict
superset of C but I still find separating header files from .m files somewhat
tedious and unnecessary. This leads to

3\. Having to declare methods and properties before you use them. I mean, this
is 2011, this shouldn't be necessary.

4\. The syntax for having "private" methods and properties is awkward even by
Obj-C standards. Basically you have to create an anonymous category in the
implementation file.

5\. Properties (with ARC) should default to strong for objects, assign for
everything else.

6\. The [[X alloc] init] way to construct objects; I understand that from a
theoretical point of view it's cool to separate allocation from initialisation
but I've never ever needed to allocate an object with anything other than the
alloc message.

7\. The debugger. GDB and Xcode are atrocious. Have a look at the C# debugger
in Visual Studio; that's how a debugger should look like.

Overall, while a lot has been improved recently in Obj-C, my main gripes with
the language all come from the facts that it's a C superset (which is also a
massive advantage) and that it's an almost 30 years old language; the
programming world was very different 30 years ago.

~~~
chriseidhof
Very true, all of this would improve the language a lot. I have often thought
about writing a language that does these kind of things and compiles to Obj-C.

Also, I would love to be able to do some kind of metaprogramming without
resorting to strings.

~~~
domhofmann
I'm trying to do just that with a project I started a few days ago called
Khaki. It's a bit of a learning exercise and quite early, but you might find
it useful in a month or two.

<https://github.com/dominikhofmann/khaki>

------
flitzwald
There is one thing in Objective-C that still gets my goat, even after 8 years
of working with it: it's the lack of syntax for container-types:

[NSMutableDictionary dictionaryWithConstructorIDontWantToType:...]

is just a huge pain in the ass. Other problems with the syntax have been
solved by introducing sugar at the right place. Why not

    
    
      id hash=@{ @"key" : @"value };
    

and

    
    
      id array=@[ @"value1", @"value2", @"value3"];

~~~
hboon
Can't get rid of the issue completely, but at least we can have:

#define MD(val, key, vals...) [NSMutableDictionary
dictionaryWithObjectsAndKeys:val, key, ## vals , nil]

then do:

NSMutableDictionary* dict = MD(@"value1", @"key1", @"value2", @"key2")

And so on. Courtesy of <http://news.ycombinator.com/item?id=1789839>.

~~~
stephth
That _## vals_ syntax is new to me. What's the difference with the following?

    
    
      #define MD(...) [NSMutableDictionary dictionaryWithObjectsAndKeys:__VA_ARGS__, nil]

~~~
hboon
Both of them wouldn't work for MD() due to the trailing nil.

But for MD(val, key, vals...), it'd give you a slightly better error,
complaining about the number of arguments when you do MD().

Otherwise they are the same in this case.

## removes one non-whitespace character – often the comma – before the ## if
vals or __VA_ARGS__ is empty.

e.g

    
    
      #define MO_LogDebug(fmt, ...) NSLog((@"DEBUG " fmt), ##__VA_ARGS__)
    
      MO_LogDebug(@"This works as expected %d", resultCode);
    
      // Removes the comma automatically in here:
      // NSLog((@"DEBUG " @"This works too without args"), );
      MO_LogDebug(@"This works too without args");

------
fbuilesv
I wonder if I'm the only person that thinks that Xcode is the problem, not
ObjC. Having experience with C I feel just fine writing code in Objective-C,
but only the thought of trying to use Xcode instead of Emacs is painful.

I'd love to know what Eclipse/VS/NetBeans users think about it, maybe it's
easier if you're already used to working inside a huge IDE.

~~~
5hoom
No, you're not the only one.

Most of the problems I've hit with iOS development are Xcode-isms.

I've recently been sent on a merry hunt to get the built-in git integration
from imploding, and the project groups vs folders ambiguity has caused
mistakes of the "what actual file is this name pointing too again?" variety
(and this in turn leads back to the git integration issues when a file is not
where you think it is).

It would also be nice if Objective-C++ was a first class citizen with regards
to refactoring tools (I understand this might be hard to implement however).

Rarely has it been a problem with the actual language itself.

~~~
dbattaglia
I believe JetBrains have an Obj-C IDE now. Haven't tried it yet but I know
they are pretty good at the whole refactoring thing (I use ReSharper at work
all the time).

------
kitsune_
I'm (some what) proficient in many programming languages. Some more than
others. I've worked in languages like Python, Eiffel, C#, C++, Prolog, Java,
OCaml, F#, Ruby and as of recently, after a long hiatus, Haskell.

I have such a strong dislike for Objective-C, I can't explain it. I mean C++
is insane in a way, and Haskell is a pure Mindbender. But Objective-C's
syntax, to me, is indeed so verbose, I'd rather read the EU regulations on
"the common organisation of agricultural markets".

I had to create a couple of iPhone apps, and I probably will have to create
some more in the future.

Is there any way for me to overcome my unnatural dislike for this language?

And yeah, this article did not work for me, as you would have already guessed.

~~~
dextorious
> Is there any way for me to overcome my unnatural dislike for this language?

Grow some taste?

------
ataggart
_Go and look at some Lisp, then come back – obj-c will suddenly look better :)
... For example, to filter an array is lovely_

    
    
      (filter foo? all-records)
    

Yeah, maybe not so much.

------
tolmasky
As someone who likes Objective-C a lot, I have to say this is a pretty bad
defense of it. No offense, clearly we are both fans of the language, I just
don't think this will convince anyone on the other side. In fact, I find very
little defense of it at all in this post. It seems his fundamental argument is
"its a matter of taste", which while true, in no way conveys the many "whys"
of the choices made in this language. This is sad because most of the things
people are initially turned off by actually have very logical reasons behind
them, which over time you do grow to love and miss when you leave.

1\. The first major point (which is found at the end of this post) in any
"defense of Obj-C" should be that this is a very pragmatic language. It makes
a lot of wise tradeoffs and rarely strives for "purity" or "religion". This
helps to put a lot of the language choices in context, and actually is the
strongest reason its a great language in my opinion.

2\. "Ugly" - The point is certainly not that you "see through the brackets",
that's a terrible argument! The point is to understand why we have brackets,
because they allow for named arguments without colliding with existing C
syntax. Additionally, they make it clear to the user that what is about to
happen is _not_ a traditional method call, it is a message send. This is
because you can do _both_ in Obj-C (not to mention Obj-C++).

3\. "Verbose" - First off this is a framework decision. It's possible to take
Obj-C without Cocoa, and write a framework that is just as non-verbose as
Python (and vice versa). But fine, you could make the argument that the named
parameters "encourage" verbosity if you want. The key here is not to hand wave
this away as a matter of "taste", but to understand the logic behind this: its
_very easy to read_. I can show lots of non-programmers Obj-C code, and it
really reads like english. In fact if you just read aloud many Obj-C snippets,
it often sounds very close to English. 80% of coding is reading code, and if
you work on a big project, its reading _other people's code_. You never run
into a piece of code that has 4 arguments and have no idea what the last
"true" is for. Similarly, you never have appendChild(node1, node2) moments
where you're not sure which is the node you're appending and which is the one
being appended next to. Apple's SDK's are repeatedly praised and a big part of
that is that the frameworks are very friendly. I personally find the opposite
trend of terseness incredibly strange: why do we focus so much on shrinking
variable names.

4\. "Memory Management" - This I will admit was more or less fair. The MM
story just isn't that great with Obj-C. I have to admit I thought it wasn't a
big deal before spending a lot of time in a dynamic language, but it really is
annoying coming back to it. And while I'm not 100% sure yet, ARC is not the be
all end all. I have to say I think about memory almost just as much with ARC
(perhaps simply because I'm not used to it). At least with explicit management
I knew exactly what was going on, with ARC I kind of feel that its half magic
and half really hard situations. I really hope I'll eat my words about this
soon. Now, the counter argument is that _this_ is why Obj-C is so fast. I
honestly don't know if that's true. I know enough smart people on both sides
of the argument to say that I simply don't know enough about it.

~~~
davedx
I stopped reading at: "Things like factories, adapters, and other design
patterns are all thankfully not there."

Huh? Design patterns are "thankfully not there"? What does that even mean?

~~~
saurik
Not that I agree with him, but I do understand what he meant by that, and
might be able to explain slightly: many people believe that "design patterns"
are something that languages like Java (quite in particular, this language is
held up during these conversations) require to work around design
deficiencies.

Arguably, this is true: many of the patterns simply "fall away" if you have
access to features like multi-method dispatch (Lisp+CLOS), message passing
with transparent proxying (as in SmallTalk, and to some extent Objective-C),
or continuations (Lisp/Scheme).

However, the argument often goes even further into the realm of complaints
against "all kinds of patterns, even those that tend to exist in all
abstractions, even mathematical ones", deriding things like factories as
"overly-complex" (in the same concept of "overly-complex" that make some
people choose NoSQL over RDBMS not for scalability, but due to the common lack
of schemas).

~~~
dfox
Factory is actually perfect example of pattern that is mostly used to overcome
the fact that passing classes around is unnecessarily complex in Java and thus
it's favorable to wrap code calling constructor in it's own class and pass
instances of it. In "dynamic" languages (including ObjC) you can simply use
use the class object (and if the need arises: things that behave like class
objects) itself instead of factory in most cases.

------
chubs
Is it considered poor form around here to submit your own articles? If so, i'm
terribly sorry and will remove, however i feel strongly that a lot of people
write off obj-c based on superficial weaknesses, and that it has a lot of
strengths that are very underrated, and i wish i'd known a lot of this stuff
when i started off in iphone development.

~~~
makecheck
The guidelines[1] just say to submit something interesting/relevant, and this
is. Besides, no one knows better than you where to find your content. :)

[1] <http://ycombinator.com/newsguidelines.html>

------
jon6
-quote- Go and look at some Lisp, then come back – obj-c will suddenly look better :)

Trust me, it grows on you. You’ll soon learn to see through the brackets –
just like the green vertical text in the matrix, it becomes invisible after a
while. -end quote-

Its ironic that a Lisp/Scheme person would say the same as to why
s-expressions are good (the parens become invisible!) so I don't see why
objective-c syntax is better but somehow uses the same reasoning.

~~~
Luyt
_"You’ll soon learn to see through the brackets"_

@I @hope @that @also @applies @to @the @the @at-@signs. ;-)

~~~
dextorious
Huh? Obj-C only uses @ signs at a couple of places, like to denote a native
@"dasdasda" string and in compiler instructions...

------
plinkplonk
If you have worked in smalltalk _and_ C (a somewhat rare combination these
days, I must admit) , Objective C is trivially readable.

~~~
Derbasti
And even if you haven't, you can learn how to read it in ten minutes. Say what
you want about Obj-C, but I think its _readability_ is really outstanding.

~~~
atomicdog
[[perhaps [[not] a always] that [readable[though]]]]]

------
super_mario
I really hope Apple promotes MacRuby to first class citizen for both OS X and
iOS development. That would make things a whole lot more modern and easier.
Who knows, once we have quad core CPUs on even the lowliest of iDevices we
could see this happening.

------
zdw
_There’s a philosophy here: user happiness is prioritised over developer
happiness._

See also the App Store policies. Apple's priorities tend to be it's users,
Apple, then any 3rd party developers. I don't tend to think this is a bad
thing...

~~~
Bdennyw
Make no mistake Apple's priorities are: Apple, Users, Developers.

~~~
thought_alarm
If you're a developer (or a business), what's your priority? If it's not your
users (or your customers) then you're doing it wrong.

~~~
Androsynth
late comment that will probably never get read:

This is overly simplistic. In their heyday MS catered to developers first and
their users second. You can make some snarky comment about this, but at the
time it allowed them to become one of the largest and most powerful tech
companies out there.

Google catered to it's own engineers first.

The point is there are different ways of building a business; don't blindly
choose the Apple path just because they're currently at the top of the heap.

------
barumrho
I love it too for its readable and descriptive method names. It is also
surprisingly flexible considering its age. (I guess what I am saying is that
Apple kept it up-to-date pretty well.)

------
extension
I love Obj-C message send syntax and I miss it dearly when using any other
language. I love that a method implicitly documents itself at the call site,
and that the delimiters occur between calls rather than in the middle of them.

And it works great with code completion. You just type '[' and the editor
immediately knows what you are doing. Choose a method and the parameters are
right in front of you. No documentation required, unless you actually need in-
depth information.

~~~
masklinn
> And it works great with code completion. You just type '[' and the editor
> immediately knows what you are doing.

Whereas in other languages you'd have to write... "."?

> Choose a method and the parameters are right in front of you. No
> documentation required, unless you actually need in-depth information.

Pretty much every somewhat advanced IDE does that, especially for mostly-
statically-analyzable languages.

~~~
dextorious
> Whereas in other languages you'd have to write... "."?

You write "." AFTER you've written the method name. In ObjC "[" immediately
tells that you want a method/class name for autocompletion.

------
hamidpalo
Looking at the example given of how lovely obj-c is:

    
    
       filteredArray = [allRecords filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]];
    

Makes me wonder if the author has ever seen languages that do this like so:

    
    
       let filteredArray = Seq.filter (fun f -> f = "foo") allRecords

------
pbreit
I didn't find this very convincing at all. For starters, the code presentation
reinforces the verbosity and difficulty working with it. Don't most languages
support named parameters and in an easier to understand way? I'm not qualified
to discuss memory management but that point also left me confused.

------
bitwize
Remember Smalltalk?

Xerox PARC, GUI, inspired Steve Jobs, all that fun stuff.

Objective-C is a sort of nerfed Smalltalk bolted onto the side of C. Yes you
can see the seams and it's clunky-looking, but it works. Smalltalk semantics
means it's much easier to build robust and loosely-coupled programs than in
C++, and you don't even occur that much runtime overhead.

I do all my game dev in Objective-C, and I don't even have a Mac that I use
actively. In fact I defy people to write significant Objective-C programs that
don't use or need the Cocoa or NS libraries. I think they will have an easier
and more fun time of it than when working in C++.

------
smweber
After having spent a couple years doing embedded OS development in C,
Objective C is beautiful. The verbosity makes it much easier to read than
typical C code and the memory management is brilliant compared to doing it
yourself. It walks the line between static and dynamic types quite well, with
most things being static except when dynamic makes things a lot easier. I
think Objective C is brilliant considering what they were able to add to C
while maintaining great speed and full compatibility with C.

------
Aloisius
I dislike the NextStep libraries (and all of Apple's subsequent creations) far
more than Objective-C itself. The completely unnecessary verboseness is what
drives me up the wall.

If the libraries were designed more like C++'s (say what you will about STL,
but at least set<> is called set<>), I'd probably have no issues whatsoever.

~~~
Toady
You may dislike the verbosity, but it's hardly "completely unnecessary." A
typical Objective-C program is inherently self-documenting. It's nice knowing
what a group of arguments is used for without having to look up the method
prototype.

------
chaostheory
For me the problem isn't Obj-C. It's cocoa. (Unless things have changed,) if
everything was consistent in cocoa from a language perspective i.e. every
library / framework is accessible with Obj-C from the start as opposed to
being only C. If I remember correctly the Addressbook portion is one of the
culprits.

------
jtmille3
The only argument I'm buying into is this one...

[someInstance doSomethingWithObject:a andAnotherParam:b];

It just reads beautifully. Otherwise working with Objective-C was like pulling
teeth at times. It had been a long time since I had to write so much code to
get such simple things done.

~~~
equalarrow
Exactly. I once worked with a very smart Obj-C guy. I asked him if he could
document all the method calls so I knew what they did.

He said: there is no need. In Obj-C the selectors should document themselves.

------
jeswin
I guess, the way to defend it would be by demonstrating expressiveness. Syntax
hardly matters.

\- Closures (I guess blocks might achieve the same, never worked in Obj-C)

\- Lambdas

\- Dynamic Typing or Type Inference. You need at least one of those.

\- Or any other construct that enhances expressiveness.

------
kaffeinecoma
Not a fan of the syntax, but my real gripe is with the header files, and all
the DRY that entails. If I were Apple that's the first thing I'd aim to fix,
rather than giving us ARC.

------
philjackson
"Things like factories, adapters, and other design patterns are all thankfully
not there."

Not sure I understand this? How does Obj-c enable the developer to avoid
factories?

~~~
toadkick
Agreed. I've had to use factories in Obj-C plenty. I guess the argument that I
would make is that they are much easier to implement in Obj-C and require less
boilerplate (especially if you use blocks), not that the pattern doesn't exist
in Obj-C.

