On 4 September 2018 at 04:19, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote:
>>
>> A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it.
>
>
> What resources do you think go into GDC?  I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages.
>

*Looks behind self*

*Looks under desk*

*Looks under keyboard*

There must be resources somewhere, but none appear to be within reach. :-)

On Monday, 3 September 2018 at 22:30:47 UTC, Chris wrote:
> On Monday, 3 September 2018 at 18:52:45 UTC, Laurent Tréguier wrote:
>> On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:
>>> it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk."
>>
>> Well it comes with the Boost license that says: `THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND`
>
> You know exactly what I mean, don't you?

I think I know what you mean. But licenses are not decorative. If it says "WITHOUT WARRANTY OF ANY KIND", it means that it actually comes without warranty of any kind.

On Tuesday, 4 September 2018 at 02:19:20 UTC, Laeeth Isharc wrote:
> On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote:
>> On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote:
>>> Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot.
>
> I didn't give a you don't need an IDE speech, and I didn't say a smooth experience was a bad thing.

I know, I know. But it's always the same story, whenever people wonder about D's state in IDE integration, often other people will just say that vim + terminal is enough.

> But in my experience a strong reality orientation leads to good things coming out of life and telling the universe it should be something different from what it is is a recipe for misery and suffering, and why would you do that to yourself?
>
> So if you want the world to be different, come up with a plan.  It could be I am going to donate X dollars a month to the Foundation to fund IDE development, or if could be figuring out how you can help with the work in whatever way.  But just grumbling - I really think that mistakes the nature of the situation, and not to mention human psychology.  You can accomplish things with a vision that's thought through and inspires others.  Negativity is part of being creative but not if you stop there.

I stated it in an earlier post, I've been working on editor/IDE integration myself because of this. I don't just grumble, although I do like grumbling a lot :)

On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote:
> D is not a petri dish for testing ideas. It's not an experiment.

Well, the general consensus for programming languages is that it a language is experimental
 (or proprietary) until it is fully specced out as a stable formal standard with multiple _independent_ implementations...

On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote:
> On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:
>
>>
>> I think this sort of misunderstanding is the source of a lot of friction on this forum. Some users think (or in my case: thought) that D will be a sound and stable language one day, a language they can use for loads of stuff, while the leadership prefers to keep it at a stage where they can test ideas to see what works and what doesn't, wait let me rephrase this, where the user can test other people's ideas with every new release.
>

First of all, thanks a lot for your answer. I appreciate it. I have to know where I'm standing in order to be able to plan ahead. I don't think this is unreasonable.

> D is not a petri dish for testing ideas. It's not an experiment. It's a serious language. Walter, Andrei, and everyone involved in maintaining and developing it want to see it succeed. They aren't just treading water, wasting everyone's time. And I know you keep hearing this, but I'll say it anyway: most of the development is based on volunteer work, and trying to get volunteers to do anything they don't want to do is like asking them to voluntarily have their teeth pulled when they don't need to.

I have no doubt at all that Walter, Andrei et al are a 100% serious about D, as in "a professional tool" and I do not question their expertise and experience. However, for a bit more than a year I've been under the impression that scarce resources are spent on features and details that are not critical to production when you use D, while more basic things that are sometimes not related to D as such are put on the long finger.

> Walter has said that people come to him and ask what they should work on. He provides them with a list of priority tasks. Then they go off and work on something else. That's the nature of unsponsored open-source development and has been the biggest challenge for D for years.

I can imagine that. This is why volunteers are not the way to go when it comes to core development and the ecosystem. This is why foundations with a lot of funding and IT companies spend a lot of resources on these two aspects.

> I have high hopes that some of this can be turned around by raising more money and I have long-term plans to try and facilitate that over the coming months. With more money, we can get people to work on targeted tasks even when they have no vested interest in it. We can pull in full-time coders, maybe get someone to oversee PR reviews so they don't stay open so long, fund development of broader ecosystem projects.
>
> There isn't anyone involved in the core D development who isn't aware of the broader issues in the community or the ecosystem, and they are working to bring improvements. I have been around this community since 2003. From my perspective, it has been one continuous march of progress. Sometimes slow, sometimes fast, but always moving, always getting better. And right now there are more people involved than ever in moving it forward.
>
> Unfortunately, there are also more demands on more fronts than ever. There are longtime users who become increasingly frustrated when the issues that matter to them still aren't resolved, newcomers who have no context of all the progress that has been made and instead hold D in comparison to Rust, Go, and other languages that have stronger backing and more manpower. That's perfectly legitimate.

