8 ms·

Stop the Hate: Obj-C Deserves Your Love

24 points by renaebair 16y ago

towndrunk 16y ago
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 16y ago
  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. :)
- deleted 16y ago
  [deleted]
- renaebair 16y ago
  I just edited the blog post for clarity: Sean was working for another company when he first learned Obj-C. I don't think he specified that in his post initially, because it probably seemed so obvious (to him) that something like that would never happen at Intridea. :)
tlrobinson 16y ago
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 16y ago
  That's because ruby and objective-C are both inspired by smalltalk.
ambulatorybird 16y ago
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.
- jawngee 16y ago
  It's making me feel old too. GET OFF MY LAWN YOU DAMN KIDS WITH YOUR FANCY PYTHON.
- Tichy 16y ago
  Actually even with gc enabled languages, you can create memory leaks. Hence you still need to know a little bit on how it works. However, I fail to see why I should have to worry about it and do it manually.
- redstripe 16y ago
  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?
deleted 16y ago
[deleted]
redstripe 16y ago
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 16y ago
  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 16y ago
    Objective-C's retain/releasing is only trivial if you're doing fairly simple stuff. Ever create a circular reference with objects? Ugh...
  - famfam 16y ago
    reference counting != "manual garbage collection"
- gte910h 16y ago
  >Using a language like obj-c where you have to do memory management manually just seems so archaic after using modern languages. That's not an Objective C thing, the language has garbage collection, just it isn't enabled for the mobile platform, for the reason it eats power and memory.
fintler 16y ago
Just thought I'd mention http://rubydcamp.org/ http://rubydcamp.org/. The people who wrote this post are sponsoring it (I'm not affiliated with them at all).
bitwize 16y ago
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.
probablycorey 16y ago
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.
- jeremymcanally 16y ago
  Compared to other C-supersets, it's not the worst thing ever, but yeah I totally agree with you that Obj-C is painful compared to many newer languages. So glad that MacRuby is pretty much usable now. I just wish I could use it for iPhone development. :)
  - gte910h 16y ago
    Out of C, C++ and Objective-C, I'll take objective C any day.
- cpprocket 16y ago
  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.
cageface 16y ago
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 16y ago
  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 16y ago
    Cheering about doing better than malloc in 2010 is like being happy that you can outrace a Model T in the Indy 500.
bensummers 16y ago
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 16y ago
  How do you create such a function though? stringWithFormat is built in.
  - bensummers 16y ago
    http://developer.apple.com/mac/library/qa/qa2005/qa1405.html http://developer.apple.com/mac/library/qa/qa2005/qa1405.html
  - ant5 16y ago
    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; }
  - famfam 16y ago
    It's the same as in C. va_list, va_start, va_arg, va_end, etc.
famfam 16y ago
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.
- ant5 16y ago
  I agree with all your points but this one: 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. retain/release + autorelease pools solve the ownership problem inherent in manual memory management system. You can return a heap allocated object from your function/method and neither you nor the caller have to be concerned about how it will be cleaned up. Not sure what's wrong with that solution -- I've even implemented/used an equivalent implementation for pure C code.
- jawngee 16y ago
  > 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 16y ago
    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.
  - famfam 16y ago
    Hah, okay, make it 3 then. I was only thinking of NSString and char*.
Tichy 16y ago
Why does it deserve our (my) love again? I am missing the pro-love arguments in that article.
ant5 16y ago
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.
- city41 16y ago
  I pretty much totally agree. I released two apps in the app store (one was a rather elaborate game). I feel I experienced enough to get a feel for what the language is like, and I came away unimpressed. At the most basic level, how verbose the language is is what bugged me the most. You gotta type like crazy to get anything done in Obj-C.
- jawngee 16y ago
  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.
vinhboy 16y ago
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".
seanalltogether 16y ago
This one always tickles me NSObject Class Reference – performSelector: – performSelector:withObject: – performSelector:withObject:withObject: why stop there, lets tack on more withObject arguments
probablycorey 16y ago
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-Wax.html http://probablyinteractive.com/2009/10/18/Setting-up-iPhone-... 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.
jimbokun 16y ago
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 16y ago
  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 16y ago
    If it does than you are doing something incredibly wrong. I'm really starting to doubt the intelligence of HN.
    - cageface 16y ago
      s/than/then/g
      - jawngee 16y ago
        @cageface really? you can't refute my point, so you instead try to correct my spelling to make yourself look smarter?
        cageface 16y ago
        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?

