4 ms·

Comments like this shows immaturity. Just because a platform manages memory management doesn't mean you can create 1 million objects. If you program in C++ or C

Comments like this shows immaturity. Just because a platform manages memory management doesn't mean you can create 1 million objects. If you program in C++ or C you appreciate these aspects which will help you write better code. Satellites designed in 1970's still going to the far edges of the solar system even though the processing power and memory is less than your cell phone. When you design your software without considering these aspect would be disaster. Example satellites designing now crashing on the orbits of other planets.

eru 17y ago
I agree. > Just because a platform manages memory management doesn't mean you can create 1 million objects. Yes, you still have to watch out. Only your example is not crass enough. A million objects does not have to be very much. And e.g. a Haskell program compiled with GHC can churn through a Gigabyte of memory in a second (see http://blog.interlinked.org/tutorials/haskell_laziness.html http://blog.interlinked.org/tutorials/haskell_laziness.html), and this isn't a bad thing. (As long as the memory is immediately reclaimed, and you do not actually use the whole Gigabyte at once.)
jrockway 17y ago
OK, but I feel like I'm not reading the same comments you (and the voters) are. Why is allocating your own memory in Objective-C "better" than letting, say, GHC, do it for you? I may be a young whippersnapper standing on your lawn, but my programs run as fast or faster and are more reliable. And it takes less time to write them.
- misterbwong 17y ago
  I'm a young whippersnapper standing on the lawn too, but there's something to be said about knowing the underlying workings of code before using it. Here's the disconnect I'm seeing: Allocating your own memory in Objective-C is not necessarily better. But all other things equal, a programmer that understands how GHC manages memory is better than one that does not. You're arguing the utility of this knowledge, as it pertains to your usual use case, is minimal. This is not the same as saying that the utility of this knowledge is minimal.
  - jrockway 17y ago
    But all other things equal, a programmer that understands how GHC manages memory is better than one that does not. Sure, but I never said this. The original post, now many levels up, said "kids bitch about how hard it is to manage memory". It is hard. That's why people bitch about it, and don't want to do it. I say that it's conceptually very simple. But in practice, it's very difficult to type the code to do this yourself at the right place. (It doesn't sound difficult, but most C programs either leak memory or use memory they didn't allocate, so clearly it is difficult.) There is a reason why C++ has things like the boost pointer library (and even auto_ptr). It's because memory management is for computers to do, not for humans to do. I think people have trouble realizing that a human can know both "high-level" and "low-level" things, but that a programmer needs to stick to one level or the other -- don't write low-level concepts (memory allocators) in your high-level application program. The same person can write both parts, but the programmer writing the high-level app shouldn't be worried about the low-level details ("of course it works"). When you mix the levels of abstraction, you write bad code. (I wrote a toy language once. I found that writing a garbage collector was much easier to get right than manually managing my own memory. When writing the collector, the details of memory allocation was all I needed to think about. When writing the high-level application code on top, all I had to think about was my high-level application. That's the whole point of abstraction, and it's what C-level languages fail to provide.)
- Flow 17y ago
  I don't think people are arguing against GC being good. It's just that Objective-C did not have GC until very recently and that's they way it is. Having used lots of languages and frameworks I think that Cocoa/UIKit is very elegant despite the manual memory management. It might even be true that most of the big Cocoa applications will continue to use manual memory management.

eru 17y ago

I agree. > Just because a platform manages memory management doesn't mean you can create 1 million objects. Yes, you still have to watch out. Only your example is not crass enough. A million objects does not have to be very much. And e.g. a Haskell program compiled with GHC can churn through a Gigabyte of memory in a second (see http://blog.interlinked.org/tutorials/haskell_laziness.html http://blog.interlinked.org/tutorials/haskell_laziness.html), and this isn't a bad thing. (As long as the memory is immediately reclaimed, and you do not actually use the whole Gigabyte at once.)

jrockway 17y ago

OK, but I feel like I'm not reading the same comments you (and the voters) are. Why is allocating your own memory in Objective-C "better" than letting, say, GHC, do it for you? I may be a young whippersnapper standing on your lawn, but my programs run as fast or faster and are more reliable. And it takes less time to write them.

misterbwong 17y ago
I'm a young whippersnapper standing on the lawn too, but there's something to be said about knowing the underlying workings of code before using it. Here's the disconnect I'm seeing: Allocating your own memory in Objective-C is not necessarily better. But all other things equal, a programmer that understands how GHC manages memory is better than one that does not. You're arguing the utility of this knowledge, as it pertains to your usual use case, is minimal. This is not the same as saying that the utility of this knowledge is minimal.
- jrockway 17y ago
  But all other things equal, a programmer that understands how GHC manages memory is better than one that does not. Sure, but I never said this. The original post, now many levels up, said "kids bitch about how hard it is to manage memory". It is hard. That's why people bitch about it, and don't want to do it. I say that it's conceptually very simple. But in practice, it's very difficult to type the code to do this yourself at the right place. (It doesn't sound difficult, but most C programs either leak memory or use memory they didn't allocate, so clearly it is difficult.) There is a reason why C++ has things like the boost pointer library (and even auto_ptr). It's because memory management is for computers to do, not for humans to do. I think people have trouble realizing that a human can know both "high-level" and "low-level" things, but that a programmer needs to stick to one level or the other -- don't write low-level concepts (memory allocators) in your high-level application program. The same person can write both parts, but the programmer writing the high-level app shouldn't be worried about the low-level details ("of course it works"). When you mix the levels of abstraction, you write bad code. (I wrote a toy language once. I found that writing a garbage collector was much easier to get right than manually managing my own memory. When writing the collector, the details of memory allocation was all I needed to think about. When writing the high-level application code on top, all I had to think about was my high-level application. That's the whole point of abstraction, and it's what C-level languages fail to provide.)
Flow 17y ago
I don't think people are arguing against GC being good. It's just that Objective-C did not have GC until very recently and that's they way it is. Having used lots of languages and frameworks I think that Cocoa/UIKit is very elegant despite the manual memory management. It might even be true that most of the big Cocoa applications will continue to use manual memory management.