On Wednesday, 20 December 2017 at 08:49:18 UTC, Shachar Shemesh
wrote:
On 19/12/17 11:54, Walter Bright wrote:
"C, Python, Go, and the Generalized Greenspun Law"
http://esr.ibiblio.org/?p=7804
I have two takeaways from that article:
1. ESR doesn't understand C++ one bit.
2. I feel exactly the same way about D.
I'll start with 1. I've been writing in C++ for a long time
now, and have *never* had to spend much time on double
frees/leaks. This is especially true since C++11, where the
built-in types are good enough for anything which doesn't
include graphs with cycles (and, yes, I would use a GC for
those).
RAII + reference counting where needed pretty much eliminated
those problems for me. ESR's lumping of C++ and C together, at
the very least, lacks an explanation of why C++'s additional
tools for handling this case are insufficient. A more likely
case is that ESR is simply ignorant of them and their impact
when used correctly.
The only times where I saw people mucking about with the
allocators is when the *performance* profile was deemed not
good enough. D's built-in facilities have nothing to offer on
that front: The main case against the GC is it's horrid (and,
worse, unexpected) performance.
I spend a lot of my time on D trying to work around the
limitations that the GC is imposing on me, to the point where I
feel like much we do here is to write our own infrastructure,
because we can't use the built-in one. To be clear, the problem
is a performance one here too, but the handling is completely
different.
In C++ it is possible to start with the built-in facilities and
then slowly work alternative ones as bottlenecks are analyzed.
No such path is possible in D. If you don't want to use the GC,
you will need to rework *everything*. Your entire code will
have to revolve around using non-GC facilities, most of which
you will have to write for yourself.
So, no, I'm not convinced.
Shachar
I agree with you regarding C++ when I program alone, it is
beautiful safe C++14 (now C++17) code.
However I completely disagree when I have to deal with the
typical enterprise C++ code, that most of the time looks like C
being compiled with a C++ compiler, from developers that learned
it before C++98 and can't care less what is being discussed on
Reddit and HN.
So I happily use Java and C# at work, only dealing with C++ for
low level OS integration stuff, because that C++ that I am going
to touch, written by such devs, will require gloves and tweezers.
--
Paulo
