On 23/08/18 17:01, Steven Schveighoffer wrote:
> So interestingly, you are accepting the sockaddr by VALUE.

Indeed. The reason is that I cannot accept them by reference, as then you wouldn't be able to pass lvalues in. Another controversial decision by D.

Had that been C++, I'd definitely get a const ref instead.

Shachar

On 08/23/2018 05:17 PM, H. S. Teoh wrote:
> And the nice thing about D being open source is that should the
> situation escalate to the point where the community simply cannot get
> along with W&A anymore, forking is always an option.

But forking only happens when the dissenters have enough motivation to do it. If they don't, they might just fade away one by one, looking for greener pastures elsewhere. That would probably be the worst outcome for D: the community shrinks until it's just Walter and Andrei wondering where everybody did go.

Now, I don't know if the amount of (quality) contributors is actually growing, shrinking, or stagnating. But I do know that I feel the pull (push?) away from D myself.

It feels like `@safe` and `shared` won't ever be solid. Auto-decoding won't go away. Unsound conversions (e.g., `char` -> `dchar`) won't go away. Regressions aren't being fixed (78 open). Wrong-code don't get fixed (170!). Etc., and so on. So why even bother?

Currently, I'm toying with ideas for a hobby language of my own. I know that it most likely won't go anywhere, but wasting time on that starts to feel more rewarding than wasting it on D.

On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
> Waiting for the community to fix a bug in D that is blocking Weka will get Weka kicked out of the market. There is no value proposition. We simply have to work faster than that.
>
> Oh, and our code base over 300,000 lines. Don't say "dustmite". It is unable to process the code.

A quick question, if Weka did not have the current 300k backlog of code, what language of choice is more likely to be picked by the team at Weka?

On 24/08/2018 4:39 AM, ag0aep6g wrote:
> Currently, I'm toying with ideas for a hobby language of my own. I know that it most likely won't go anywhere, but wasting time on that starts to feel more rewarding than wasting it on D.

I've been doing that for a few years now.
My parser generator is slowly coming together.

I'll probably start by trying to spec out D in it.

On 23/08/18 18:35, Joakim wrote:
> 
> So your example of a fatal flaw is that D could be 100X faster at compilation instead of just 10X than most every other native language out there?! C'mon.

Have you tried Stephan's example yet?

static foreach(i; 0..16384) {}

Do give it a shot, tell me what you think of its compilation time.

> On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh wrote:
>> * Features not playing well together.
>>
>> Despite what Joakim seems to think, I've actually brought up an example in this thread.
> 
> Despite what you seem to think, perhaps because you didn't read what I wrote very closely, I noted your bugzilla link in my post you're quoting and asked you if you really thought it was fatal.

Each problem on its own, maybe not. All together? Most definitely.

A language needs to be coherent. A programmer needs to be able to look at code and know what the compiler will make of that code. The less that can happen, the less useful the language is.

This is, in fact, precisely the criticism the D community levels against C++.

> Yes, this is a known problem with D: why do you think it's fatal?
See above.

> 
> By this rationale, C++ should be dead by now. Why do you think it's fatal to D?

C++ does not suffer from this *kind* of complexity. For the most part, C++'s complexity is feature centric. You use a feature, you need to really learn that feature in order to get it to work.

D's complexity is waiting to pounce you behind street corners. You use a feature, and all's well. And then, when you're doing stuff completely tangential to your old code, things suddenly break.

You can avoid C++'s complexity by not using features. The same is not true of D.

With that said, who said these problems don't affect C++? Had C++ not being plagued by these problems, D (and Rust, and Go, and so on) would probably never had been born. These are languages written with the explicit hope of killing C++.

They do not seem like they are going to, but D lacks quite a few things that C++ has going for it. To name a few:

* Large community
* excellent tooling
* large use base

> 
>> * Critical bugs aren't being solved
>>
>> People keep advertising D as supporting RAII. I'm sorry, but "supports RAII" means "destructors are always run when the object is destroyed". If the community (and in this case, this includes Walter) sees a bug where that doesn't happen as not really a bug, then there is a deep problem, at least, over-promising. Just say you don't support RAII and destructors are unreliable and live with the consequences.
>>
>> BTW: Python's destructors are unworkable, but they advertise it and face the consequences. The D community is still claiming that D supports RAII.
> 
> Maybe they're not critical to everyone else?

