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.

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

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 2017
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 

 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 

 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 

 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 

 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 2017
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 

 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 

 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017