
Stop the Hate: Obj-C Deserves Your Love - renaebair
http://intridea.com/2010/7/13/stop-the-hate-obj-c-deserves-your-love
======
ant5
As someone who has been, on and off, writing Objective-C for the past decade,
I will unequivocally state that as application programming languages go, it's
a terrible 1980s jalopy of bad language decisions cobbled on top of more bad
language design under which Smalltalk-descendent ideas peek through now and
then.

Language research has progressed. Microsoft has invested heavily in C# and
related technologies. Even Smalltalk research moved on -- strongtalk,
newspeak. We have alternative, real-world usable languages running on the JVM,
from Scala to Clojure.

Yet Objective-C moves forward one slow, stuttering step at a time. There are
no namespaces. There are no self types (your init methods all have to return
id so that they don't conflict with other init methods that have the same
name). There are no private methods. Writing an initializer takes 3 lines of
boilerplate, every time, plus the header declaration:

    
    
      if ((self = [super init]) == nil)
        return nil;
    
      return self;
    

The language is obtuse, ridiculously verbose, frustrating to use, and
downright paleolithic compared to modern deployed languages. It's a joke
compared to everyone else's modern language research. I suffer through it full
time because that's what the platform demands, but I would shoot it in the
head in a second if I could.

Nuke it from orbit. It's the only way to be sure.

Anyone who thinks ObjC is a good language either hasn't actually spent
significant time outside of C/C++/ObjC, or is still new to the wide, wonderful
world of Mac/iPhone development.

~~~
jawngee
As someone who does a ton of Objective-C, I challenge the notion that
namespaces are even remotely necessary. I've also done development in nearly
everything under the sun, in nearly every "popular" language under the sun,
which challenges your other assumption that anyone who thinks Objective-C is
good hasn't spent time outside of C/C++/Objective-C.

I'm guessing you've never written a Windows app with C++ and MFC. Or have done
any hardcore UI development in C# or Java - both languages that are easily way
more verbose - and require way more boilerplate - than Obj-C.

My assumption is that you simply don't grok it, that you haven't learned how
to utilize dynamic dispatch, KVO, etc. to greatly simplify and streamline your
application designs. Or you are one of those script kids that takes all the
low level shit for granted. This isn't python. This isn't ruby. This isn't
even smalltalk. It's a high level layer on top of a low level language. You
don't get that kind of performance without some sacrifice, but rest assured
that sacrifice is significantly less than C/C++ while maintaining similar or
the same performance.

~~~
ant5
_As someone who does a ton of Objective-C, I challenge the notion that
namespaces are even remotely necessary ..._

Apple is now suggesting that you use three-character class name prefixes,
since they claim all the two character ones. I had my two character prefix
claimed by a new private framework Apple added to iOS, and now one of my class
names conflict with one of theirs. Kaboom.

If you go the no-prefix route, your code isn't library-reusable since other
people will do the same thing, and you will still get screwed -- Apple
regularly claims non-prefixed classes in their code, too.

 _My assumption is that you simply don't grok it, that you haven't learned how
to utilize dynamic dispatch, KVO, etc. to greatly simplify and streamline your
application designs. Or you are one of those script kids that takes all the
low level shit for granted. This isn't python. This isn't ruby. This isn't
even smalltalk._

Seeing as you're writing ObjC using a compiler I've worked on, I think that
probably understand the "low level shit" better than you do.

~~~
jawngee
So you work on GCC and are complaining about mostly legacy C things?

What?

~~~
Zev
The best way to hate a language is to implement it. It forces you to learn all
the ins and outs of the language, every nook and obscure corner that
something, somewhere, depends on.

------
probablycorey
He is at the first stage of Cocoa development. Learning a new language is fun,
and you can create some really cool stuff with the Cocoa frameworks. But once
that wears off you are left with Objective-C, a vestigial language that isn't
suited for a majority of application development.

Here are some reasons I think Objective-C needs to be retired:

\- Header Files: These are archaic and require you to repeat code
unnecessarily. Compiler's shouldn't require humans to do something that
computers are better at.

\- No Automatic Garbage Collection: In ObjC 2.0 we have this, but not on the
iPhone. Unless you are making a high performance game, there is no reason the
phone can't handle Automatic GC.

\- No NSDictionary/NSArray literals: [[NSDictionary alloc]
initWithObjectsAndKeys:@"value", @"key", @"value2", @"key2", nil]; // Enough
said

\- No regex: You kind of get regex's in 3.2+, but they are very limited and
require around 3-4 lines of setup to get anything done.

\- Xcode: You are pretty much required to use Xcode and I don't like Xcode.
Even if you use the "xcodebuild" CLI, you still have to create the project
through Xcode.

\- Closures: I guess we will be able to use these soon, but it is going to
take awhile for all the API's to get updated to accommodate them.