24 points by renaebair 16y ago

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 16y ago
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. :)
deleted 16y ago
[deleted]
renaebair 16y ago
I just edited the blog post for clarity: Sean was working for another company when he first learned Obj-C. I don't think he specified that in his post initially, because it probably seemed so obvious (to him) that something like that would never happen at Intridea. :)

tlrobinson 16y ago

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 16y ago
That's because ruby and objective-C are both inspired by smalltalk.

ambulatorybird 16y ago

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.

jawngee 16y ago
It's making me feel old too. GET OFF MY LAWN YOU DAMN KIDS WITH YOUR FANCY PYTHON.
Tichy 16y ago
Actually even with gc enabled languages, you can create memory leaks. Hence you still need to know a little bit on how it works. However, I fail to see why I should have to worry about it and do it manually.
redstripe 16y ago
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?

deleted 16y ago

[deleted]

redstripe 16y ago

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 16y ago
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 16y ago
  Objective-C's retain/releasing is only trivial if you're doing fairly simple stuff. Ever create a circular reference with objects? Ugh...
- famfam 16y ago
  reference counting != "manual garbage collection"
gte910h 16y ago
>Using a language like obj-c where you have to do memory management manually just seems so archaic after using modern languages. That's not an Objective C thing, the language has garbage collection, just it isn't enabled for the mobile platform, for the reason it eats power and memory.

fintler 16y ago

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

bitwize 16y ago

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.

probablycorey 16y ago

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.

jeremymcanally 16y ago
Compared to other C-supersets, it's not the worst thing ever, but yeah I totally agree with you that Obj-C is painful compared to many newer languages. So glad that MacRuby is pretty much usable now. I just wish I could use it for iPhone development. :)
- gte910h 16y ago
  Out of C, C++ and Objective-C, I'll take objective C any day.
cpprocket 16y ago
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.

cageface 16y ago

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 16y ago
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 16y ago
  Cheering about doing better than malloc in 2010 is like being happy that you can outrace a Model T in the Indy 500.

bensummers 16y ago

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 16y ago
How do you create such a function though? stringWithFormat is built in.
- bensummers 16y ago
  http://developer.apple.com/mac/library/qa/qa2005/qa1405.html http://developer.apple.com/mac/library/qa/qa2005/qa1405.html
- ant5 16y ago
  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; }
- famfam 16y ago
  It's the same as in C. va_list, va_start, va_arg, va_end, etc.

famfam 16y ago

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.

ant5 16y ago
I agree with all your points but this one: 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. retain/release + autorelease pools solve the ownership problem inherent in manual memory management system. You can return a heap allocated object from your function/method and neither you nor the caller have to be concerned about how it will be cleaned up. Not sure what's wrong with that solution -- I've even implemented/used an equivalent implementation for pure C code.
jawngee 16y ago
> 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 16y ago
  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.
- famfam 16y ago
  Hah, okay, make it 3 then. I was only thinking of NSString and char*.

Tichy 16y ago

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

ant5 16y ago

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.

city41 16y ago
I pretty much totally agree. I released two apps in the app store (one was a rather elaborate game). I feel I experienced enough to get a feel for what the language is like, and I came away unimpressed. At the most basic level, how verbose the language is is what bugged me the most. You gotta type like crazy to get anything done in Obj-C.
jawngee 16y ago
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.

vinhboy 16y ago

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

seanalltogether 16y ago

This one always tickles me NSObject Class Reference – performSelector: – performSelector:withObject: – performSelector:withObject:withObject: why stop there, lets tack on more withObject arguments

probablycorey 16y ago

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-Wax.html http://probablyinteractive.com/2009/10/18/Setting-up-iPhone-... 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.

jimbokun 16y ago

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 16y ago
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 16y ago
  If it does than you are doing something incredibly wrong. I'm really starting to doubt the intelligence of HN.
  - cageface 16y ago
    s/than/then/g
    - jawngee 16y ago
      @cageface really? you can't refute my point, so you instead try to correct my spelling to make yourself look smarter?
      - cageface 16y ago
        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?