www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A Few thoughts on C, C++, and D

reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.

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.

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.

And=E2=80=A6 if the application is written in C++ or C there might be other=
s
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++.

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.

In the mean time the Rust community are trying all of this sort of
marketing to try and prove to themselves they are actually relevant and
not a small clique. OK so they have some financial support, but maybe
that can be got round in the D community.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 29
next sibling parent reply aberba <karabutaworld gmail.com> writes:
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.

 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.

 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.

 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++.

 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.

 In the mean time the Rust community are trying all of this sort 
 of marketing to try and prove to themselves they are actually 
 relevant and not a small clique. OK so they have some financial 
 support, but maybe that can be got round in the D community.
IMO, the most important thing is getting the job done. I don't want to write my own pdf generator, my own web socket lib, json lib,... I just want to get my job done... Some languages are not fast, nor offer control nor safe, ... they get jobs done for (most) people. Plus their docs are good for figuring things out for (most) people. Majority of developers are probably web developers or library-consumers using other more technical devs work. Chasing after companies doesn't help. Its better to capitalise on D's productivity and make it easy to get things done (as a community). It's individuals that come together to form companies that end up being aquired by bigger corps or distrubt the industry.
May 29
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
 IMO,  the most important thing is getting the job done.
* getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously.
May 29
next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote:
 On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
 IMO,  the most important thing is getting the job done.
* getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously.
At least as important as getting the job done, is doing jobs. As much fun as it is to debate and discuss what could or needs to be done to attract one group of developers or another, actually using and releasing systems built with D are going to contribute to accumulating to the total mass of code. Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem.
May 29
parent reply bachmeier <no spam.net> writes:
On Monday, 29 May 2017 at 20:58:54 UTC, Brad Roberts wrote:

 Each time someone wraps a new library, each time someone fixes 
 some bug because it affects them, etc.. these all push things 
 forward inch by inch.

 Eventually that mass might actually reach critical.   But even 
 if it doesn't, things continue to get incrementally easier for 
 those that already use D and it's ecosystem.
Incremental is key. It's what enabled me to use D for my work. Apologies to anyone that feels only enterprise code bases with at least 10 million lines of code are worth talking about, but good luck convincing anyone to rewrite a code base that critical and that big. At the end of the day I'm the one writing D code for a living and the enterprise developers are stuck writing C++ and Java.
May 29
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 29 May 2017 at 21:43:30 UTC, bachmeier wrote:
 Incremental is key. It's what enabled me to use D for my work. 
 Apologies to anyone that feels only enterprise code bases with 
 at least 10 million lines of code are worth talking about, but 
 good luck convincing anyone to rewrite a code base that 
 critical and that big.
I don't think Russel Winder was talking about enterprise code, but for a language to take hold you need at least one significant publicly visible application written in it. E.g. Go has Docker, Rust has a Firefox engine, and so on... It is taken as a sign of maturity.
May 29
parent reply bachmeier <no spam.net> writes:
On Monday, 29 May 2017 at 22:20:34 UTC, Ola Fosheim Grøstad wrote:

 I don't think Russel Winder was talking about enterprise code, 
 but for a language to take hold you need at least one 
 significant publicly visible application written in it.

 E.g. Go has Docker, Rust has a Firefox engine,  and so on... It 
 is taken as a sign of maturity.
I'm not necessarily disagreeing with RW's post. My reading is that the goal would be to get D into the enterprise, but maybe I misinterpreted. If D as a successor to Vala leads to more projects like Tilix, that's great. However, an easier way to accomplish the same thing would be wrapping more C libraries, writing better documentation for Dub, and so on. Incremental improvements lead to incremental adoption of D. I'll also note that Vala didn't catch on, so being the successor to Vala by itself may not help D adoption.
May 29
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 May 2017 at 01:46:02 UTC, bachmeier wrote:
 I'm not necessarily disagreeing with RW's post. My reading is 
 that the goal would be to get D into the enterprise, but maybe 
 I misinterpreted. If D as a successor to Vala leads to more 
 projects like Tilix, that's great.
I never quite understood the enterprise-focus either. What I like to see for a language is a difficult use scenario being maintainable. I sometimes browse large code bases just to see if a language leads to readable code.
 writing better documentation for Dub, and so on. Incremental 
 improvements lead to incremental adoption of D.