\- No dynamic variables: It's handy to be able to shove data into objects
sometimes. It's a hack, but as long as you treat it as such you can save a lot
of needless code. (You can do this via the ObjC runtime, but it's messy)

\- Unit Testing: It barely exists and is difficult to use.

\- No namespacing: ObjC handles namespaces by prefixing class names. Blah,
that is so 1978.

~~~
cpprocket
Am I the only person in the world who happened to like header files? It's a
nice tool (for me) to separate interface declaration from modules/classes, so
it's much easier to navigate massive codebases without the help from IDE.

Seriously, how would you get a list of all functions in a module without an
IDE? Besides, I put all my documentation into h-files as well, so other devs
can pretty much see what I am doing without ever glancing at c-files.

With Ruby or Java you need some advanced folding support in your editor or a
full-fledged IDE.

~~~
jawngee
No I'm with you re: header files.

These "people" don't also seem to get when you distribute a lib, you need to
distribute headers with them.

------
famfam
Didn't see a single explanation of why the language deserves my love. Let's
see.

* The language is verbose.

* Practically speaking, it's only used to developer for two platforms (OSX and iOS).

* The frameworks for those platforms are MEGA verbose.

* The memory management model for the iOS platform is not GC, and it's not manual management. Frankly I found manual management of memory simpler than retain/release. And the autorelease pool? That's just wrong.

* Typically speaking back to two files per class.

* Doesn't have any functional elements to it whatsoever. Any manipulation of collections = instant development velocity kill.

* Typically have to deal with two different kind of strings (NS versus C).

So for now, yep, I still hate ObjectiveC.

~~~
jawngee
> Typically have to deal with two different kind of strings (NS versus C).

NSString has plenty of methods to deal with this, and you get boxing for free
between CFString and NSString.

> The frameworks for those platforms are MEGA verbose.

Which some view as self documenting.

~~~
Zev
_NSString has plenty of methods to deal with this, and you get boxing for free
between CFString and NSString._

And that pesky char * that you get from C.

------
redstripe
I don't understood why people think automatic deallocation = garbage
collection = slow language. You can have reference counting without garbage
collection. It's pretty obvious to a compiler when a variable has gone out of
scope and can be dereferenced (and deallocated immediately at 0).

Using a language like obj-c where you have to do memory management manually
just seems so archaic after using modern languages. Plus there is strange
property duplication syntax, split header/code files, a GUI editor that
doesn't easily wire events to code, named parameters, c/smalltalk calls mixed
together, etc.. it's just a mess.

In my brief stint using it the whole time I kept thinking this would be so
much simpler if I could do it the XYZ language way. Obj-C is a language that
you have to try really hard to like. If you have to convince yourself then
maybe it's not that good.

~~~
protomyth
First, even the "manual" version of garbage collection (the retain/release)
pattern is pretty trivial with Objective-C (more so with the new property
syntax). Once you know the rules it was pretty automatic and really didn't
cause that many problems. It was more a problem with the "checklist" language
comparisons.

The "property duplication syntax" (I assume you mean the declare versus
synthesis) is there for flexibility and so you can do some pretty good
customization to make your classes work better.

For OS X, Objective-C now has garbage collection that works pretty well.

~~~
vegashacker
Objective-C's retain/releasing is only trivial if you're doing fairly simple
stuff. Ever create a circular reference with objects? Ugh...

------
towndrunk
So the post is about how he had to learn Objective-C quickly because they
fired their iPhone developer. If you look under Services on their web page
they have this...

"Our mobile development team is highly specialized in creating applications
for many popular mobile platforms including the iPhone..."

Does "highly specialized" mean learned it last night...

~~~
jeremymcanally
Hah, oops. I think Sean meant at a previous employer. All of our mobile devs
are seriously skilled (f.e., Brendan Lim delivers talks all over the place
about mobile dev) and check out our work (Mashable, Oil Reporter, etc.). Er,
point is: our mobile devs rock. :)

------
probablycorey
The worst part is Apple forces you to use Objective-C on the iPhone even if
better options exist. I created a Lua/Cocoa bridge
[http://probablyinteractive.com/2009/10/18/Setting-up-
iPhone-...](http://probablyinteractive.com/2009/10/18/Setting-up-iPhone-
Wax.html) that works wonderfully. It considerably cuts down the amount of code
I need to write, but Apple forbids me from using it on the iPhone.

------
bensummers
_One of the limitations of Objective-C, the inability to create a function
with a variable length argument list ..._

Erm, not true. For example, NSString's

    
    
      + (id)stringWithFormat:(NSString *)format, ...

~~~
vegashacker
How do you _create_ such a function though? stringWithFormat is built in.

