A Few thoughts on C, C++, and D

[Moritz Maxeiner via Digitalmars-d]

On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
> A few thoughts not entirely random but without a well thought 
> out storyline, prompted by a couple of recent threads here.
>
> I like the comment from DConf that D should be the successor to 
> Vala for writing GObject-based code. We have GtkD and in it 
> GStreamer. Writing programs in C with them is a real pain in 
> the a### and using C++ is only a little bit better. Having a 
> number of exemplar applications showing how good D is for this 
> sort of application would be a big win. I have been steeling 
> myself to rewrite Me TV in D for two years, but there is always 
> another problem that means leaving it in C++ is easier.

Would writing a mixed C++/C app be viable in your case (provide 
core logic in D and interface with external stuff using C++, 
combine via C++ interop)?

>
> GObject code requires RAII and C does not provide it. And the 
> C++ wrappers do a poor job because of all the dynamic runtime 
> behaviour the C++ wrapper model badly. D should be able to 
> cover this ground easily.

Well, yeah, C has no builtin concept of objects (you can hack it 
in, of course) and without object lifetimes, no RAII.

>
> My biggest problem of the moment is libdvbv5 and librtlsdr. 
> DStep seemingly cannot help as yet, and wrapping manually is a 
> pain, and there is no GIR files for these. Thus D is a non 
> starter whereas C++ can just use the C header files.  This 
> inability to get past the inertia is a huge barrier. Seriously, 
> I end up with C++ because the manual wrapping hill is too steep.

Doing this manually sucks, yeah, but I wouldn't say it's too 
steep in general.
As an experiment I ported an old application from python to both 
C++14 (with all the new shiny things), as well as D. In C++14 it 
took me about a week to get everything right. In D two days. And 
that included writing bindings for C API things.

>
> And… if the application is written in C++ or C there might be 
> others willing to join in. As soon as the application is 
> written in D, there appears to be no audience of people willing 
> to get stuck in to help evolve the application. So here is the 
> real barrier: writing GtkD/GStreamerD applications is less 
> attractive because everyone in the universe expects such 
> applications to be written in C or C++.

Yeah, that is a problem with D not having a large community. But 
personally, I much prefer an understandable, easily maintainable 
code base in D over whatever Lovecraftian nightmare you end up 
with C or C++. Even at the cost of low external input.

>
> Each person trying to reach over the barrier tends to be an 
> island to themselves as no-one else seems to give a #### about 
> the problem that person is interested in.  The isolation of the 
> people trying to get D some traction is arguably the biggest 
> barrier to traction for D. It's the "no-one does it because 
> no-one does it" problem.
>
> If everyone in the D community got interested in and just 
> supplied moral support and advice for everyone else, even 
> though the application was uninteresting, there might be the 
> possibility of serious traction. Which then becomes a 
> self-fulfilling prophesy.

And both of these paragraphs are why I fairly regularly check 
digitalmars.d.learn to see if someone needs help I think I can 
provide.