Maybe. Just don't lie to users.

> How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed?

Weka is paying prominent D developers as contractors. We've had David Nadlinger and currently employ Johan Engelen. Both said they are cannot fix this particular bug.

If you can, feel free to contact me off-list, and I'm fairly sure we can get the budget for you to work on it. The same goes for anyone else on this list.

We also contribute our own workarounds for D's shortcomings for everyone to enjoy. This include DIP-1014 and Mecca, as well as the less obvious upstreaming of bugs our contractors fix. This is beyond the fact that our "fork" of the compiler is, itself, public (https://github.com/weka-io/ldc). I think claiming that Weka is leaching off the community is simply unwarranted.

> It is fairly laughable for a company that raised $42 million to complain that a bunch of unpaid volunteers aren't fixing bugs fast enough for them:

First of all, and this is important, I do not speak for Weka. I can pass recommendations, and I can sometime estimate in advance what will and what will not be approved, but that's it. As *I* don't have 42 million dollars, I find that particular criticism irrelevant (not to mention downright incorrect, as pointed above).

With that said, I am not complaining about anything. I am stating the situation as I see it. I understand it is uncomfortable to hear, and thus the aggressiveness of your response. I can only point out the obvious: you shaming me will not make me change my mind. At best, it will make me not say it publicly.

Shachar

On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
> On 23/08/18 17:01, Steven Schveighoffer wrote:
> My main job is to develop for Weka, not develop D itself.

Weka, at some point, made the strategic decision to use a non mainstream language

I dont think Weka, have a choice, they have to invest in the development of D itself

On Thu, Aug 23, 2018 at 06:39:32PM +0200, ag0aep6g via Digitalmars-d wrote:
> On 08/23/2018 05:17 PM, H. S. Teoh wrote:
> > And the nice thing about D being open source is that should the situation escalate to the point where the community simply cannot get along with W&A anymore, forking is always an option.
> 
> But forking only happens when the dissenters have enough motivation to do it. If they don't, they might just fade away one by one, looking for greener pastures elsewhere. That would probably be the worst outcome for D: the community shrinks until it's just Walter and Andrei wondering where everybody did go.

If that's what it takes, then maybe that will be the point where they start addressing issues that drove people away? :-P


> Now, I don't know if the amount of (quality) contributors is actually
> growing, shrinking, or stagnating. But I do know that I feel the pull
> (push?) away from D myself.
> 
> It feels like `@safe` and `shared` won't ever be solid.

To be honest, I've been skeptical of @safe since the first time I read about it in TDPL.  It feels like something tacked on, rather than integrated into the language design, and it's exactly the kind of feature that needs to be designed into the language from day one in order to have a chance of actually being successful.  Over the years, the holes in the implementation hasn't made my confidence much stronger, and as a result, in my own code I rarely, if ever, use @safe.  Maybe in self-contained modules I'd do it, and then mostly only via automatic attribute inference and annotated unittests to prevent regressions.

`shared`... TBH, I haven't really needed to use it, and from the little I know of it, it seems so cumbersome to use and bug-ridden in the current implementation that I don't think I'll ever use it.  Sometimes it's just not worth the trouble to fight with a language feature that TBH isn't thoroughly-enough designed to fit in with other language features seamlessly. I'd rather find a different way of approaching my programming problem that wouldn't require `shared`.


> Auto-decoding won't go away.

Yeah, this is a big one for me.  Ironically, Walter actually agrees that autodecoding was a bad idea.  But byCodePoint / byCodeUnit has so far been a usable (if not as pleasant) workaround for the most part.


> Unsound conversions (e.g., `char` -> `dchar`) won't go away.

Yeah, another annoying holdover from C/C++ that doesn't make any sense. This is one issue where I'd be happy for breaking changes that will clean up the core language.


