5 ms·

Meh. I do not program in Objective-C but I think I can provide more reasons for liking the language than the linked article contains :) Reason 1: When you need

by praptak 15y ago

Meh. I do not program in Objective-C but I think I can provide more reasons for liking the language than the linked article contains :) Reason 1: When you need what C provides, it is right there for you (being a superset of C) Reason 2: When you need what C does not provide (basic reflection, generics, polymorphism, whatever) it is in the "bracket" part of Objective-C. Reason 3: The two above do work quite well together - the impedance mismatch is minimal, compared to e.g. Python with extensions written in C.

blub 15y ago
One of these days I will write a detailed account of my experience learning Obj-C, but for now I'll say this: The fact that Obj-C takes C and adds objects on top is its biggest flaw, just like with C++. Worse than C++ though, Obj-C doesn't even attempt to fix at least some of C's more glaring flaws... you get the whole language, quirks and all.
- chalst 15y ago
  I think it depends on what you want from the language. If you want to write C and gain some safety through the use of the message-passing abstraction, it's perfect. If you want a real high-level language, it's lousy.
  - falling 15y ago
    With clang, ObjC is getting very interesting features that take it closer and closer to "real" high level languages, like GCD, ARC and blocks. I'd still like more type safety, but the evolution there is slower and would need more fundamental changes to the language and abandoning C compatibility.
    - eropple 15y ago
      I dunno--in an age where we have actual, halfway decent garbage collection, referring to ARC as something that might compete favorably with those "real" high level languages makes my eyes go a bit crossed.
      - kstenerud 15y ago
        When you're writing for underpowered chips, ARC is a godsend. If you're writing for a mac, there's GC available.
      - falling 15y ago
        It shouldn't. GC is not perfect, ARC is not perfect, no language is perfect. All of them can be improved. ObjC is definitely being improved.
      - tptacek 15y ago
        People in 2011 lose weeks to tuning allocators and collectors in real high level languages. C programmers take a memory profile, deploy the appropriate pool/arena allocator, and get on with their job, comfortable with the fact that their former allocation bottleneck is now in the average case register-fast. ARC fits better with the C world of quickly tuning bottlenecks to register speed. Have you ever debugged C code with custom object lifetimes under a garbage collector? It's a nightmare.
        pvg 15y ago
        People in 2011 lose weeks to tuning allocators and collectors in real high level languages. But that's, statistically, almost no people out of 'people who use GC'. There aren't that many allocators in common use that even have much in the way of tunable parameters (I can only think of the JVM ones, offhand), the people who spend weeks tuning them have very particular needs - high throughput, low latency, high-enough complexity to warrant a high-level language. These are the sort of people who also do things like start at a PHP page and end up chasing performance improvements in the bowels of a network kernel driver. It's done, but it's unrepresentative. ARC fits better with the C world It seems like a much more central reason ARC is more suitable than a GC for Objective C than 'GC tuning is occasionally a dark art'.
        tptacek 15y ago
        What can I tell you here? You're right, of course: most apps don't care about performance at all, either in space efficiency or time efficiency. Those apps shouldn't use C, and should certainly use a GC'd language. I'm only reacting to the idea that (pp) "because it's 2011, nobody should be using ARC". Well, a statistically tiny number of apps may require the bare-metal performance that hand allocation provides, but they're also disproportionately important apps.
IPlusOneYou 15y ago
Or you could pick a well thought out OO language like Java or C#, maybe even Python. Unfortunately you're trapped using the abomination for iPhone development unless you pick Monotouch.
- plinkplonk 15y ago
  "well thought out OO language like Java" Not even Java's fans would defend it as a "well thought out OO" language. Since this is Hacker News, it maybe appropriate to point out that nothing prevents you from building whatever specific flavour of OO you want on top of the Objective C runtime, if you want it badly enough.
- pnathan 15y ago
  I would not call Python a well-thought out OO language. Its OO is essentially a cranked up dict; the abstraction over the dict is just barely papered over. It can get pretty awkward.
jballanc 15y ago
You can actually go one step further with your "Reason 2". Many may not realize this, but everything that you can do with the "bracket" part of Objective-C you can also do with straight-up C and the Objective-C Runtime methods. This is where I get to promote my favorite page of documentation ever: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
- weaksauce 15y ago
  That's an excellent page, thanks! This actually makes me wonder... how much overhead is in each objective c object over a similar struct in c?
  - kstenerud 15y ago
    In terms of size, they're almost the same (Objective-C classes are implemented with structs). In terms of speed, the difference is absolutely huge. You can generate a random number faster than you can make an Objective-C call. But, it's fast enough for 95% of things people do with it.
    - infinite8s 15y ago
      Exactly. Many of the benefits of Obj C's dynamism come into play with the UI, where the main speed constraint is the response time of the user. And whenever you need to write compute bound code it is easy to drop down into C.
    - madmoose 15y ago
      Objective-C message sends are not much slower than C++ virtual calls: http://mikeash.com/pyblog/performance-comparisons-of-common-operations-iphone-edition.html http://mikeash.com/pyblog/performance-comparisons-of-common-... And that's from 2008. Clang's improved it a lot.
      - Groxx 15y ago

