Seems to me there is a really, really good article for CVu or Overload in all this, starting with reprinting the ESR article, follwed up by some experience history article like this.
On Tue, 2017-12-19 at 11:42 -0800, H. S. Teoh via Digitalmars-d wrote: > On Tue, Dec 19, 2017 at 01:54:05AM -0800, Walter Bright via > Digitalmars-d wrote: > > "C, Python, Go, and the Generalized Greenspun Law" > > > > http://esr.ibiblio.org/?p=7804 > > Coming from a strong C/C++ background, it took me a good long while > to > accept the GC. I had all the usual objections about lack of control > (e.g. over GC pauses), lack of determinism (never know when something > will get collected), performance, etc.. But there's one thing the GC > gives that no amount of clever programming can: productivity. > > It's exactly as ESR says: once your code gets to a certain point of > complexity, in a manual memory management language like C/C++ your > coding time becomes more and more disproportionately spent on > managing > memory rather than working on your problem domain. That is, if you > wish > to preserve code correctness. It *is* possible to be productive past > this point, but memory-related bugs become more frequent and > eventually > overwhelms your effort to make progress in the problem domain. > > After I started writing non-trivial code in D, I found my brain has > been > freed up from the constant energy drain of having to think about > managing memory -- is that pointer still in scope, do I have to free > it, > have I freed it already, are the parameters borrowed references or > transfer of ownership, should they be borrowed references instead, > should I use a refcounting wrapper instead, what happens to this > template if a refcounted type was passed in instead of something > else, > what happens to the reference if an exception is thrown here, ad > nauseam > -- now I can actually think about the algorithm as it directly > pertains > to the problem domain, rather than constantly fiddling with the dirty > details of memory management. > > As a result, not only my productivity skyrocketed, but the > correctness > of my algorithms improved. When you're constantly under the nagging > of > manual memory management gotchas, you may well churn out > *memory-correct* code, but not necessarily code that's correct *in > the > problem domain*. Being freed from the fidgety concerns of memory > management means more mental resources can be directed at actually > solving the problem at hand and doing a better job at it. Not to > mention an entire class of memory-related bugs are eliminated by the > GC. > > That's why nowadays my opinion is that if you're not working with > performance-sensitive code (i.e., where every missed CPU cycle > increases > the likelihood of a patient dying or the airplane crashing), and if > you > haven't profiled your code to clearly show that the GC is a > performance > bottleneck, then you really should just let the GC do its job. There > *have* been cases where I've found that GC performance is hindering > my > code; so far, judicious, strategic use of GC.disable() and manual > calls > to GC.collect() have sufficed to fix that, without needing to throw > out > the GC baby with the bathwater altogether. Having to go back to > paying > the mental memory management tax on every other line of code I write > is > just not a wise use of my time and energy. > > > T > -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part