On Tuesday, 7 January 2020 at 20:28:10 UTC, Ali Çehreli wrote:
> On 1/7/20 11:55 AM, p.shkadzko wrote:
>> On Tuesday, 7 January 2020 at 19:21:43 UTC, Ali Çehreli wrote:
>
>>>   http://ddili.org/ders/d.en/ix.html
>
>> Hmm, for some reason in Firefox clicking on any link in this index takes forever to load the indexed section
>
> Thanks for letting me know. However, they should all be simple links with anchors. I hope others can debug and perhaps I can do something on the server side.
>
> Ali

works fine on developer edition 73.0b2

On Monday, 4 November 2019 at 09:03:04 UTC, RazvanN wrote:
> ...
>
> [1] https://www.tiobe.com/tiobe-index/

As for March 2020, D has gone off the top 20 and is now on place 23.

What does that tell us? Not much really, other than that sub 1% language positions are noisy.

I'm surprised C is still on second place. What can we do to kill it really?

On Friday, 6 March 2020 at 15:27:27 UTC, IGotD- wrote:
> On Monday, 4 November 2019 at 09:03:04 UTC, RazvanN wrote:
>> ...
>>
>> [1] https://www.tiobe.com/tiobe-index/
>
> As for March 2020, D has gone off the top 20 and is now on place 23.
>
> What does that tell us? Not much really, other than that sub 1% language positions are noisy.
>
> I'm surprised C is still on second place. What can we do to kill it really?

Easier C interop.
I Love D but lots of times i start to think of returning to C.
I don´t like having to manage bindings , I need something faster that I can just put my C headers there and make it work like I would in C. I love Atilla´s DPP work, but its not *there* yet.

I would like something like how Zig handle this issue. I think that every C programmer that want to swap languages will go eventually to Rust (If they want more safety), or to Zig (easier interop + more power).

D + BetterC have today the "more power" part only.

On Friday, 6 March 2020 at 16:37:08 UTC, SrMordred wrote:
> [snip]
>
> Easier C interop.
> I Love D but lots of times i start to think of returning to C.
> I don´t like having to manage bindings , I need something faster that I can just put my C headers there and make it work like I would in C. I love Atilla´s DPP work, but its not *there* yet.
>
> [snip]

With respect to C interop specifically, what does dpp need to be *there*?

On Friday, 6 March 2020 at 20:14:38 UTC, jmh530 wrote:
> On Friday, 6 March 2020 at 16:37:08 UTC, SrMordred wrote:
>> [snip]
>>
>> Easier C interop.
>> I Love D but lots of times i start to think of returning to C.
>> I don´t like having to manage bindings , I need something faster that I can just put my C headers there and make it work like I would in C. I love Atilla´s DPP work, but its not *there* yet.
>>
>> [snip]
>
> With respect to C interop specifically, what does dpp need to be *there*?

There are still somethings that fail to parse.(but thats a minor thing )
But the "problem" i see is that is a separate project. I have to clone it, make a working executable (that had problems on windows on the first time that i tried , but it was solved), then make a dpp file (instead of just working with D files ).
Not sure how it work with header only libs.

Its not that we can´t do nice stuff with it, but this little frictions slowly build up, and u start to look for alternatives.

And it feels like outside the realm of D.
(where do a manage all this ? postScripts in dub files?, makefiles? caching? )

I questioned a few days ago about an integration of dpp with dub that i heard last year (that can potentially decrease this friction ), but nobody answered me.

On Saturday, 7 March 2020 at 02:49:43 UTC, SrMordred wrote:
> On Friday, 6 March 2020 at 20:14:38 UTC, jmh530 wrote:
>> On Friday, 6 March 2020 at 16:37:08 UTC, SrMordred wrote:
>>> [snip]
>>>
>>> Easier C interop.
>>> I Love D but lots of times i start to think of returning to C.
>>> I don´t like having to manage bindings , I need something faster that I can just put my C headers there and make it work like I would in C. I love Atilla´s DPP work, but its not *there* yet.
>>>
>>> [snip]
>>
>> With respect to C interop specifically, what does dpp need to be *there*?
>
> There are still somethings that fail to parse.(but thats a minor thing )
> But the "problem" i see is that is a separate project. I have to clone it, make a working executable (that had problems on windows on the first time that i tried , but it was solved), then make a dpp file (instead of just working with D files ).
> Not sure how it work with header only libs.
>
> Its not that we can´t do nice stuff with it, but this little frictions slowly build up, and u start to look for alternatives.
>
> And it feels like outside the realm of D.
> (where do a manage all this ? postScripts in dub files?, makefiles? caching? )
>
> I questioned a few days ago about an integration of dpp with dub that i heard last year (that can potentially decrease this friction ), but nobody answered me.