> Regressions aren't being fixed (78 open). Wrong-code don't get fixed
> (170!).  Etc., and so on. So why even bother?

I think this is unfair.  Regressions *are* being fixed... but they're getting reported at a faster rate than they're being fixed.  Wrong-code bugs also *are* getting fixed... just not as fast as we'd like, but I think it's unfair to say they aren't getting fixed.

Overall, I think with the number of regressions being introduced every release, we really got into language-freeze mode way too early.  The fear of breaking changes has gotten to the level of paranoia, yet at the same time regressions keep happening.  IMNSHO, if there are going to be so many regressions anyway, why not take the chance to pull off breaking changes like killing autodecoding, killing unsound conversions, and a number of other small but cumulatively annoying rough edges that have been thorns in our sides for years.  Unfortunately, I don't see this happening in the near future.


> Currently, I'm toying with ideas for a hobby language of my own. I know that it most likely won't go anywhere, but wasting time on that starts to feel more rewarding than wasting it on D.

I've felt the temptation myself, actually.  The thing that's stopping me from actually doing it is that I simply don't have the time it takes to actually pull it off.

To put things in perspective, though: despite all of D's rough edges and certain dark corners where you run into implementation bugs, features that clash with each other, and other such unpleasant things, I still find D much more pleasant to use than C/C++ or Java. Go isn't even on my radar because it lacks generics. And Rust... honestly, I really cannot see myself going back to the dark world of worrying about memory management in every piece of code I write. That's simply the wrong level of abstraction to be working at, IMO, when your programming problem isn't to implement a memory manager.  And I'm not interested in non-compiled languages, so Python isn't really on my consideration either.  D is far from perfect, but I haven't yet found something closer to my personal ideal of what a programming language should be like.  So for the time being, given the choice, I'd still choose D over any other language.


T

-- 
Do not reason with the unreasonable; you lose by definition.

On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
>
>
> On 23/08/18 18:35, Joakim wrote:
>> 
>> So your example of a fatal flaw is that D could be 100X faster at compilation instead of just 10X than most every other native language out there?! C'mon.
>
> Have you tried Stephan's example yet?
>
> static foreach(i; 0..16384) {}

I don't see any posts by a "Stephan" in this thread. I don't doubt that there are degenerate cases in D's compile-time features, particularly the new ones.

> Each problem on its own, maybe not. All together? Most definitely.
>
> A language needs to be coherent. A programmer needs to be able to look at code and know what the compiler will make of that code. The less that can happen, the less useful the language is.
>
> This is, in fact, precisely the criticism the D community levels against C++.

Ah, I see none of these are "fatal flaws," but they all combine together to create a fatal situation. That's an argument that can actually be defended, but not the one you started off making.

>> By this rationale, C++ should be dead by now. Why do you think it's fatal to D?
>
> C++ does not suffer from this *kind* of complexity. For the most part, C++'s complexity is feature centric. You use a feature, you need to really learn that feature in order to get it to work.
>
> D's complexity is waiting to pounce you behind street corners. You use a feature, and all's well. And then, when you're doing stuff completely tangential to your old code, things suddenly break.
>
> You can avoid C++'s complexity by not using features. The same is not true of D.

Sorry, it sounds like you're simply saying you prefer one type of complexity to another. I'm not a C++ developer, but my understanding is it has many of the same problems as D, more because of backwards compatibility.

> With that said, who said these problems don't affect C++?

Nobody, that's my point in bringing it up.

>Had C++ not being plagued by these problems, D (and Rust, and Go,
> and so on) would probably never had been born. These are languages written with the explicit hope of killing C++.
>
> They do not seem like they are going to, but D lacks quite a few things that C++ has going for it. To name a few:
>
> * Large community
> * excellent tooling
> * large use base

My point was that C++ has always had what you believe to be the "fatal flaw" of incoherence, yet was able to build all those up. Walter has been there from the beginning and seen how C++ did it, perhaps his anarchy-driven development isn't so misguided after all.

