4 ms·

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 w

by 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?

keldaris 8y ago
Well, there are two at least partly orthogonal points here - the teleological discussion over what computer programming actually is and the practical point regarding which mindset is more likely to lead to better software. I don't know that I can express my position on the former issue better than I already have in the form of a short comment suitable for this format (though I do recommend the talk I linked), so I'll leave that aside for now. On the latter point, however - and to answer your question regarding bad software - all other factors being equal, I think the answer is "probably, yes". The fundamental reason is that someone who is used to regarding memory management (which is really just one example among many) as incidental complexity to be outsourced away by default is less likely to reason carefully and intelligently about the actual implications of that decision. Just to pick a trivial example, someone who has internalized the RAII pattern in C++ without really understanding its implications may find it difficult to solve (or even find) memory fragmentation issues leading to bad performance - not something easily found in current profilers if you don't know what you're looking for already. There's a lot of issues like that which may seem either obvious or subtle depending on whether your mindset is to properly understand how the solution you've chosen actually works or regard it as incidental until proven otherwise. In the modern computer programming industry you can go a long way without really dealing with any of the issues I've mentioned. However, the fact that much of modern software is unbelievably bloated and slow for no good technical reason is indicative that perhaps it would be better if more programmers took direct responsibility not just for the code they actually write, but for the code they outsource to others, often without truly grappling with the implications of those decisions.
- marvy 8y ago
  > perhaps it would be better if more programmers took direct responsibility not just for the code they actually write, but for the code they outsource to others, often without truly grappling with the implications of those decisions. Now THERE I agree completely! (Will watch the talk next weekend I hope.)

by marvy 8y ago

keldaris 8y ago

Well, there are two at least partly orthogonal points here - the teleological discussion over what computer programming actually is and the practical point regarding which mindset is more likely to lead to better software. I don't know that I can express my position on the former issue better than I already have in the form of a short comment suitable for this format (though I do recommend the talk I linked), so I'll leave that aside for now. On the latter point, however - and to answer your question regarding bad software - all other factors being equal, I think the answer is "probably, yes". The fundamental reason is that someone who is used to regarding memory management (which is really just one example among many) as incidental complexity to be outsourced away by default is less likely to reason carefully and intelligently about the actual implications of that decision. Just to pick a trivial example, someone who has internalized the RAII pattern in C++ without really understanding its implications may find it difficult to solve (or even find) memory fragmentation issues leading to bad performance - not something easily found in current profilers if you don't know what you're looking for already. There's a lot of issues like that which may seem either obvious or subtle depending on whether your mindset is to properly understand how the solution you've chosen actually works or regard it as incidental until proven otherwise. In the modern computer programming industry you can go a long way without really dealing with any of the issues I've mentioned. However, the fact that much of modern software is unbelievably bloated and slow for no good technical reason is indicative that perhaps it would be better if more programmers took direct responsibility not just for the code they actually write, but for the code they outsource to others, often without truly grappling with the implications of those decisions.

marvy 8y ago
> perhaps it would be better if more programmers took direct responsibility not just for the code they actually write, but for the code they outsource to others, often without truly grappling with the implications of those decisions. Now THERE I agree completely! (Will watch the talk next weekend I hope.)