7 ms·

I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages

I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages - though I guess this is mostly due to cocoa

unreal37 12y ago
It's not hate, but Objective-C can be intimidating.
- espitia 12y ago
  I just spent the past 2 months learning obj-c, about to release my first app and boom, X out obj-c. my luck.
  - rgbrgb 12y ago
    90% of what you learned are Cocoa frameworks and Apple-flavored OOP patterns that will be totally applicable to apps written in Swift. Fear not!
  - lstamour 12y ago
    No worries, Objective-C is faaar from deprecated.
  - brianpgordon 12y ago
    You'll always be able to contribute to NeXTSTEP. It's not dead yet!
  - krenoten 12y ago
    I don't know very much at all about objective C, but the way these things generally work is that you will benefit from the experience as you learn new languages, as it will be an anchor of context against which you may base fresh perceptions.
  - oldguysrule 12y ago
    Objective C isn’t going anywhere. Swift is shit. I suspect it will die in a couple years, like the misguided effort to get people to adopt the Java bridge or WebScript before that.
ktran03 12y ago
I never understood what the fuss was all about either. If you know one other language really well, Objective-C should take a week or two to get use to. To understand all the design patters, apple HIG, XCode, profiling, libraries, debugging, app submission, etc, these combined is where youll sink your time to learn iOS development. Imo, Objective-C is the easy part.
- mox1 12y ago
  I recently translated one of my Apps from Android to iPhone. I had 0 objective-C experience, but I made it work. It was a bit of a frustrating experience. Many times I found myself writing Objective-C boilerplate-ish code that I had 0 clue what it was doing, considering this is a hobby / for fun project I just wanted it working. It's not easy to google the answer to, "Why did I just add this new keyword after this colon in this random .h file.." I didn't want to spend the next month reading Objective-C for beginners, I know what a for loop is, I also know what constructors are. I just wanted to use the language.
  - ff10 12y ago
    You may know what a constructor is, but maybe not know what a designated initializer does. ;-)
  - cesarbs 12y ago
    I felt the same when working on iOS. I felt I was writing way too much boilerplate code, while Android and Windows Phone just gave me a lot more "for free".
  - BHSPitMonkey 12y ago
    You've just described exactly what it feels like transitioning from iOS to Android development, too.
Touche 12y ago
You may not hate Objective-C, but I doubt you love it either. Have you / would you ever use Objective-C to write a web back-end? To write a command-line tool?
- mrsteveman1 12y ago
  I've done both, they were fun projects :) The only thing that got in the way was the difficulty using the code away from OS X or iOS, and the fact that a lot of libraries for things like database access (especially those intended for iOS) were never intended to be used in a long running process. I found slow (3 week) memory leaks that someone writing an iOS app would never have hit.
- jaegerpicker 12y ago
  I actually really like Objective-C and would totally use it as a back end language if there were good libraries to make use of. I've also written a couple of command line tools in Obj-C.