Which is what I've been talking about in this thread. D is too old to live with its parents :) Too many people already use it in production or are interested in it. There are a) longtime users who still have to put up with OSS style hacks and are growing tired of it (after years of putting in a lot of effort). There are b) new users who are put off by the lack of a smooth ecosystem. And both groups are told that "that's the way we do things around here".

> And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/

Exactly. As I said in an earlier message, it's not just the money (or the lack thereof), it's the approach. In my opinion Both Walter and Andrei should hire a manager who is not involved in the core development. If you're involved in the core development you cannot be managing things at the same time and "learn as you go along". That's a recipe for disaster. It's not a good idea to mix management and development because they are two completely different things, and you might end up not being good at any of them.

A manager could lay down a practical road map based on what users need _most_, secure funding and direct the funding towards the most urgent issues. Everyone should do what they're good at, only in this way you can get optimal results.

> So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth.

Never would I attribute "disingenuous motives" to the members of the core team. But sometimes perceptions are different and one might not see the wood for trees so it's good to get input from the outside now and again. The reason I got a bit sarcastic or polemical at times is that I didn't get a real answer (until now), especially at a moment when I'm reassessing my programming options for the future. And I don't seem to be the only one either who asks himself "to D or not to D?". Other (new) languages now have many features that made me pick up D in the first place, and they offer a smoother and more comprehensive experience on top of that. I don't think this should be taken lightly by the core team / D Foundation. Don't forget, for various reasons developers are keen on testing new stuff at the moment.

I only posted here to raise awareness of the issues, I could have just left silently as many others have. And yes, I have better things to do than to be on this forum, like testing my future optionst.

On Monday, 3 September 2018 at 16:41:32 UTC, Iain Buclaw wrote:
> 15 years ago, people were complaining that there was only one D compiler.  It is ironic that people now complain that there's too many.

One needs multiple implementations to confirm the accuracy of the language specification. D still has one implementation, i.e. one compiler with multiple backends, distributed as multiple executables (with tweaks).

Anyway, I think people complained about the first and only compiler being non-free. That's not relevant  now, of course.

On Tuesday, 4 September 2018 at 05:38:49 UTC, Iain Buclaw wrote:
> On 4 September 2018 at 04:19, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote:
>>>
>>> A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it.
>>
>>
>> What resources do you think go into GDC?  I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages.
>>
>
> *Looks behind self*
>
> *Looks under desk*
>
> *Looks under keyboard*
>
> There must be resources somewhere, but none appear to be within reach. :-)

If Iain had a beer for every person that complained about the effort spent by team GDC without having first thanked him and his vast team then...

People are sometimes quite disconnected from reality.  At least I have no other explanation for people demanding others do this or do that without doing the minimum necessary to make it appealing for others to work on it.  I mean my experience is that you can pay people a lot of money and ask them beforehand do you want to work on X, and it's no guarantee they actually will be willing to when it comes to it.  Programmers in general can be very independent-minded people, and if somebody is looking for especially meek and compliant people then if you have come to the D forums you are in the wrong place!

One can be much more persuasive with positive words than complaints.  Most people are well aware of that so if they are complaining it's in my judgement because they want to complain.  People with high standards will do that when they feel powerless.  I'm not talking here about notorious highly intelligent trolls like Ola and sock-puppets who never seem to actually write code in D.

But nobody who can keep up here is powerless.

It's possible to change the world you know, and from the most unpromising start.  Forget about what's realistic, and focus on what you want to achieve.  Believe me, you can achieve an awful lot from the most unpromising start.

