7 ms·

Even though many of the technical points are highly debatable, my biggest issue is with the sentence "the programmer is freed to work on the actual problem" lis

Even though many of the technical points are highly debatable, my biggest issue is with the sentence "the programmer is freed to work on the actual problem" listed among the "advantages" of automatic memory management, and with how ubiquitous that mindset has become. Insofar as computer programming is concerned, the "actual problem" is always the transformation of specific data on a specific set of computing hardware. Automating memory management doesn't imply working on the actual problem, it's just outsourcing a part of the actual problem in the pursuit of other objectives - decreasing development time, reducing the likelihood of specific bugs, etc. I'm not arguing that people shouldn't use automatic memory management, it often makes perfectly good technical and business sense to do so - but pretending that memory management is not a crucial part of solving any real problem in computer programming (even if you're not doing it explicitly) does no good to anyone.

marvy 8y ago
I think maybe your definition of "actual problem" is not the same as their definition. Let me try to defend their definition with an analogy. If I write in C, I don't have to worry about register allocation (which variable goes in which register, when should I spill to the stack, etc.). I can just write things like (a+b+c)/3 and it "just works". Perhaps the compiler will do a bad job with allocating the registers, and a good assembly programmer would have done far better, even to the extent that the program goes from "way too slow" to "plenty fast". (Unlikely these days, but in the past knowing when to use the "register" keyword was worth knowing.) But even then register allocation is incidental complexity, in that they are an artifact of the solution, not of the problem itself. But even though C programmers don't have to worry which registers are callee-save vs caller-save every time they call of function, they do have to worry about who is supposed to free every allocated data structure. Java programmers don't; they can just write ("1+2="+3).getBytes() and it "just works". The garbage collector may be so inefficient that you wish it weren't there, but even then, deciding exactly when to deallocate every temporary string is incidental complexity, in that they are an artifact of the solution, not of the problem itself. Of course, just because the problem is incidental doesn't mean it need not be solved! You really do need to free those strings or else you'll run out of memory and crash. (but not too soon, or else you have a use-after-free problem.) And likewise, at the end of the day, the values better end up in the right registers. But whether you're writing a game or web app or an FPGA simulator, memory management is not the "actual problem" you care about solving. The proof is that you don't think about when you're writing the user guide to your software.
- mattnewport 8y ago
  I don't think register allocation is a great analogy since it is largely a "solved problem" - there are well known techniques that allow compilers to do as good or better job of it than a programmer in most situations. This is not yet true for memory management. You give "writing a game" as an example where memory management is not the actual problem. Games however often care a lot about performance and achieving good performance is part of the actual problem you're solving. For many games projects on current hardware you won't be able to solve the performance problem without thinking about memory allocation and blindly relying on the garbage collector will result in a game that doesn't solve the actual problem of performing adequately on the target hardware.
  - marvy 8y ago
    Sure, register allocation is mostly solved and memory management is far from solved; thus memory management gets far more of the game programmer's attention (or else your game will play at two frames per second, plus occasional longer pauses). But the analogy is otherwise fine: reviews of your game will mention the performance (because it matters), but they will not mention your memory management strategy (because the don't care and may not even know). They will mention the rules, the mechanics, the story, the graphics and music and sound effects. Those are all part of the actual problem. Memory management is an implementation detail. Don't get me wrong: this implementation detail is so vital that it may very well make sense to structure the entire code base around it, but that doesn't mean it's part of the "actual" problem, at least if you use my definition. (See also my other reply in this thread.)