by praptak 15y ago

blub 15y ago

One of these days I will write a detailed account of my experience learning Obj-C, but for now I'll say this: The fact that Obj-C takes C and adds objects on top is its biggest flaw, just like with C++. Worse than C++ though, Obj-C doesn't even attempt to fix at least some of C's more glaring flaws... you get the whole language, quirks and all.

chalst 15y ago
I think it depends on what you want from the language. If you want to write C and gain some safety through the use of the message-passing abstraction, it's perfect. If you want a real high-level language, it's lousy.
- falling 15y ago
  With clang, ObjC is getting very interesting features that take it closer and closer to "real" high level languages, like GCD, ARC and blocks. I'd still like more type safety, but the evolution there is slower and would need more fundamental changes to the language and abandoning C compatibility.
  - eropple 15y ago
    I dunno--in an age where we have actual, halfway decent garbage collection, referring to ARC as something that might compete favorably with those "real" high level languages makes my eyes go a bit crossed.
    - kstenerud 15y ago
      When you're writing for underpowered chips, ARC is a godsend. If you're writing for a mac, there's GC available.
    - falling 15y ago
      It shouldn't. GC is not perfect, ARC is not perfect, no language is perfect. All of them can be improved. ObjC is definitely being improved.
    - tptacek 15y ago
      People in 2011 lose weeks to tuning allocators and collectors in real high level languages. C programmers take a memory profile, deploy the appropriate pool/arena allocator, and get on with their job, comfortable with the fact that their former allocation bottleneck is now in the average case register-fast. ARC fits better with the C world of quickly tuning bottlenecks to register speed. Have you ever debugged C code with custom object lifetimes under a garbage collector? It's a nightmare.
      - pvg 15y ago
        People in 2011 lose weeks to tuning allocators and collectors in real high level languages. But that's, statistically, almost no people out of 'people who use GC'. There aren't that many allocators in common use that even have much in the way of tunable parameters (I can only think of the JVM ones, offhand), the people who spend weeks tuning them have very particular needs - high throughput, low latency, high-enough complexity to warrant a high-level language. These are the sort of people who also do things like start at a PHP page and end up chasing performance improvements in the bowels of a network kernel driver. It's done, but it's unrepresentative. ARC fits better with the C world It seems like a much more central reason ARC is more suitable than a GC for Objective C than 'GC tuning is occasionally a dark art'.
        tptacek 15y ago
        What can I tell you here? You're right, of course: most apps don't care about performance at all, either in space efficiency or time efficiency. Those apps shouldn't use C, and should certainly use a GC'd language. I'm only reacting to the idea that (pp) "because it's 2011, nobody should be using ARC". Well, a statistically tiny number of apps may require the bare-metal performance that hand allocation provides, but they're also disproportionately important apps.

IPlusOneYou 15y ago

Or you could pick a well thought out OO language like Java or C#, maybe even Python. Unfortunately you're trapped using the abomination for iPhone development unless you pick Monotouch.

plinkplonk 15y ago
"well thought out OO language like Java" Not even Java's fans would defend it as a "well thought out OO" language. Since this is Hacker News, it maybe appropriate to point out that nothing prevents you from building whatever specific flavour of OO you want on top of the Objective C runtime, if you want it badly enough.
pnathan 15y ago
I would not call Python a well-thought out OO language. Its OO is essentially a cranked up dict; the abstraction over the dict is just barely papered over. It can get pretty awkward.

jballanc 15y ago

You can actually go one step further with your "Reason 2". Many may not realize this, but everything that you can do with the "bracket" part of Objective-C you can also do with straight-up C and the Objective-C Runtime methods. This is where I get to promote my favorite page of documentation ever: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html http://developer.apple.com/library/mac/#documentation/Cocoa/...

weaksauce 15y ago
That's an excellent page, thanks! This actually makes me wonder... how much overhead is in each objective c object over a similar struct in c?
- kstenerud 15y ago
  In terms of size, they're almost the same (Objective-C classes are implemented with structs). In terms of speed, the difference is absolutely huge. You can generate a random number faster than you can make an Objective-C call. But, it's fast enough for 95% of things people do with it.
  - infinite8s 15y ago
    Exactly. Many of the benefits of Obj C's dynamism come into play with the UI, where the main speed constraint is the response time of the user. And whenever you need to write compute bound code it is easy to drop down into C.
  - madmoose 15y ago
    Objective-C message sends are not much slower than C++ virtual calls: http://mikeash.com/pyblog/performance-comparisons-of-common-operations-iphone-edition.html http://mikeash.com/pyblog/performance-comparisons-of-common-... And that's from 2008. Clang's improved it a lot.
    - Groxx 15y ago