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.