Yes, I think retention is the most important factor in the case of D. Identify and understand why polyglot programmers either stay with D or leave. Then give those areas the highest priority, especially exit-triggering issues. Focusing on getting many libraries won't work, because you need to maintain them. I never use unmaintained libraries... Having many unmaintained libraries is in a way worse than having a few long-running ones that improve at a steady pace.
 I'll also note that Vala didn't catch on, so being the 
 successor to Vala by itself may not help D adoption.
Being perceived as the best for something helps. Vala was the best for something narrow. I think Rust is being perceived as the best for runtime-less programming with high level features (right or wrong) and Go is perceived as having a runtime for web services. So I personally perceive Rust and Go in different sectors of the spectrum. I have more problems placing Nim, Haxe, D etc.
May 29
parent reply bachmeier <no spam.net> writes:
On Tuesday, 30 May 2017 at 05:50:13 UTC, Ola Fosheim Grostad 
wrote:

 Focusing on getting many libraries won't work, because you need 
 to maintain them. I never use unmaintained libraries... Having 
 many unmaintained libraries is in a way worse than having a few 
 long-running ones that improve at a steady pace.
One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point.
May 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
 One of the things I hated when I started using D was links to 
 dsource libraries. I think that writing new libraries in D is 
 often a mistake for that very reason. Bindings to C libraries 
 is what we need. Put everything into one D file if possible, 
 wrapping just the stable core functionality with a few 
 convenience features tossed in, and maintenance is no longer an 
 issue. There's nothing sexy abut that approach, and that's kind 
 of the point.
What happend to that Calypso project? I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought.
May 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 30 May 2017 at 12:26:22 UTC, Ola Fosheim Grøstad 
wrote:
 What happend to that Calypso project?  I suppose libclang also 
 would allow you to inspect C header-files and then maybe it 
 would be possible to synthesize Dish bindings from it on the 
 fly? Not that I have given it much thought.
Maybe even turning some macros into functions?
May 30
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:

 Maybe even turning some macros into functions?
DStep can do that today. -- /Jacob Carlborg
May 30
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
 On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:

 Maybe even turning some macros into functions?
DStep can do that today.
That's cool! How robust is in practice on typical header files (i.e zlib and similar)? What were the objections to integration with DMD?
May 30
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-30 17:15, Ola Fosheim Grostad wrote:

 That's cool!  How robust is in practice on typical header files (i.e
 zlib and similar)?
I would say ok. I did try to run DStep on zlib.h just now. It got quite confused when translating the comments. But disabling that it looked a lot better. For example, all #defines which are for constants are properly translated to enums (manifest constants). The following macros: #define deflateInit(strm, level) \ deflateInit_((strm), (level), ZLIB_VERSION, (int)sizeof(z_stream)) #define inflateInit(strm) \ inflateInit_((strm), ZLIB_VERSION, (int)sizeof(z_stream)) #define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \ deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\ (strategy), ZLIB_VERSION, (int)sizeof(z_stream)) #define inflateInit2(strm, windowBits) \ inflateInit2_((strm), (windowBits), ZLIB_VERSION, \ (int)sizeof(z_stream)) #define inflateBackInit(strm, windowBits, window) \ inflateBackInit_((strm), (windowBits), (window), \ ZLIB_VERSION, (int)sizeof(z_stream)) Are translate to: extern (D) auto deflateInit(T0, T1)(auto ref T0 strm, auto ref T1 level) { return deflateInit_(strm, level, ZLIB_VERSION, cast(int) z_stream.sizeof); } extern (D) auto inflateInit(T)(auto ref T strm) { return inflateInit_(strm, ZLIB_VERSION, cast(int) z_stream.sizeof); } extern (D) auto deflateInit2(T0, T1, T2, T3, T4, T5)(auto ref T0 strm, auto ref T1 level, auto ref T2 method, auto ref T3 windowBits, auto ref T4 memLevel, auto ref T5 strategy) { return deflateInit2_(strm, level, method, windowBits, memLevel, strategy, ZLIB_VERSION, cast(int) z_stream.sizeof); } extern (D) auto inflateInit2(T0, T1)(auto ref T0 strm, auto ref T1 windowBits) { return inflateInit2_(strm, windowBits, ZLIB_VERSION, cast(int) z_stream.sizeof); } extern (D) auto inflateBackInit(T0, T1, T2)(auto ref T0 strm, auto ref T1 windowBits, auto ref T2 window) { return inflateBackInit_(strm, windowBits, window, ZLIB_VERSION, cast(int) z_stream.sizeof); } Currently DStep cannot handle #if or #ifdef.
 What were the objections to integration with DMD?
