4 ms·

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

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
So, I guess what you're saying (correct me if I'm wrong) is that even though memory management (and register allocation, and other things) can be classified as "incidental", this is a dangerous label, because people are prone to then think "and therefore I can outsource these problems to a GC/compiler/whatever and not need to think or worry about them anymore" and then wonder why performance is so bad. If that's your point then I agree, but I still think it's worth at least making a vague mental note that the problem is still incidental (and then carefully avoid the above conclusion).
- mattnewport 8y ago
  Not the OP but I think you're still missing his point. The argument is that it is fundamentally wrong headed to argue that the process of realizing software on actual hardware is incidental or not part of the actual problem in the same way that it would be wrong to argue that the laws of physics are not part of the actual problem for engineering. If you're building a road bridge you could say that the actual problem is getting vehicles from one side of the river to the other and not the engineering details required to realize a physical structure capable of doing that. Things like the tensile strength of steel would be no more important to the bridge builders than mere memory allocation is to the average programmer in a GC'd language. You could also argue that taking that approach would lead to bridges that fail as badly at their primary function as much modern software does.
  - keldaris 8y ago
    That's exactly right, thank you. It's a fundamentally simple point often made by embedded and game programmers (perhaps most famously in recent years in Mike Acton's keynote at CppCon [1]), but most programmers seem to have completely written off most of what computer programming actually is as "incidental". [1] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
    - marvy 8y ago
      Hmm... maybe I better watch this talk at some point and try to get this through my head better... When I saw the bridge example my reaction was basically "why would that result in bad bridges?" I feel slightly attacked when you say "written off". I don't mean to "write off" memory management as something undeserving of attention. I think that if performance matters at all, then even if you program in a GC'd language you better know roughly how your GC works and what it's good and bad at, and preferably have a plan for switching to a different GC if need be. More generally, "incidental" stuff deserves attention. It may very well deserve the MAJORITY of your attention. I don't want to "write it off". I just want to classify it properly. Am I increasing my own risk of creating bad software by thinking this way?
      - 8y ago

marvy 8y ago

So, I guess what you're saying (correct me if I'm wrong) is that even though memory management (and register allocation, and other things) can be classified as "incidental", this is a dangerous label, because people are prone to then think "and therefore I can outsource these problems to a GC/compiler/whatever and not need to think or worry about them anymore" and then wonder why performance is so bad. If that's your point then I agree, but I still think it's worth at least making a vague mental note that the problem is still incidental (and then carefully avoid the above conclusion).

mattnewport 8y ago
Not the OP but I think you're still missing his point. The argument is that it is fundamentally wrong headed to argue that the process of realizing software on actual hardware is incidental or not part of the actual problem in the same way that it would be wrong to argue that the laws of physics are not part of the actual problem for engineering. If you're building a road bridge you could say that the actual problem is getting vehicles from one side of the river to the other and not the engineering details required to realize a physical structure capable of doing that. Things like the tensile strength of steel would be no more important to the bridge builders than mere memory allocation is to the average programmer in a GC'd language. You could also argue that taking that approach would lead to bridges that fail as badly at their primary function as much modern software does.
- keldaris 8y ago
  That's exactly right, thank you. It's a fundamentally simple point often made by embedded and game programmers (perhaps most famously in recent years in Mike Acton's keynote at CppCon [1]), but most programmers seem to have completely written off most of what computer programming actually is as "incidental". [1] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
  - marvy 8y ago
    Hmm... maybe I better watch this talk at some point and try to get this through my head better... When I saw the bridge example my reaction was basically "why would that result in bad bridges?" I feel slightly attacked when you say "written off". I don't mean to "write off" memory management as something undeserving of attention. I think that if performance matters at all, then even if you program in a GC'd language you better know roughly how your GC works and what it's good and bad at, and preferably have a plan for switching to a different GC if need be. More generally, "incidental" stuff deserves attention. It may very well deserve the MAJORITY of your attention. I don't want to "write it off". I just want to classify it properly. Am I increasing my own risk of creating bad software by thinking this way?
    - 8y ago