On Friday, 5 June 2020 at 04:55:36 UTC, FeepingCreature wrote:
> mixin but no macros

Reminds me of q{}-based mixins: https://forum.dlang.org/post/jekltctbqxettfzzefbc@forum.dlang.org

It's not macros directly, but about the best you can get from macros without suffering from the bad consequences of C++ macros, including the proposal getting directly rejected by Walter.

On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
> What are you?

My days in college were assignments in Java and reimplement them in D. My sharpened languages today are C# and D.

I have utilities written in D at work and my hobby programming, not much these days. I develop test automation for a web based app as my day job.

My preference to use D probably comes from a number of different parts.

* I'm familiar with the library selection
* The language has many toys to play with
* I am easily able to do meta programing to write code for me (C# feels like the compiler avoids helping you to write correct meta programs)

With having history in D I have these benefits

* I know when I'm pushing the boundaries of the language
* writing a quick hack for a specific use case can be easier than finding a generic library that mostly fits.

But things get even stranger when I consider the tools at work.

I don't have any other contributors, supposedly because it is D and not C#. But I think we just don't have a good support system for these tools. I personally have jumped into improving VB, python, powershell, Javascript, batch, and obviously C#.

When we look at the future of our automation, it looks like Javascript will be the language to go to. But even that is a concern because our crew knows C# and it seems like even moving to a mainstream language is going to be a pain.

So now when I need a script for some infrastructure at work... I'm dead in the water. I want to write it in D. I feel obligated to use something standard, I don't want to build it in something standard and then be the sole maintainer.

On Thursday, 11 June 2020 at 04:51:28 UTC, Jesse Phillips wrote:
> On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
>> [...]
>
> My days in college were assignments in Java and reimplement them in D. My sharpened languages today are C# and D.
>
> [...]

Seems like you're in the tight position choosing between these two.

I've talked to folks who say D is nice but the ecosystem doesn't help to get things done...libraries, development tools, and content seems to pop up a lot.

On Thursday, 11 June 2020 at 11:07:12 UTC, aberba wrote:
> On Thursday, 11 June 2020 at 04:51:28 UTC, Jesse Phillips wrote:
>> On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
>>> [...]
>>
>> My days in college were assignments in Java and reimplement them in D. My sharpened languages today are C# and D.
>>
>> [...]
>
> Seems like you're in the tight position choosing between these two.
>
> I've talked to folks who say D is nice but the ecosystem doesn't help to get things done...libraries, development tools, and content seems to pop up a lot.

True. What I do for writing selenium based tests, or switch to another browser test API just would not be possible today. We would have to build the api communication from the ground up. The company I work for doesn't develop software testing solutions so I would not be able to convince them to put what would basically be money to improve D.

I think D is fine for the scripts we tend to have and if every was fluent/enjoying D, I could see time taken to implement something in D. But I'm working with QA and developers which don't appear to be doing it for the joys of programming.

On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips wrote:
> I think D is fine for the scripts we tend to have and if every was fluent/enjoying D, I could see time taken to implement something in D. But I'm working with QA and developers which don't appear to be doing it for the joys of programming.

Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm. That will be the case until/unless D becomes a mainstream language with a better reason to use it than "it's a fun language to program in".

On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
> On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips wrote:
>> I think D is fine for the scripts we tend to have and if every was fluent/enjoying D, I could see time taken to implement something in D. But I'm working with QA and developers which don't appear to be doing it for the joys of programming.
>
> Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm.

I don't think the core team wants it to remain this way. Unless D is fine staying this way for another 10yrs. By then we'll all be gone.


> That will be the case until/unless D becomes a mainstream language with a better reason to use it than "it's a fun language to program in".
It depends on what you mean by mainstream. These issues as I cited are not not related to the language itself per se. Its related to the ecosystem.

And its mislead to make it seem like there's some "elite" group of coders here who are absolutely comfortable with the current state of affairs. Besides, you can read from all the experiences shared in this thread and see how many of them are not related to D itself being a blocker. Its the other stuff.

Do we know how many people use D or are interested in D? No. Do we know the "self-selected group" of people or the sort of interest in D? No. Do we know what people are using D for in their companies? I'm not sure we do.

Very little survey is done on some of these things. Its again misleading to think comments here is a true representation of D users. Many people I've unexpectedly met online almost never post anything here.

And since no~ one really knows where the D money goes and where help is much needed (as such information is not available for community members to know), I'll say there not much~ financial investment into D tools. To expect that someone will do this for free is almost not going to happen. Again we've seen that anytime the D Foundation pays someone (through funds, campaign, etc), job gets done.

If there was an "elite" group of hard-core programmers who don't care about tools, Visual Studio wouldn't exist in the first place.

I'm not saying we are Microsoft, I'm saying we should NOT beat down concerns and issues expressed in relations to the tools we have or don't have...yet.

I'm personally very glad we have people here who go as far (some each and every days for yrs) to invest heavily in D tools out of their free time. But that alone is not enough for a small community like ours. Again the community could be bigger.

And about community, it not just about popularity at all. Its more about having many hands on deck, people with diverse skills and experience to contribute to both the core language, tools, resources, finance and the like.

On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
>
> Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm. That will be the case until/unless D becomes a mainstream language with a better reason to use it than "it's a fun language to program in".

I'm quite thankful for what D has done for me.

I've only done a little bit of C and C++. I really didn't want to program in those languages. D has allowed me access to similar tools and abilities to interact with C based libraries easily. As annoying as the Win32 api can be, I can still easily incorporate it into my programs.

When I work with C# there are times I'm pretty sure my api would be better in D. Every time I reach for generics it is never the tool I think it is and I have to resort to runtime type information.

On Thursday, 11 June 2020 at 20:21:12 UTC, aberba wrote:
> On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
>> On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips wrote:
>>> I think D is fine for the scripts we tend to have and if every was fluent/enjoying D, I could see time taken to implement something in D. But I'm working with QA and developers which don't appear to be doing it for the joys of programming.
>>
>> Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm.
>
> I don't think the core team wants it to remain this way. Unless D is fine staying this way for another 10yrs. By then we'll all be gone.
> <snip>

I *think* we're in agreement here. I just wanted to correct your inference that I meant some kind of "elite" super hackers when I said that the people posting on this list are a "self-selected group". What I meant is that the people who generally post on this mailing list are by definition not average programmers, in that they don't just learn the popular languages/frameworks you need to know to get a job and stick to those; they go out of their way to use more obscure and possibly experimental languages out of a joy for programming and/or taking new and interesting approaches to problems. That being said, a lot of the people who post here are far and away some of the best programmers I've ever seen, and I've learned a great deal just being involved with D in some small capacity.

On Saturday, 6 June 2020 at 21:14:44 UTC, Steven Schveighoffer wrote:
> To continue the "show" analogy, consider a theater show where all the show light bulbs burn out simultaneously. You could say "Well, they can do it by flashlight," and yes, it could happen. People wouldn't be able to see it, but the show would *happen*. So one could argue that not having significant lighting is not a showstopper in the way you are saying "just use void initialization".

Ugliness is intended, though. Even if you know what you are doing, even if nothing can go wrong, you still must write ugly code to do basic things - this is exactly what Manu proposes. And it's predictably frustraiting too, guess it's about time you understand the obvious.

On Tuesday, 9 June 2020 at 16:33:13 UTC, Stanislav Blinov wrote:
> There's no need for a new interface. What needs to happen is resolution of [1] and amendment to destroy() so it avoids rt_finalize and infers correct attributes. Which, even three years later, I maintain should be resolved by disallowing classes to loosen destructor attributes.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=15246
>
> Until that happens, locally, in your own codebase, you can just have your own variant of destroy() that infers attributes as weakest of all in a given hierarchy. Provided you don't write classes that violate dtor attributes down the inheritance chain.
> So at least this problem can be sidestepped, though I agree it should have a formal resolution in the language and the runtime library.

Destructors should be already @nogc, it's a contract imposed by GC itself, it's not formally enforced because destructors predate @nogc attribute, but violation of the contract is still a bug in user code, so destroy can simply cast destructors to @nogc and call like that.