4 ms·

What's hilarious about this myth is that I learned to program in NeXTStep using Objective-C well over a decade ago and am enjoying writing iPhone apps. But I h

by akadien 17y ago

What's hilarious about this myth is that I learned to program in NeXTStep using Objective-C well over a decade ago and am enjoying writing iPhone apps. But I hear younger programmers bitch about how hard it is to write code in Objective-C, manage memory, etc.

jrockway 17y ago
But I hear younger programmers bitch about how hard it is to write code in manage memory, etc. That's because we like to create applications, not program computers. Memory management is programming for the sake of programming, it doesn't do anything user-visible. The computer can do it automatically, so why pass it off to the human? (Also, C does have automatic memory management. Ever "free" anything you allocate on the stack? I thought not.)
- akadien 17y ago
  Uh, Q.E.D.?
  - jrockway 17y ago
    "Old people like unnecessarily performing the same exact task a number of times, and enjoy spending time with obscure debugging tools when they forget to do it right in one place?" OK, sure, I agree.
    - rajeshamara 17y ago
      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.)
- swernli 17y ago
  There are a lot of things that you depend on that aren't "user-visible" and require what you call "programming for the sake of programming." In fact, I'd go so far as to say it's good that some of us love that stuff, otherwise there would be no one to write and/or fix the fancy language features, libraries, and embedded systems young whippersnappers like you depend on. By the way, I'm actually fairly young myself (23), but I've always loved the down and dirty, close-to-the-metal details of programming. And I also have the soul of a 50 year old (a la: "I need a lawn so I can yell at kids to stay off it." http://xkcd.com/479/ http://xkcd.com/479/).
alexgartrell 17y ago
I can't help but wonder who these "younger programmers" that don't know memory management are. To graduate from my school, you must know it very well. In fact, a CS major can't graduate without passing a class that requires you to write a malloc implementation yourself. A good amount of CS majors go on to take Operating Systems, whose core project (writing a kernel from scratch) requires that you interface with the virtual memory capabilities of the x86 processor (involving frame allocations, setting up the page table, etc.) Maybe the ageism thing is more of a lack of understanding on both sides than a directed bias against only the older people? I'm not trying to say that young people won't end up being better programmers in 10 to 20 years; if that weren't the case, there'd be no point in pursuing it as a career. However, to assume that comparative ignorance at 20 is the same thing as global ignorance is unfair.
- thomaspaine 17y ago
  Not every programmer majored in CS. In fact, these days unless you majored in CS or EE, you probably won't get any exposure to lower level programming unless you learn it on your own. For people who get into programming via other domains (math, stats, design, etc) there's generally just not a very compelling reason to learn these things because you're going to be doing 99% of your programming in a higher level language like Matlab, SPSS, Python, etc, where memory management is largely abstracted away.
  - alexgartrell 17y ago
    My argument isn't for the relevance of memory management or that everyone is aware of it, just that a lot of junior people are aware of it, so it's unfair to characterize them all as "bitching" about the hard stuff.
- pashields 17y ago
  I don't know what makes you think that all CS programs are like this. My operating systems course did not require me to write a kernel. In fact, there was only one class that required you to work in a language that required manual memory management (using c++). Granted, my department, at least at the time, had a relatively strong functional bent: before you graduated, you would have worked in scheme and haskell. Most people ended up taking other classes that forced them to use C or more c++, but wasn't required. I'm a vassar college alum, for the record.
elai 17y ago
I'm a young guy and I find iPhone memory management is very easy. The built in reference counting system with objects makes it fairly nice to work with vs. some ad-hoc system dealing with malloc'ed memory here and there. You might get a memory error here and there, but usually it means your design was sloppy somewhere [usually involving arrays, the bad part of objective-c design] and would probably eat up memory in a garbage collected system anyway.

by akadien 17y ago

jrockway 17y ago

But I hear younger programmers bitch about how hard it is to write code in manage memory, etc. That's because we like to create applications, not program computers. Memory management is programming for the sake of programming, it doesn't do anything user-visible. The computer can do it automatically, so why pass it off to the human? (Also, C does have automatic memory management. Ever "free" anything you allocate on the stack? I thought not.)

akadien 17y ago
Uh, Q.E.D.?
- jrockway 17y ago
  "Old people like unnecessarily performing the same exact task a number of times, and enjoy spending time with obscure debugging tools when they forget to do it right in one place?" OK, sure, I agree.
  - rajeshamara 17y ago
    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.)
swernli 17y ago
There are a lot of things that you depend on that aren't "user-visible" and require what you call "programming for the sake of programming." In fact, I'd go so far as to say it's good that some of us love that stuff, otherwise there would be no one to write and/or fix the fancy language features, libraries, and embedded systems young whippersnappers like you depend on. By the way, I'm actually fairly young myself (23), but I've always loved the down and dirty, close-to-the-metal details of programming. And I also have the soul of a 50 year old (a la: "I need a lawn so I can yell at kids to stay off it." http://xkcd.com/479/ http://xkcd.com/479/).

alexgartrell 17y ago

I can't help but wonder who these "younger programmers" that don't know memory management are. To graduate from my school, you must know it very well. In fact, a CS major can't graduate without passing a class that requires you to write a malloc implementation yourself. A good amount of CS majors go on to take Operating Systems, whose core project (writing a kernel from scratch) requires that you interface with the virtual memory capabilities of the x86 processor (involving frame allocations, setting up the page table, etc.) Maybe the ageism thing is more of a lack of understanding on both sides than a directed bias against only the older people? I'm not trying to say that young people won't end up being better programmers in 10 to 20 years; if that weren't the case, there'd be no point in pursuing it as a career. However, to assume that comparative ignorance at 20 is the same thing as global ignorance is unfair.

thomaspaine 17y ago
Not every programmer majored in CS. In fact, these days unless you majored in CS or EE, you probably won't get any exposure to lower level programming unless you learn it on your own. For people who get into programming via other domains (math, stats, design, etc) there's generally just not a very compelling reason to learn these things because you're going to be doing 99% of your programming in a higher level language like Matlab, SPSS, Python, etc, where memory management is largely abstracted away.
- alexgartrell 17y ago
  My argument isn't for the relevance of memory management or that everyone is aware of it, just that a lot of junior people are aware of it, so it's unfair to characterize them all as "bitching" about the hard stuff.
pashields 17y ago
I don't know what makes you think that all CS programs are like this. My operating systems course did not require me to write a kernel. In fact, there was only one class that required you to work in a language that required manual memory management (using c++). Granted, my department, at least at the time, had a relatively strong functional bent: before you graduated, you would have worked in scheme and haskell. Most people ended up taking other classes that forced them to use C or more c++, but wasn't required. I'm a vassar college alum, for the record.

elai 17y ago

I'm a young guy and I find iPhone memory management is very easy. The built in reference counting system with objects makes it fairly nice to work with vs. some ad-hoc system dealing with malloc'ed memory here and there. You might get a memory error here and there, but usually it means your design was sloppy somewhere [usually involving arrays, the bad part of objective-c design] and would probably eat up memory in a garbage collected system anyway.