People talk about how most people are not super-hackers and one shouldn't expect them to manage without polish.  Well hacker is a state of mind,a way of being in the world.  Ask Iain if his self-conception is as a super-hacker with l33t skillz that a mere professional programmer couldn't match and you might be surprised (I think his self-conception might be wrong, but that's Dunning Kruger in action for you).

It's really much more about values and virtues then capabilities.  Are you able to tolerate discomfort and the accurate initial feeling of conscious incompetence?  Because that's what real learning feels like once you leave the spoon-feeding stream of education.

D is a gift to the world from Walter, Andrei, and those who contributed after it was begun.  Just demanding people do stuff for you without doing anything to contribute back - that's not how life works.

I don't think I have ever seen this degree of a feeling of entitlement in my life! And I've been working in finance since 1993.

If doesn't want to pay money towards the development of IDE integration, doesn't want to do any work themselves, then the least they could do is draw up a feature list of what's missing and find a way to help from time to time with the organisation of the work.

That's the only way things ever get done anyway.

Have you noticed how the documentation has gotten much better?  Runnable examples too.  Did that happen because people complained?  No - it happened because Seb Wilzbach (and maybe others) took the initiative to make it happen and did the work themselves.

A little money goes a long way in open source.  So if you're a company and you're complaining and not donating money to the Foundation then what exactly do you expect?  We have a few support contracts with MongoDB (a choice made before I got involved) and the legal fees alone were 20k and we pay about 30k USD a year.  If a few companies contributed at that scale to the Foundation that's at least a couple of full-time developers.

And if you disagree with Andrei and Walter choices about priorities you know you can just direct where the money should be spent as we are with SAoC.

On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
> On 22/08/18 21:34, Ali wrote:
>> On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
>>> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention.
>> 
>> Yea, I agree, the negatives are not really negative
>> 
>> Walter not matter how smart he is, he is one man who can work on the so many things at the same time
>> 
>> Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors
>> 
>
> No, no and no.
>
> I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change.
>
> It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view.
>
> Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them.
>
> And by "fatal", I mean literally flaws that are likely to literally kill the language.
>
> And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis.
>
> And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they?
>
> This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting.
>
> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>
> They don't see the point.
>
> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>
> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.
>
> With great regrets,
> Shachar

Same feeling here btw.

I regularly have to face strange bugs while updating the compiler or its libraries.

For instance, my Resync tool used to work fine both on Windows and Linux.

But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files.

Very typical...

While D remains my favorite file scripting language, I must admit that this is quite disappointing for such an old language, compared to similar languages like Crystal.

On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
> But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files.

What???

There is nothing in the changelog between 2.080.0 and 2.082.0 for changes to std.file.

Version from July 2017[0]. Version from 2.082.0[1]. They look the same to me.

[0] https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430
[1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216

On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
> On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:
>> Let's start with this one:
>> https://issues.dlang.org/show_bug.cgi?id=14246#c6
>>
>> The problems I'm talking about are not easily fixable. They stem from features not playing well together.
>>
>> One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).
>
> The only real problem with D is that it's a language designed with
> GC in mind, yet there are numerous attempts to use it without GC.
> Also, supporting GC-less programming gets in the way of improving
> D's GC (which is pretty damn bad by modern standards).
> That's the only real technical problem.
> For example, the "bug" above just means that D doesn't support RAII
> (in the C++ sense). That's hardly a *fatal flaw*. Lots of languages don't
> support RAII. Python, Java, C# - tons of code were written in those.
> And yes, most of those just use GC to dispose of memory - other resources
> are rarely used (compared to memory) and it's not a problem to manage them
> manually.
> You also mentioned lazy parameters allocating... GC thing again. Just
> allocate then? No?
> IMO, if getting the maximum number of users is the main goal, D is indeed
> going the wrong way. It would be better to get rid of @nogc, betterC, dip1000,
> implement write barriers and use them to improve GC. Martin Nowak (I think)
> mentioned that write barriers will decrease performance of D programs by 1-5%.
> Seems like a small price to pay for better GC with shorter pauses. It would also
> probably be simpler technically than stuff like dip1000 and rewriting Phobos.
> Of course, maximizing the number of users is not the only goal, or even the
> main one. My understanding is that Walter wants a "systems language" with
> "zero cost abstractions". Well, it's very well possible that D's design
> precludes that.
> Other than memory management, I don't see any real fundamental problems.

+1

Making D a "true" C++ competitor is not going to happen soon.

Even Rust, which IS by definition a true C++ competitor (no GC, etc), will still find it very hard to replace C++ in its current niche markets, like embedded and game development.

While putting all the "funded" efforts in making D a *direct* competitor to GC languages (like Go, Crystal, C#, Java, etc) would be an achievable goal, IMHO...