4 ms·

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

by 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
  Thank you, that’s helpful. The algorithm is a bit above my head to rewrite in Objective-C on Sunday, but from my superficial understanding of it the Objective-C version wouldn’t be really ugly. Yes, it would be wordier and clumsier, but tolerably so (for me). After all, it’s precisely these things where functional languages shine. I seldom find I have to monkey around with __block. Manual boxing/unboxing sucks, yes. It can be alleviated by a simple macro where this really matters, but I can see such and argument is like pouring petrol into the fire when compared to functional languages :) Now I understand what was meant by “sophisticated algorithms”. Yes, Objective-C is not perfect for those – first class collections are a great convenience here. But I certainly do not see that as a future “liability for Apple” or a huge drawback for the language ecosystem. It’s a niche.

by zoul 16y ago

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
Thank you, that’s helpful. The algorithm is a bit above my head to rewrite in Objective-C on Sunday, but from my superficial understanding of it the Objective-C version wouldn’t be really ugly. Yes, it would be wordier and clumsier, but tolerably so (for me). After all, it’s precisely these things where functional languages shine. I seldom find I have to monkey around with __block. Manual boxing/unboxing sucks, yes. It can be alleviated by a simple macro where this really matters, but I can see such and argument is like pouring petrol into the fire when compared to functional languages :) Now I understand what was meant by “sophisticated algorithms”. Yes, Objective-C is not perfect for those – first class collections are a great convenience here. But I certainly do not see that as a future “liability for Apple” or a huge drawback for the language ecosystem. It’s a niche.