I don't recall exactly, I recommend reading the post I linked to [1]. [1] http://forum.dlang.org/post/ks3kir$1ubq$1 digitalmars.com -- /Jacob Carlborg
May 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
 Currently DStep cannot handle #if or #ifdef.
Oh, that is often required…
 What were the objections to integration with DMD?
I don't recall exactly, I recommend reading the post I linked to [1].
My impression is that there is no consensus? So still a possibility then.
May 30
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-30 21:42, Ola Fosheim Grøstad wrote:
 On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
 Currently DStep cannot handle #if or #ifdef.
Oh, that is often required…
Yes, but it's very difficult to do. Say there's some code looking like this: #ifdef Windows #include <windows.h> DWORD foo(); #else int foo(); #endif Ideally that should be translated to: version (Windows) { import core.sys.windows.windows; DWORD foo(); } else { int foo(); } But trying to compile the code in the "body" for Windows, on any other platform will fail because windows.h is not available.
 My impression is that there is no consensus? So still a possibility then.
Good look convincing Walter that DMD should depend on DStep and LLVM. -- /Jacob Carlborg
May 30
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 31 May 2017 at 06:52:00 UTC, Jacob Carlborg wrote:
 Yes, but it's very difficult to do.

 Say there's some code looking like this:

 [snip]
Some simpler #ifdefs might be easier to handle and add a lot of value. Then you can make a list of stuff that is not supported, like #ifdefs with #includes.
May 31
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 31 May 2017 at 06:52:00 UTC, Jacob Carlborg wrote:
 But trying to compile the code in the "body" for Windows, on 
 any other platform will fail because windows.h is not available.
But you don't have to do that if it is built into the compiler?
May 31
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-31 17:50, Ola Fosheim Grøstad wrote:

 But you don't have to do that if it is built into the compiler?
Ah, you mean like that. No, that should be necessary if the bindings are always generated on the fly. My answer was assuming how DStep currently is working. -- /Jacob Carlborg
May 31
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 1 June 2017 at 06:43:44 UTC, Jacob Carlborg wrote:
 On 2017-05-31 17:50, Ola Fosheim Grøstad wrote:

 But you don't have to do that if it is built into the compiler?
Ah, you mean like that. No, that should be necessary if the bindings are always generated on the fly. My answer was assuming how DStep currently is working.
*nods* I think your idea of integrating with the compiler is a sound idea. Even though a stand-alone tool is just as good in theory I think most developers want as hassle free builds as possible. If one can just point to the OS include directory and import directly that would be very neat.
Jun 01
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-01 10:25, Ola Fosheim Grøstad wrote:

 Even though a stand-alone tool is just as good in theory I think most
 developers want as hassle free builds as possible. If one can just point
 to the OS include directory and import directly that would be very neat.
Currently DStep will just ignore everything in the body of a preprocessor if statement where the condition is false, just like the regular compiler. For example, running DStep on a header file with the following content: #ifdef _WIN32 char foo(); #else int foo(); #endif Will produce on non-Windows platforms: extern (C): int foo (); So DStep works, just that will generate platform specific bindings. -- /Jacob Carlborg
Jun 01
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 1 June 2017 at 12:04:40 UTC, Jacob Carlborg wrote:
 So DStep works, just that will generate platform specific 
 bindings.
That is good enough if it is integrated with the compiler then.
Jun 04
prev sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
 On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:

 Maybe even turning some macros into functions?
DStep can do that today.
How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D.
May 30
next sibling parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 30 May 2017 at 15:50:01 UTC, Swoorup Joshi wrote:
 On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
 On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:

 Maybe even turning some macros into functions?