- oldguysrule 12y ago
  I got started with WebObjects, a Next product a couple years before Apple bought them. Yes I've written wonderfully powerful web applications in Objective-C back when the rest of the web was being built using CGI and Perl scripts. I loved Smalltalk and I love Objective-C at a deep level. The Objective-C runtime is incredibly powerful and its method dispatch is astonishingly efficient considering what it does. It is not as fast as vtables, but it isn't as fragile either. It might well interest you to know that WebObjects (I'm talking 1997 here) ran on HP-UX, SunOS, AIX, and one other popular Unix of the day that slips my mind and it too shipped with a lively scripting language called WebScript which was not so different from a minimal Swift today. The thing is, once you dig into the Objective-C runtime and spend a bit of time trying to write an interpreter, you start to realize that the interpreter almost writes itself. Swift is far from the first language built atop the Objective-C runtime. Consider FScript (http://www.fscript.org http://www.fscript.org) has been around for well over a decade and does more or less the same thing except it gives you something closer to Smalltalk than Javascript and it includes some advanced matrix manipulation goodies as well. The majority of the people squealing with glee over the introduction to Swift seem to be the sort of people I wouldn't care to work with. If a bit of syntax puts you off so much, lord help you when a truly new paradigm hits. Swift looks to have some nice features, but it seems to be missing the low level access to the runtime that advanced developers can use like default message handlers (forwardInvocation:/doesNotUnderstand:/methodForSelector: kinds of stuff) and the ability to fiddle method dicts at runtime which can be very useful for intercepting strange errors and unexpected code paths. So, yes, I do LOVE Objective-C. It is my second favorite language to work in after Smalltalk and to those claiming that Swift will help them move over from Android because it less verbose - lets remember Java is the most boilerplate per capability language I've seen since COBOL. I don't know what those people are talking about.
whalesalad 12y ago
I also really like Obj-C now that I am familiar with it. I think the biggest pain point with iOS apps is understanding the way to build apps within the context of the iPhone (how to structure views, and the custom things like alert sheets, etc...) particularly if you are coming from a web app background. The syntax is quite nice (although sometimes verbose) once you get used to it.
badman_ting 12y ago
I don't think syntax is really the issue. Using objc these days is clunky for reasons besides syntax.
- matwood 12y ago
  Like dealing with ARC, which is still clunky: @lazy var asHTML: () -> String = { [unowned self] in if let text = self.text { return "<\(self.name)>\(text)</\(self.name)>" } else { return "<\(self.name) />" } } Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l https://itun.es/us/jEUH0.l
IanDrake 12y ago
My dislike is that it uses [] for method calls. It's like making Objective-English where we swap Z and A and j for o, just for the hell of it. If thzt sjunds like fun tj yju, thzn gj fjr Jboective-C.
- trustfundbaby 12y ago
  very genius response!
- emp 12y ago
  It's not for the hell of it. [ ] does not mean method call, it is the syntax for a message send. Objective-C is a super set of C, adding an Smalltalk like object system to C. The delimiters say "I am sending a message", which is different to a method call. Also, without them the language would be much more difficult to parse, and future changes to C could break the language. It's lasted well (first appeared in 1993). Not as long as Lisp, perhaps it needs more [ ] :)
  - dragonwriter 12y ago
    > It's lasted well (first appeared in 1993). 1983, actually.
    - emp 12y ago
      Thanks - I felt I should type 1983, but if felt wrong! I still had my Apple ][ back then.
  - IanDrake 12y ago
    Thanks. Just read up on messaging and now I like it even less :( In Smalltalk and Objective-C, the target of a message is resolved at runtime, with the receiving object itself interpreting the message. ... A consequence of this is that the message-passing system has no type checking. http://en.wikipedia.org/wiki/Objective_c#Messages http://en.wikipedia.org/wiki/Objective_c#Messages
    - 12y ago
egypturnash 12y ago
To someone on the outside of ObjC, its just SO DAMN VERBOSE. It's unapproachable the same way Java is unapproachable.
mwfunk 12y ago
I understand why ObjC's syntax makes some people bristle, but I've never felt that way myself. It's sort of like the people that really hate Python for no other reason than the meaningful whitespace. It's unconventional, but once you understand the rationale for it it makes sense in a way that is at least forgivable if not likable. There have been a lot of C-based object-oriented APIs over the years. GObject has a C API. On the Mac, there's Core Foundation and a bunch of other OS X APIs that are built on top of it. For over a decade on X11, before gtk and Qt even existed, the closest thing there was to a standard graphical environment was Motif (the corresponding desktop environment was CDE), and Motif was built on top of Xt. Xt was yet another C-based object system, although it was specialized for designing UI components. This is all well and good but you end up with a ton of boilerplate code that does nothing but manage the lifecycles of the object instances (retain/release for example), and lends itself to extremely verbose function calls in place of object methods. One possible solution is to put together some really elaborate preprocessor macros to make it look like you have extended the C language to include special syntax for your object system, so you can at least replace this: obj foo = obj_factory(); int c = obj_getNumberOfElements(foo); ...with something more compact like this: obj foo = [Obj new]; int c = [foo numberOfElements]; (the second example is ObjC-ish but the former is nothing in particular other than just what the typical C object APIs tend to look like) The only catch is that the little mini-language you are extending C with using macros can't use existing C syntax, because you can only add to the language, not alter the behavior of existing operators. So, you can't just do method calls using a dot syntax on the instance (such as foo.numberOfElements()). So, you have to come up with something new. Maybe you always liked Smalltalk, and maybe you even based much of behavior of your object system on how Smalltalk objects behave and interact? If so, you might settle on the bracket notation. This has the added benefit of making it very clear when a chunk of code is run-of-the-mill C versus when the code is triggering the syntactic sugar you created with macros to add support for your object system to the C language. C++ doesn't exist yet, or else you might've just gone with that instead of rolling your own thing. Eventually C++ does exist, and you start to feel a little primitive for sticking with the weird macro language. You eventually build your mini-language into a C compiler so you don't have use the macros anymore. You experiment with some new alternatives to the syntax that are more conventional, but no one uses them. Many developers like that the non-C-ish syntax makes it easy to distinguish between straight C code vs. interactions with the object system, which has its own set of rules and conventions. Anyway, that's mostly speculation, but something like that story is how I've always thought Objective-C evolved over the years. I don't mind it nearly as much as long as I don't think of it as a separate programming language from C (like C++ or Java or pretty much anything else these days), but rather think of it as C with some useful syntactic sugar that gets rid of a ton of boilerplate code for a particular C-based object-oriented API.
return0 12y ago
It really reeks of 80s. I 'd rather program in plain C.

unreal37 12y ago

It's not hate, but Objective-C can be intimidating.

espitia 12y ago
I just spent the past 2 months learning obj-c, about to release my first app and boom, X out obj-c. my luck.
- rgbrgb 12y ago
  90% of what you learned are Cocoa frameworks and Apple-flavored OOP patterns that will be totally applicable to apps written in Swift. Fear not!
- lstamour 12y ago
  No worries, Objective-C is faaar from deprecated.
- brianpgordon 12y ago
  You'll always be able to contribute to NeXTSTEP. It's not dead yet!
- krenoten 12y ago
  I don't know very much at all about objective C, but the way these things generally work is that you will benefit from the experience as you learn new languages, as it will be an anchor of context against which you may base fresh perceptions.
- oldguysrule 12y ago
  Objective C isn’t going anywhere. Swift is shit. I suspect it will die in a couple years, like the misguided effort to get people to adopt the Java bridge or WebScript before that.

ktran03 12y ago

I never understood what the fuss was all about either. If you know one other language really well, Objective-C should take a week or two to get use to. To understand all the design patters, apple HIG, XCode, profiling, libraries, debugging, app submission, etc, these combined is where youll sink your time to learn iOS development. Imo, Objective-C is the easy part.

mox1 12y ago
I recently translated one of my Apps from Android to iPhone. I had 0 objective-C experience, but I made it work. It was a bit of a frustrating experience. Many times I found myself writing Objective-C boilerplate-ish code that I had 0 clue what it was doing, considering this is a hobby / for fun project I just wanted it working. It's not easy to google the answer to, "Why did I just add this new keyword after this colon in this random .h file.." I didn't want to spend the next month reading Objective-C for beginners, I know what a for loop is, I also know what constructors are. I just wanted to use the language.
- ff10 12y ago
  You may know what a constructor is, but maybe not know what a designated initializer does. ;-)
- cesarbs 12y ago
  I felt the same when working on iOS. I felt I was writing way too much boilerplate code, while Android and Windows Phone just gave me a lot more "for free".
- BHSPitMonkey 12y ago
  You've just described exactly what it feels like transitioning from iOS to Android development, too.

Touche 12y ago

You may not hate Objective-C, but I doubt you love it either. Have you / would you ever use Objective-C to write a web back-end? To write a command-line tool?

mrsteveman1 12y ago
I've done both, they were fun projects :) The only thing that got in the way was the difficulty using the code away from OS X or iOS, and the fact that a lot of libraries for things like database access (especially those intended for iOS) were never intended to be used in a long running process. I found slow (3 week) memory leaks that someone writing an iOS app would never have hit.
jaegerpicker 12y ago
I actually really like Objective-C and would totally use it as a back end language if there were good libraries to make use of. I've also written a couple of command line tools in Obj-C.
oldguysrule 12y ago
I got started with WebObjects, a Next product a couple years before Apple bought them. Yes I've written wonderfully powerful web applications in Objective-C back when the rest of the web was being built using CGI and Perl scripts. I loved Smalltalk and I love Objective-C at a deep level. The Objective-C runtime is incredibly powerful and its method dispatch is astonishingly efficient considering what it does. It is not as fast as vtables, but it isn't as fragile either. It might well interest you to know that WebObjects (I'm talking 1997 here) ran on HP-UX, SunOS, AIX, and one other popular Unix of the day that slips my mind and it too shipped with a lively scripting language called WebScript which was not so different from a minimal Swift today. The thing is, once you dig into the Objective-C runtime and spend a bit of time trying to write an interpreter, you start to realize that the interpreter almost writes itself. Swift is far from the first language built atop the Objective-C runtime. Consider FScript (http://www.fscript.org http://www.fscript.org) has been around for well over a decade and does more or less the same thing except it gives you something closer to Smalltalk than Javascript and it includes some advanced matrix manipulation goodies as well. The majority of the people squealing with glee over the introduction to Swift seem to be the sort of people I wouldn't care to work with. If a bit of syntax puts you off so much, lord help you when a truly new paradigm hits. Swift looks to have some nice features, but it seems to be missing the low level access to the runtime that advanced developers can use like default message handlers (forwardInvocation:/doesNotUnderstand:/methodForSelector: kinds of stuff) and the ability to fiddle method dicts at runtime which can be very useful for intercepting strange errors and unexpected code paths. So, yes, I do LOVE Objective-C. It is my second favorite language to work in after Smalltalk and to those claiming that Swift will help them move over from Android because it less verbose - lets remember Java is the most boilerplate per capability language I've seen since COBOL. I don't know what those people are talking about.

whalesalad 12y ago

I also really like Obj-C now that I am familiar with it. I think the biggest pain point with iOS apps is understanding the way to build apps within the context of the iPhone (how to structure views, and the custom things like alert sheets, etc...) particularly if you are coming from a web app background. The syntax is quite nice (although sometimes verbose) once you get used to it.

badman_ting 12y ago

I don't think syntax is really the issue. Using objc these days is clunky for reasons besides syntax.

matwood 12y ago
Like dealing with ARC, which is still clunky: @lazy var asHTML: () -> String = { [unowned self] in if let text = self.text { return "<\(self.name)>\(text)</\(self.name)>" } else { return "<\(self.name) />" } } Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l https://itun.es/us/jEUH0.l

IanDrake 12y ago

My dislike is that it uses [] for method calls. It's like making Objective-English where we swap Z and A and j for o, just for the hell of it. If thzt sjunds like fun tj yju, thzn gj fjr Jboective-C.

trustfundbaby 12y ago
very genius response!
emp 12y ago
It's not for the hell of it. [ ] does not mean method call, it is the syntax for a message send. Objective-C is a super set of C, adding an Smalltalk like object system to C. The delimiters say "I am sending a message", which is different to a method call. Also, without them the language would be much more difficult to parse, and future changes to C could break the language. It's lasted well (first appeared in 1993). Not as long as Lisp, perhaps it needs more [ ] :)
- dragonwriter 12y ago
  > It's lasted well (first appeared in 1993). 1983, actually.
  - emp 12y ago
    Thanks - I felt I should type 1983, but if felt wrong! I still had my Apple ][ back then.
- IanDrake 12y ago
  Thanks. Just read up on messaging and now I like it even less :( In Smalltalk and Objective-C, the target of a message is resolved at runtime, with the receiving object itself interpreting the message. ... A consequence of this is that the message-passing system has no type checking. http://en.wikipedia.org/wiki/Objective_c#Messages http://en.wikipedia.org/wiki/Objective_c#Messages
  - 12y ago

egypturnash 12y ago

To someone on the outside of ObjC, its just SO DAMN VERBOSE. It's unapproachable the same way Java is unapproachable.

mwfunk 12y ago

I understand why ObjC's syntax makes some people bristle, but I've never felt that way myself. It's sort of like the people that really hate Python for no other reason than the meaningful whitespace. It's unconventional, but once you understand the rationale for it it makes sense in a way that is at least forgivable if not likable. There have been a lot of C-based object-oriented APIs over the years. GObject has a C API. On the Mac, there's Core Foundation and a bunch of other OS X APIs that are built on top of it. For over a decade on X11, before gtk and Qt even existed, the closest thing there was to a standard graphical environment was Motif (the corresponding desktop environment was CDE), and Motif was built on top of Xt. Xt was yet another C-based object system, although it was specialized for designing UI components. This is all well and good but you end up with a ton of boilerplate code that does nothing but manage the lifecycles of the object instances (retain/release for example), and lends itself to extremely verbose function calls in place of object methods. One possible solution is to put together some really elaborate preprocessor macros to make it look like you have extended the C language to include special syntax for your object system, so you can at least replace this: obj foo = obj_factory(); int c = obj_getNumberOfElements(foo); ...with something more compact like this: obj foo = [Obj new]; int c = [foo numberOfElements]; (the second example is ObjC-ish but the former is nothing in particular other than just what the typical C object APIs tend to look like) The only catch is that the little mini-language you are extending C with using macros can't use existing C syntax, because you can only add to the language, not alter the behavior of existing operators. So, you can't just do method calls using a dot syntax on the instance (such as foo.numberOfElements()). So, you have to come up with something new. Maybe you always liked Smalltalk, and maybe you even based much of behavior of your object system on how Smalltalk objects behave and interact? If so, you might settle on the bracket notation. This has the added benefit of making it very clear when a chunk of code is run-of-the-mill C versus when the code is triggering the syntactic sugar you created with macros to add support for your object system to the C language. C++ doesn't exist yet, or else you might've just gone with that instead of rolling your own thing. Eventually C++ does exist, and you start to feel a little primitive for sticking with the weird macro language. You eventually build your mini-language into a C compiler so you don't have use the macros anymore. You experiment with some new alternatives to the syntax that are more conventional, but no one uses them. Many developers like that the non-C-ish syntax makes it easy to distinguish between straight C code vs. interactions with the object system, which has its own set of rules and conventions. Anyway, that's mostly speculation, but something like that story is how I've always thought Objective-C evolved over the years. I don't mind it nearly as much as long as I don't think of it as a separate programming language from C (like C++ or Java or pretty much anything else these days), but rather think of it as C with some useful syntactic sugar that gets rid of a ton of boilerplate code for a particular C-based object-oriented API.

return0 12y ago

It really reeks of 80s. I 'd rather program in plain C.