>>> * Critical bugs aren't being solved
>>>
>>> People keep advertising D as supporting RAII. I'm sorry, but "supports RAII" means "destructors are always run when the object is destroyed". If the community (and in this case, this includes Walter) sees a bug where that doesn't happen as not really a bug, then there is a deep problem, at least, over-promising. Just say you don't support RAII and destructors are unreliable and live with the consequences.
>>>
>>> BTW: Python's destructors are unworkable, but they advertise it and face the consequences. The D community is still claiming that D supports RAII.
>> 
>> Maybe they're not critical to everyone else?
>
> Maybe. Just don't lie to users.

Is it a lie if you don't know about some bug in the implementation?

>> How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed?
>
> Weka is paying prominent D developers as contractors. We've had David Nadlinger and currently employ Johan Engelen. Both said they are cannot fix this particular bug.
>
> If you can, feel free to contact me off-list, and I'm fairly sure we can get the budget for you to work on it. The same goes for anyone else on this list.

I'm sorry, I wouldn't know how to and am not interested in learning.

> We also contribute our own workarounds for D's shortcomings for everyone to enjoy. This include DIP-1014 and Mecca, as well as the less obvious upstreaming of bugs our contractors fix. This is beyond the fact that our "fork" of the compiler is, itself, public (https://github.com/weka-io/ldc). I think claiming that Weka is leaching off the community is simply unwarranted.

Sure, but nobody claimed you're just leeching: I know you've contributed in various ways. But the question stands: were you able to apply time/money to get any _critical_ bugs fixed and upstreamed? If so, why don't you believe you could get more fixed? Nobody's asking you to do it all yourself, you could work with Sociomantic and the community to raise bounties on those issues.

>> It is fairly laughable for a company that raised $42 million to complain that a bunch of unpaid volunteers aren't fixing bugs fast enough for them:
>
> First of all, and this is important, I do not speak for Weka. I can pass recommendations, and I can sometime estimate in advance what will and what will not be approved, but that's it. As *I* don't have 42 million dollars, I find that particular criticism irrelevant (not to mention downright incorrect, as pointed above).

I don't think it's irrelevant or incorrect, as that's essentially what you're doing. You may not officially represent Weka, but you're basically complaining that you can't get your work done properly with these bugs, which is done at Weka. That reflects on Weka, whether you like it or not.

> With that said, I am not complaining about anything. I am stating the situation as I see it.

Yes, you're stating a giant complaint about the way things are being done.

> I understand it is uncomfortable to hear, and thus the aggressiveness of your response.

The only part's that's uncomfortable is your continual rhetorical strategy to exaggerate, then when that's pointed out, to claim you're being "squashed" or "shamed."

I want accurate, substantive claims about D and feel no discomfort from such, some of which you've made. I'm only aggressive in trying to understand what the underlying roots of your unhappiness are and pointing out ways to fix it. You seem intent on casting that as something else.

> I can only point out the obvious: you shaming me will not make me change my mind. At best, it will make me not say it publicly.

I think you misinterpret my questions. I've been trying to get you to add substance to your initial broad claims with all my posts and questions. That is an attempt to elicit real, substantial criticism, not silence or shame it.

On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
>> On 23/08/18 17:01, Steven Schveighoffer wrote:
>> My main job is to develop for Weka, not develop D itself.
>
> Weka, at some point, made the strategic decision to use a non mainstream language
>
> I dont think Weka, have a choice, they have to invest in the development of D itself

This sounds about right.

Obviously the solution  is to have the payed consultants fill those bugs for you if you think your time is not best spent at this.

The only issue I can see here is that the D BDFL would need to be in the loop so they can expedite the fix/review of those bugs. Or design some kind of process for this.

I know Dlang foundation has a sponsor package that has some level of support. I'd be interested to see if this can work for Wekka, as others might be in the same boat at some point.

On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
>> On 23/08/18 17:01, Steven Schveighoffer wrote:
>> My main job is to develop for Weka, not develop D itself.
>
> Weka, at some point, made the strategic decision to use a non mainstream language
>
> I dont think Weka, have a choice, they have to invest in the development of D itself

I hope a startup can choose D without having to do that. Otherwise D is not really a viable option for startups because they need to focus on survival rather than language development.