5 ms·

Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and t

Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and then to move transparently up to a much higher level of abstraction for non-critical code. With the relatively underpowered processors of today's mobile devices, this kind of control is important. However, Obj-C completely falls on its face for anything of real algorithmic complexity. Working with complex, nested data structures and more sophisticated algorithms is very awkward, and manual memory management only clouds things further. In the longer run this may become a liability for Apple.

zoul 16y ago
I fail to see how manual (or, in this context, explicit) memory management could “cloud things”. (It seems to me simply like many programmers can’t be bothered to invest the afternoon it takes to learn Cocoa memory management.) Also, could you elaborate why Objective-C makes it hard to work with nested data structures and sophisticated algorithms? In fact, I am struggling to find an example of at least a single general-purpose language that makes working with ”sophisticated algorithms” hard.
- uxp 16y ago
  I have never understood what is so difficult about Cocoa/ObjC's memory management. In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative. At least we don't have to declare how much memory to alloc and dealloc manually.
  - leon_ 16y ago
    If you just keep to "release what you alloc/new/copy" you'll be golden.
    - nupark2 16y ago
      Except for retain cycles. Which are easy to cause with blocks, and even without blocks can make dealing with thread-safety near impossible (think weak referenced delegate and race conditions between its -dealloc and messages that are being sent to it).
- cageface 16y ago
  The kinds of algorithms you can express very cleanly in a functional language, like Haskell, for example, are a lot more awkward when you have to worry about managing memory at each intermediate step. Look at all the monkeying around you have to do with __block declarations etc. For typical Obj-C code, where you're just gluing together bits of the Cocoa API, I agree that Obj-C's memory management isn't too bad. When you're trying to work at a higher level of abstraction, it's a distraction. Writing complex algorithms in Obj-C is a pain because of it's incredibly clumsy syntax for collections and the manual coercion of elemental types back and forth to objects. Look at an implementation of a neural net or something as simple as k-means clustering in Obj-C, then C++, then Scala or Haskell to see how poor Obj-C is for this kind of thing. For example, imagine how much worse this would be in Obj-C: https://github.com/cageface/brains/blob/scala/src/main/scala/brains/clustering/KMeans.scala https://github.com/cageface/brains/blob/scala/src/main/scala... Admittedly, Scala is particularly nice for this kind of thing, and Java is no better than Obj-C, but even C++ gives you much better tools for abstracting this kind of code.
  - schrototo 16y ago
    So? Then don't write those kinds of things in Objective-C. I wouldn't want to write UI code in Haskell either...
    - cageface 16y ago
      So what do you do when you want to implement a neural net or Bayesian filter, for example, in your iPhone app then? I drop into C++ for this but that's hardly ideal.
      - schrototo 16y ago
        I don't have any experience with this, but shouldn't it be possible to compile Haskell code into a static library?
        cageface 16y ago
        I think it would be difficult. You'd have to get both runtime libraries to play nicely together, but the point is that Obj-C, while quite nice for UI work, isn't good at this kind of thing.

zoul 16y ago

I fail to see how manual (or, in this context, explicit) memory management could “cloud things”. (It seems to me simply like many programmers can’t be bothered to invest the afternoon it takes to learn Cocoa memory management.) Also, could you elaborate why Objective-C makes it hard to work with nested data structures and sophisticated algorithms? In fact, I am struggling to find an example of at least a single general-purpose language that makes working with ”sophisticated algorithms” hard.

uxp 16y ago
I have never understood what is so difficult about Cocoa/ObjC's memory management. In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative. At least we don't have to declare how much memory to alloc and dealloc manually.
- leon_ 16y ago
  If you just keep to "release what you alloc/new/copy" you'll be golden.
  - nupark2 16y ago
    Except for retain cycles. Which are easy to cause with blocks, and even without blocks can make dealing with thread-safety near impossible (think weak referenced delegate and race conditions between its -dealloc and messages that are being sent to it).
cageface 16y ago
The kinds of algorithms you can express very cleanly in a functional language, like Haskell, for example, are a lot more awkward when you have to worry about managing memory at each intermediate step. Look at all the monkeying around you have to do with __block declarations etc. For typical Obj-C code, where you're just gluing together bits of the Cocoa API, I agree that Obj-C's memory management isn't too bad. When you're trying to work at a higher level of abstraction, it's a distraction. Writing complex algorithms in Obj-C is a pain because of it's incredibly clumsy syntax for collections and the manual coercion of elemental types back and forth to objects. Look at an implementation of a neural net or something as simple as k-means clustering in Obj-C, then C++, then Scala or Haskell to see how poor Obj-C is for this kind of thing. For example, imagine how much worse this would be in Obj-C: https://github.com/cageface/brains/blob/scala/src/main/scala/brains/clustering/KMeans.scala https://github.com/cageface/brains/blob/scala/src/main/scala... Admittedly, Scala is particularly nice for this kind of thing, and Java is no better than Obj-C, but even C++ gives you much better tools for abstracting this kind of code.
- schrototo 16y ago
  So? Then don't write those kinds of things in Objective-C. I wouldn't want to write UI code in Haskell either...
  - cageface 16y ago
    So what do you do when you want to implement a neural net or Bayesian filter, for example, in your iPhone app then? I drop into C++ for this but that's hardly ideal.
    - schrototo 16y ago
      I don't have any experience with this, but shouldn't it be possible to compile Haskell code into a static library?
      - cageface 16y ago
        I think it would be difficult. You'd have to get both runtime libraries to play nicely together, but the point is that Obj-C, while quite nice for UI work, isn't good at this kind of thing.