~~~
ant5
Like any other vararg function:

    
    
      + (NSString) stringWithFormat: (NSString *) format, ... {
          NSString *string;
          va_list ap;
      
          /* Fetch the arguments */
          va_start(ap, format);
          // Could iterate over the arguments yourself here, or just use:
          CFStringRef cfString = CFStringCreateWithFormatAndArguments(NULL, NULL, (CFStringRef)format, args);
          string = [NSMakeCollectable(cfString) autorelease];
          va_end(ap);
      
          return string;
      }

------
bitwize
Intended audience of article is Rubyists and other users of dynamic languages
who are unfamiliar with having to code in a C style. Probably small subset of
HN readers.

I would recommend use of Objective-C without Apple frameworks to anyone who
must build robust modular systems while retaining C compatibility or
performance characteristics. I use it myself in a game engine.

------
ambulatorybird
This makes me feel old -- when I was learning programming/CS, memory
management and storage classes were part of basic training. Now we've got a
generation of programmers who've never had to worry about these things.

~~~
redstripe
Just because it's good to be aware of how memory management works doesn't mean
you should be dragged through tedious manual tasks every time you code.

Assembler was probably part of many peoples basic training as well. Do you
want to spend your days juggling everything in 4 general purpose registers
because it makes you feel like a better programmer? Is that the best use of
your time?

------
fintler
Just thought I'd mention <http://rubydcamp.org/>. The people who wrote this
post are sponsoring it (I'm not affiliated with them at all).

------
cageface
I'm supposed to be impressed because Obj-C does reference counting?

It really is sad that so little of the state of the art in GC is available in
mainstream languages.

~~~
jws
I'd say he more aiming to _comfort_ than _impress_. The good part is that
because of the homogenous paradigm there are three rules to learn about when
to retain/release. You find them, read them, think about it for 10 minutes,
and then get on with programming.

You could contrast it with malloc/free in the unix/C ecosystem. Get a pointer
back from function X in library Y. What do you do when you are done? free?
call X_Z? constraints on the order of freeing dependent objects? That is a
trip to the man pages every time.

~~~
cageface
Cheering about doing better than malloc in 2010 is like being happy that you
can outrace a Model T in the Indy 500.

------
jimbokun
The discussion for another article on the front page discusses why, even
today, many developers prefer C-family languages over Java for developing user
interfaces, because of unpredictable delays in responsiveness with garbage
controlled languages.

In that context, Objective C is the closest you will find to a best of both
worlds language for responsive user interfaces. Being a strict superset of C,
you can control the performance characteristics of your application to your
hearts content. With SmallTalk style message passing, you can implement highly
dynamic object oriented designs.

The warts that come along with this are the places where C still pokes through
when you just want to work in a high level object oriented context and things
like header files and static variables rear their ugly heads.

~~~
cageface
You can easily get unpredictable delays in responsiveness with reference
counting too. How can you be sure releasing that reference isn't going to
unleash the teardown of some huge data structure?

~~~
jawngee
If it does than you are doing something incredibly wrong.

I'm really starting to doubt the intelligence of HN.

~~~
cageface
s/than/then/g

~~~
jawngee
@cageface really? you can't refute my point, so you instead try to correct my
spelling to make yourself look smarter?

~~~
cageface
If you choose to attack someone's intelligence instead of presenting a factual
counterargument then it behooves you to get your spelling right.

So again, how can you be sure that the reference you just released isn't the
last live pointer to some huge datastructure that now has to be torn down
reference-by-reference?

~~~
jawngee
Like I said, if that happens you are doing something incredibly wrong. It is
your error. It's not the language, it's bad programming, bad architecture, bad
whatever.

If you release an object and it gets torn down, it means you didn't increment
the ref in the right place. And I don't get how release/retain is such a
difficult concept to grasp. If you don't think you can deal with it, should
this be your profession?

~~~
cageface
Brushing aside the unnecessary and uncalled for rudeness...

If you release the last pointer to a complex datastructure that has no other
references, you certainly should hope it gets "torn down" = deallocated. If
that object happened to contain a lot of other objects they will each in turn
have to be released. Obviously your main code execution path is going to halt
while this graph is walked and released.

Maybe Jimbokun is right that you can control this better in a ref counting
scheme than in a typical GC but you're hardly immune from the problem.

------
seanalltogether
This one always tickles me

NSObject Class Reference

– performSelector:

– performSelector:withObject:

– performSelector:withObject:withObject:

why stop there, lets tack on more withObject arguments

------
tlrobinson
I'd actually go a step further and argue Objective-C is actually closer to
Ruby than to C. So close, in fact, that MacRuby implements Ruby's object
system using Objective-C's runtime.

Syntax and naming conventions are another matter...

~~~
chrismealy
That's because ruby and objective-C are both inspired by smalltalk.

------
vinhboy
As someone who is also learning Obj-C, it would be awesome if someone can
provide some resources relating to

Ruby --> Obj-C or PHP --> Obj-C

Just for references sake. Or some "gotchas".

------
Tichy
Why does it deserve our (my) love again? I am missing the pro-love arguments
in that article.