DStep can do that today.
How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D.
Ha ha. I wonder what the decision makers think when all of us are like: "this is what D needs", "this hold me back", "kill GC", "I can't live without in-built RAII", ...
May 30
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-05-30 17:50, Swoorup Joshi wrote:

 How difficult is it to turn C++ headers usable for D?
Currently DStep doesn't support C++ headers at all. If think it's quite some work to support that. Of course it's possible to start simple, i.e. C++ free functions and continue from there. -- /Jacob Carlborg
May 30
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-05-30 14:26, Ola Fosheim Grøstad wrote:

 What happend to that Calypso project?  I suppose libclang also would
 allow you to inspect C header-files and then maybe it would be possible
 to synthesize Dish bindings from it on the fly? Not that I have given it
 much thought.
I did that by integrating DStep in DMD as a proof of concept [1]. But at that time, IIRC, it was preferred to run DStep as a separate step to generate the bindings. http://forum.dlang.org/post/ks3kir$1ubq$1 digitalmars.com -- /Jacob Carlborg
May 30
prev sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
 One of the things I hated when I started using D was links to 
 dsource libraries. I think that writing new libraries in D is 
 often a mistake for that very reason. Bindings to C libraries 
 is what we need. Put everything into one D file if possible, 
 wrapping just the stable core functionality with a few 
 convenience features tossed in, and maintenance is no longer an 
 issue. There's nothing sexy abut that approach, and that's kind 
 of the point.
I do not see anything massive wrong with that idea, beyond that your are open to libraries written in C. Potential unsafe memory function call inside the libraries...
May 30
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, May 29, 2017 13:58:54 Brad Roberts via Digitalmars-d wrote:
 On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote:
 On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
 IMO,  the most important thing is getting the job done.
* getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously.
At least as important as getting the job done, is doing jobs. As much fun as it is to debate and discuss what could or needs to be done to attract one group of developers or another, actually using and releasing systems built with D are going to contribute to accumulating to the total mass of code. Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem.
+1000 - Jonathan M Davis
May 30
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
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.
May 29
prev sibling next sibling parent Gerald <gerald.b.nunn gmail.com> writes:
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
 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.
I'm glad to see the message resonated with you, thanks for watching :)
 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.
I can understand this since if GtkD never existed I probably would have gone with Python or Vala, it would have been way too much work to bite off. Unfortunately at the end of the day someone has to step up and do the work and I suspect that gstreamer is a pretty niche area of interest.
 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++.
For Tilix the number of D contributions has been quite small, though I'm not convinced that it's because of D any more then it's because developers have little experience or interest in GTK and desktop applications. I think most of the C, C++ or Python based GTK open source projects also suffer from lack of contributors, it's always an issue in the open source world unless your project happens to be "hot" for some reason.
 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.
Again though isn't this common for most open source projects? I will say that I've always found the D community to be very welcoming and I've never considered myself isolated or an island. It's more just a case that I have an itch to write desktop applications and this gives me an opportunity to scratch it. Other folks may have different itches and not be interested in working on my project, GTK apps or other things and that's OK.
 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.
Not to be harsh, moral support isn't worth a hill of beans, give me people willing to work and get shit done. To me this is the biggest thing, it feels like there is a lack of applications written in D. However, maybe it's just me and I'm not looking in the right places. As a humorous and somewhat related item, there was a recent thread about Tilix in the reddit/ubuntu page with this witty comment: "Oh my god, a real D application" https://www.reddit.com/r/Ubuntu/comments/6ddf0t/tilix_is_a_stunning_tiling_terminal_emulator/
May 29
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:

 My biggest problem of the moment is libdvbv5 and librtlsdr. DStep
 seemingly cannot help as yet.
I know you have reported a few bugs for DStep. Are those all or anything else that has not been reported yet? -- /Jacob Carlborg
May 29
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-05-30 at 08:39 +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:
=20
 My biggest problem of the moment is libdvbv5 and librtlsdr. DStep
 seemingly cannot help as yet.