- keldaris 8y ago
  Well, that's exactly the point - I was arguing against the (by now ubiquitous) definition of the "actual problem". Your analogy further illustrates exactly that. The actual problem (as in, the thing you are actually solving whether you realize it or not) of computer programming is not creating a product (that's business) or even data transformation (that's applied math). All computer programming is ultimately the transformation of data on real hardware (however abstracted by everything from firmware to virtual machines). Obviously, computer programmers don't exist in a vacuum and have to take into account technical (including mathematical) and social (including business) concerns, make tradeoffs, etc., but that doesn't change the basic facts. I'm just arguing we should be more explicit about them, not write them off. And to address your analogy directly, register allocation is as much part of the actual problem as memory management. Even though most of us rarely resort to actually doing it by hand, it's still there and examining it in the resulting assembly is still often an important part of optimizing code. My argument is that regardless of whether you directly encounter something like register allocation every day, it is both conceptually important and useful to recognize it as part of what computer programming actually is, the technical and social properties that lead to the degree to which it is automated and the associated tradeoffs. Pretending that the actual problem of getting computers to do what we want is some annoying series of "incidental" problems is a recipe for bad software.

marvy 8y ago

I think maybe your definition of "actual problem" is not the same as their definition. Let me try to defend their definition with an analogy. If I write in C, I don't have to worry about register allocation (which variable goes in which register, when should I spill to the stack, etc.). I can just write things like (a+b+c)/3 and it "just works". Perhaps the compiler will do a bad job with allocating the registers, and a good assembly programmer would have done far better, even to the extent that the program goes from "way too slow" to "plenty fast". (Unlikely these days, but in the past knowing when to use the "register" keyword was worth knowing.) But even then register allocation is incidental complexity, in that they are an artifact of the solution, not of the problem itself. But even though C programmers don't have to worry which registers are callee-save vs caller-save every time they call of function, they do have to worry about who is supposed to free every allocated data structure. Java programmers don't; they can just write ("1+2="+3).getBytes() and it "just works". The garbage collector may be so inefficient that you wish it weren't there, but even then, deciding exactly when to deallocate every temporary string is incidental complexity, in that they are an artifact of the solution, not of the problem itself. Of course, just because the problem is incidental doesn't mean it need not be solved! You really do need to free those strings or else you'll run out of memory and crash. (but not too soon, or else you have a use-after-free problem.) And likewise, at the end of the day, the values better end up in the right registers. But whether you're writing a game or web app or an FPGA simulator, memory management is not the "actual problem" you care about solving. The proof is that you don't think about when you're writing the user guide to your software.

mattnewport 8y ago
I don't think register allocation is a great analogy since it is largely a "solved problem" - there are well known techniques that allow compilers to do as good or better job of it than a programmer in most situations. This is not yet true for memory management. You give "writing a game" as an example where memory management is not the actual problem. Games however often care a lot about performance and achieving good performance is part of the actual problem you're solving. For many games projects on current hardware you won't be able to solve the performance problem without thinking about memory allocation and blindly relying on the garbage collector will result in a game that doesn't solve the actual problem of performing adequately on the target hardware.
- marvy 8y ago
  Sure, register allocation is mostly solved and memory management is far from solved; thus memory management gets far more of the game programmer's attention (or else your game will play at two frames per second, plus occasional longer pauses). But the analogy is otherwise fine: reviews of your game will mention the performance (because it matters), but they will not mention your memory management strategy (because the don't care and may not even know). They will mention the rules, the mechanics, the story, the graphics and music and sound effects. Those are all part of the actual problem. Memory management is an implementation detail. Don't get me wrong: this implementation detail is so vital that it may very well make sense to structure the entire code base around it, but that doesn't mean it's part of the "actual" problem, at least if you use my definition. (See also my other reply in this thread.)
keldaris 8y ago
Well, that's exactly the point - I was arguing against the (by now ubiquitous) definition of the "actual problem". Your analogy further illustrates exactly that. The actual problem (as in, the thing you are actually solving whether you realize it or not) of computer programming is not creating a product (that's business) or even data transformation (that's applied math). All computer programming is ultimately the transformation of data on real hardware (however abstracted by everything from firmware to virtual machines). Obviously, computer programmers don't exist in a vacuum and have to take into account technical (including mathematical) and social (including business) concerns, make tradeoffs, etc., but that doesn't change the basic facts. I'm just arguing we should be more explicit about them, not write them off. And to address your analogy directly, register allocation is as much part of the actual problem as memory management. Even though most of us rarely resort to actually doing it by hand, it's still there and examining it in the resulting assembly is still often an important part of optimizing code. My argument is that regardless of whether you directly encounter something like register allocation every day, it is both conceptually important and useful to recognize it as part of what computer programming actually is, the technical and social properties that lead to the degree to which it is automated and the associated tradeoffs. Pretending that the actual problem of getting computers to do what we want is some annoying series of "incidental" problems is a recipe for bad software.