D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Joakim]

On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
> On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
>> 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.
>>
>> Can you list what you or other Weka devs believe those fatal 
>> flaws to be? Because you've not listed any here, which makes 
>> you no better than some noob that comes in here, says D has to 
>> get better or it will die, then can't articulate what they 
>> mean by "better" or worse, mentions something trivial. Of 
>> course, you've actually used the language for years, so 
>> presumably you've got some real concerns, but do you really 
>> think the bug you just posted is "fatal" to the language?
>>
>> If you think there are fatal flaws, you might as well list 
>> them, whether technical or the development process, or you 
>> will just be ignored like any other noob who talks big and 
>> can't back it up. You may be ignored anyway, ;) but at least 
>> you'll have made a case that shows you know what you're 
>> talking about.
>
> I'd define fatal as some that can be fixed, but breaks 100% of 
> everyone's code, even if the change is net positive all round.
>
> However how big a problem really is is in the eye of the 
> beholder. An example:
>
> Symptom: The compiler can't discard unused symbols at compile 
> time, and so it will spend a lot of time pointlessly optimising 
> code.
>
> Problem: D has no notion of symbol visibility.
>
> Possible Solution: Make all globals hidden by default unless 
> 'export'.
>
> Side effects: Everyone will be spending weeks to months fixing 
> their libraries in order to only mark what should be visible 
> outside the current compilation unit as 'export'.
>
> Benefits: Faster compile times, as in, in the most extreme 
> example I've built one project on github with gdc -O2 and build 
> time went from 120 seconds to just 3!

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.

On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh 
wrote:
> On 23/08/18 09:58, Joakim wrote:
>> Because you've not listed any here, which makes you no better 
>> than some noob
>
> Here's one: the forum does not respond well to criticism.

Sounds more like you don't respond well to criticism, as the 
point stands that your original post was content-free.

> Here's an incredibly partial list:
>
> * 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.

> Here is another one:
>
> functions may be @safe, nothrow, @nogc, pure. If it's a method 
> it might also be const/inout/immutable, static. The number of 
> libraries that support all combinations is exactly zero (e.g. - 
> when passing a delegate in).

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

> * Language complexity
>
> Raise your hand if you know how a class with both opApply and 
> the get/next/end functions behaves when you pass it to foreach. 
> How about a struct? Does it matter if it allows copying or not?
>
> The language was built because C++ was deemed too complex! 
> Please see the thread about lazy [1] for a case where a 
> question actually has an answer, but nobody seems to know it 
> (and the person who does know it is hard pressed to explain the 
> nuance that triggers this).

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

> * 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? How much time or 
money exactly has Weka spent on getting this issue and other 
"critical" bugs fixed? 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:

https://www.crunchbase.com/organization/weka-io

> * The community
>
> Oh boy.
>
> Someone who carries weight needs to step in when the forum is 
> trying to squash down on criticism. For Mecca, I'm able to do 
> that [2], but for D, this simply doesn't happen.

As Walter pointed out, "the forum" is not some D hive mind: it's 
a community filled with differing opinions. As I've faced what I 
felt to be unthinking criticism on another issue I raised only 
indirectly related to D, I know somewhat of what you're talking 
about, but honestly, there is a lot of criticism of D and its 
process too here.

Anybody on the internet is free to criticize any opinion you post 
online, you need to get a thicker skin. I really don't see much 
"squashing" going on, and I've previously argued against 
deleting/banning even those who voiced their criticism of D in 
uncouth ways:

https://forum.dlang.org/post/tzubjgtuiyfnmnglwywu@forum.dlang.org

Walter generally has a light touch with deletions/bans.

> This is a partial list, but it should give you enough to not 
> accusing me of making baseless accusations. The simple point of 
> the matter is that anyone who's been following what I write 
> should already be familiar with all of the above.

I see, so every single bug you've ever posted to the forum in the 
past was a fatal flaw? If so, I question your judgement. If not, 
I was simply looking for some prioritization, which flaws were 
"fatal" and why.

> The main thing for me, however, is how poorly the different D 
> features fit together (my first point above). The language 
> simply does not feel like it's composed of building blocks I 
> can use to assemble whatever I want. It's like a Lego set where 
> you're not allowed to place a red brick over a white brick if 
> there is a blue brick somewhere in your building.

This is a common criticism of D. You may be right that it will be 
"fatal." All I was looking for was substantive claims like this.

On Thursday, 23 August 2018 at 09:16:23 UTC, Mihails 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. D would really 
>> benefit from a project manager, which I think Martin Nowak has 
>> tried to do, and which the companies using D and the community 
>> should get together and fund as a paid position. Maybe it 
>> could be one of the funding targets for the Foundation.
>>
>> If the job was well-defined, so I knew exactly what we're 
>> getting by hiring that person, I'd contribute to that.
>
> Didn't intend to chime in, but no, that was not what I have 
> meant at all.

I never said that's what you "meant," it was my own suggestion to 
make things better.