New dub features are usually implemented by the developers most eager to have these features. That makes totally sense in my opinion as these developers knows what they want, how they want it and what they don't want

That said, I think it is not needed to enhance dub. Dub supports a lightweight plugin feature: dependencies which makes use of pre/post generateCommands. These commands are always executed.

This feature is not investigated in detail so far but someone can try to make a DPP plugin and checks whether everything already works, or some small dub enhancement is missing.

Kind regards
Andre

On Friday, 6 March 2020 at 15:27:27 UTC, IGotD- wrote:
> I'm surprised C is still on second place. What can we do to kill it really?

That does not surprise me, and I don't see C going anywhere in the foreseeable future.

It's the common denominator between native languages like C++, D, Rust etc. And it interfaces with assembly-language. For system programming, it's the obvious language: easy to grasp and powerful. However, it's obviously not as expressive as like C++, that's true.

For example, Vulkan API is written in C, and it's a beautiful API. If it had been written in C++ (or any other native language), it would have been probably more expressive, but it would have lost a lot in terms of efficiency.

Another advantage of C is that, as it's a smaller language, it's easier to enforce a coherent coding-style for a community project.

On Saturday, 7 March 2020 at 02:49:43 UTC, SrMordred wrote:
> On Friday, 6 March 2020 at 20:14:38 UTC, jmh530 wrote:
>> With respect to C interop specifically, what does dpp need to be *there*?
>
> There are still somethings that fail to parse.(but thats a minor thing )
> But the "problem" i see is that is a separate project. I have to clone it, make a working executable (that had problems on windows on the first time that i tried , but it was solved), then make a dpp file (instead of just working with D files ).
> Not sure how it work with header only libs.
>
> Its not that we can´t do nice stuff with it, but this little frictions slowly build up, and u start to look for alternatives.
>
> And it feels like outside the realm of D.
> (where do a manage all this ? postScripts in dub files?, makefiles? caching? )
>
> I questioned a few days ago about an integration of dpp with dub that i heard last year (that can potentially decrease this friction ), but nobody answered me.

When I made my D-lite language Neat back in 2009ish, one of the things I was most proud of was the C interop. You could just write `import c.SDL` and it would go look for SDL.h, give it to gcc to preprocess, fish out defines, structs and function declarations and insert them all into a module. There was even magic glue that made the common case of "void foo_fun(FooState* state, int i)" callable as "state.fun(i)", with zero extra effort required. It was very slick when it worked :)

To be fair, I could only do this because I was the only user, and I could tweak the C parser as required; it never really worked *reliably* for a new header. Still, the sheer ease of use is something I do miss.

If D ever gets macros, or I get my own "D with macros" language going, whichever of those very unlikely events comes first, this is definitely something that should be a macro, but with a CTFE macro something like `import include.SDL` seems very doable.

On Monday, 9 March 2020 at 12:27:34 UTC, FeepingCreature wrote:
>
> When I made my D-lite language Neat back in 2009ish, one of the things I was most proud of was the C interop. You could just write `import c.SDL` and it would go look for SDL.h, give it to gcc to preprocess, fish out defines, structs and function declarations and insert them all into a module. There was even magic glue that made the common case of "void foo_fun(FooState* state, int i)" callable as "state.fun(i)", with zero extra effort required. It was very slick when it worked :)
>


Thats really nice! Yeah, this kind of "no-effort-interop" is something that allow people to change languages but keep libs old codes to live on, therefore allowing them to keep working on the new language(increasing user retention). I feel that is a interesting thing for D to pursuit.

Out of curiosity, are u working with D or are working/exploring other languages(or custom lang, maybe ) ?

I feel that the closest thing of your D-lite language C interop that i know today is Zig.

On Monday, 9 March 2020 at 10:21:16 UTC, Claude wrote:
> On Friday, 6 March 2020 at 15:27:27 UTC, IGotD- wrote:
>> I'm surprised C is still on second place. What can we do to kill it really?
>
> That does not surprise me, and I don't see C going anywhere in the foreseeable future.
>
> It's the common denominator between native languages like C++, D, Rust etc. And it interfaces with assembly-language. For system programming, it's the obvious language: easy to grasp and powerful. However, it's obviously not as expressive as like C++, that's true.
>
> For example, Vulkan API is written in C, and it's a beautiful API. If it had been written in C++ (or any other native language), it would have been probably more expressive, but it would have lost a lot in terms of efficiency.
>
> Another advantage of C is that, as it's a smaller language, it's easier to enforce a coherent coding-style for a community project.

DirectX, Metal, NVN, libGNM and libGNMX are doing pretty well, for APIs not written in C.