Maybe D is right about GC after all !

[Russel Winder]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20171220/8c8edfd0/attachment.sig>