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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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.

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.

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.

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/

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.

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.

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.

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.

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.