=20 I know you have reported a few bugs for DStep. Are those all or anything=C2=A0 else that has not been reported yet?
I am leading up to working more on this =E2=80=93 but I need a statically linked executable that will run on Debian Sid and Fedora Rawhide.=20 Looking at the problem of wrapping libdvbv5, what is in Deimos, etc., manually wrapping C libraries strikes me as a dead-end of dead-ends. As with GtkD and GStreamerD automated (or at least mostly automated) generation of wrappers is the only way forward. So if I cannot automatically generate libdvbv5 D wrappers, then I am not sure I can progress with D for Me TV. So DStep becomes a crucial factor. Except I cannot build it (as we discussed elsewhere, hence I need pre-built executables). Others have mentioned widening D's appeal by widening the number of C APIs there are wrappers for. This is a good idea, I agree =E2=80=93 in my c= ase libdvbv5 and librtlsdr are the beasties of interest. I argue Deimos is the wrong direction since it is about manually managing evolving API, DStep is the right direction since it is about creating the API of the moment. However DStep may not yet be ready. I need to tinker more. libdvbv5 effectively includes the whole Linux DVB API, there are a lot of C header files. It's alla question of how best to do the wrapping. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 30
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 30 May 2017 at 07:15:08 UTC, Russel Winder wrote:
 Others have mentioned widening D's appeal by widening the 
 number of C APIs there are wrappers for. This is a good idea, I 
 agree – in my case libdvbv5 and librtlsdr are the beasties of 
 interest. I argue Deimos is the wrong direction since it is 
 about manually managing evolving API, DStep is the right 
 direction since it is about creating the API of the moment. 
 However DStep may not yet be ready. I need to tinker more. 
 libdvbv5 effectively includes the whole Linux DVB API, there 
 are a lot of C header files. It's alla question of how best to 
 do the wrapping.
The problem is, that wrappers alone is not the solution. Lets say i write a wrapper, have no more time and abandon the project. Later people see these half finished and not maintain wrapper ( and others ). How does this reflect on the language itself. Its been my firm believe that lose packages are a detriment to a language. There is no controle over the quality of the work and yet the use of those third party packages can have a impact on the language perception ( unsupported, badly written, licencing issues ). Half baked solutions are no solutions. Packages need to be part of the language standard or "extended" library. Having the ownership under the language. Allowing people who are dissatisfied to grieve there bugs or issues, directly to the language maintainers. It also adds oversight to the packages. You mention Debian and look how they manage there packages. Code has issue: Rejected. Not maintained: Rejected. Licencing issues: Rejected. Simply trowing wrappers around C libraries does not make a language more interesting. Quality, standardization, one location, supported, ... those are the keywords. One can simply look at Go. 100.000 packages, 98% are junk, unfinished, not maintained, etc. And people are forced to dive into the junk to find the good ones. Its the same with other languages and there unenforced third party packages. This applies to enterprise users and normal users, everybody wants to have the quality and security that packages are maintained, have a standard, have the same API structure, ... But this requires a lot of coordination and manpower. Frankly, i do not see this happening any time soon in D ( and other languages ) that work with volunteers.
May 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 30 May 2017 at 07:56:43 UTC, Wulfklaue wrote:
 Its been my firm believe that lose packages are a detriment to 
 a language.
It isn't good if many of the interesting packages are unmaintained, as it gives an sense of being in the past.
 Half baked solutions are no solutions. Packages need to be part 
 of the language standard or "extended" library.
Standard libraries should stay small as they are hard to deprecate. Have official lists instead.
 One can simply look at Go. 100.000 packages, 98% are junk, 
 unfinished, not maintained, etc. And people are forced to dive 
 into the junk to find the good ones. Its the same with other 
 languages and there unenforced third party packages.
There is a solution for this: "awesome lists" https://github.com/avelino/awesome-go The problem for a small language is more when a very useful library become unmaintained, then people wonder why not somebody else took over.
May 30
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
And in good news, despite Dub's inability to understand the way things
are on Debian, and using some egregious hacks, I have a DStep build on
Debian Sid that appears to work. No such luck on Fedora but that is a
"known issue" for DStep (*).

It seems libdvbv5 D wrapper generation may be working. Me TV may yet
become a D code.

I shall also have to try librtlsdr.


(*) What DStep needs is some folk knowledgeable about libclang 3.9,
4.0, and 5.0 to help moving up from 3.7 (and 3.8).

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 30