On 8/23/18 12:22 PM, Shachar Shemesh wrote:
> On 23/08/18 17:01, Steven Schveighoffer wrote:
>> I'm not saying all bugs you file will be fixed, but all bugs you *don't* file will definitely not be fixed.
> 
> So far, my experience is that it has about the same chances of being fixed both ways, and not filing takes less effort.

I have had much better success with bugs being fixed for issues that I file vs. hoping someone fixes it without a report, not just in D's ecosystem, but pretty much anywhere.

But that's the choice you make. We'll have to disagree on that one. It's hard to fix bugs without reports, but hey, maybe you will get lucky and someone fixes them by accident.

-Steve

On Thursday, 23 August 2018 at 18:27:27 UTC, Abdulhaq wrote:
> On Thursday, 23 August 2018 at 09:51:43 UTC, rikki cattermole wrote:
>>> Good luck getting W&A to agree to it, especially when there is yet another "critical D opportunity" on the table ;)
>>
>> No. They have power for as long as we the community say that they do.
>> We are at the point where they need a check and balance to keep everybody going smoothly. And I do hope that they listen to us before somebody decides its forkin' time.
>
> No fork of D can be successful, it won't have the manpower, skills or willpower to draw on. Even with W and A it's already short.
>
> 'Threatening' W and A with a fork is an empty threat that just p***es them off. Bad move on your part.

Agreed, W&A's "power" is that they have done or are doing much of the work and that enough people trust they're better at how they work than those forking. That would be a very high bar for any forking team to surpass.

On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis wrote:
>
> D does have a problem in general of having a lot of great features that work really well in isolation but don't necessarily work well in concert (and it doesn't help that some features have really never been properly finished). And frequently, the answer that folks go with is to simply not use sections of the language (e.g. it's _very_ common for folks to just give up on a lot of attributes like pure, nothrow, or @safe). A number of the issues do get worked out over time, but not all of them do, and sometimes the solutions cause a lot of problems. For instance, DIP 1000 may end up being great for @safe and will help solve certain issues, but it results in yet another attribute that has to be pasted all over your code and which most folks simply won't use. So, it's helping to fix a real problem, but is it making things better overall? I don't know.
>
> And while I definitely think that D is easier to understand than C++ (in spite of the increase in D's complexity over time), it's also very much true that D continues to get more and more complicated as we add more stuff. Generally, each solution is solving a real problem, and at least some of time, the solution actually interacts quite well with the rest of the language, but it all adds up. And honestly, I don't think that there's a real solution to that. Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less.
>
> D definitely improves over time, but certain classes of issues just never seem to be fixed for some reason (e.g. the issue with RAII and destructors really should have been fixed ages ago), and some of the major design decisions don't get fully sorted out for years, because they're not a high enough priority (e.g. shared). I don't really agree that D is in much danger of dying at this point, but I completely agree that we as a group are not doing a good enough job getting some of the key things done (much of which comes down to an issue of manpower, though some of it is also likely due to organizational issues).
>
> - Jonathan M Davis

This is a great summary of the situation, thanks for such a good and honest appraisal. From a technical POV I'd say it could replace the whole thread.

But there is a social/psychological aspect to the whole thing. Sachar's comment is obviously the cry of pain of someone whose back has just been broken by a last straw. He is being told, 'the straw you are complaining about is nothing'.

There is a class of developers who expect things to Just Work TM, especially if they are told that it Just Works. Each time that they discover some combination of features that doesn't work they have to refactor their code and remember not to try that again. Ultimately the developer painfully learns the things that they should not attempt to use, or they give up before the process is complete and leave. I expect the pain caused by this is much more acute in a commercial environment where the pressure is on.

Long term D developers have learnt not to bother with certain features or combinations of features and forget all the pain they went through to get that knowledge. They are ones saying, come in the water's lovely.

For anyone considering using D for a commercial project the situation you describe is cause for concern. The issues can be fixed but it will take some brave and ruthless decisions, I suspect.

On 8/23/2018 5:55 AM, Steven Schveighoffer wrote:
>> If front() returns by ref, then no copying happens. If front() returns by value, then a copy is made. This should not be surprising behavior.
> I think he means, if the range ITSELF doesn't allow copying, it won't work with foreach (because foreach makes a copy), but it will work with opApply.

    foreach (ref v; collection)

does not make a copy. It's up to the programmer whether copying is done with it. After all, if one is passing a struct instance around by value instead of by ref, there is no escaping copying it. This should not be surprising.

Designing a non-copyable struct is a more advanced technique, and it is reasonable to expect that someone using it should understand the consequences.


> There are many people who post short curt answers, maybe even cynical. But this isn't necessarily the authoritative answer. Where I see this happening, I usually try to respond with a more correct answer (even though my voice isn't authoratative exactly), but the sad truth is that we can't spend all our day making sure we have a super-pleasant forum where every answer is valid and nobody is rude.

The D forums are deliberately set up to allow people the freedom to say what they wish as much as possible, we only put minimal restrictions on it, such as we expect professional demeanor.

What we aren't going to do is vet every post for consisting only of approved opinions. That wouldn't even be a forum - it would be an echo chamber.


> In reply to Shachar's general point:
> This whole thread seems very gloomy and final, but I feel like the tone does not match in my mind how D is progressing. "Every single one of the people [at Weka] rushing to defend D at the time has since come around." Seems like you all have decided to either ditch D internally, maybe moving forward, or accepted that Weka will fail eventually due to the choice of D? It sure reads that way.
> 
> This is in SHARP contrast to the presentation that Liran gave at Dconf this year, touting D as a major reason Weka was able to develop what they did, and to some degree, your showcase of how Mecca works.
> 
> My experience with D is that it has gotten much better over the years. I suppose that having worked with the earlier versions, and seeing what has happened gives me a different perspective. I guess I just don't have that feeling that there are some unfixable problems that will "kill" the language. Everything in a programming language is fixable, it just matters how much pain you are willing to deal with to fix it. If we get to a point where there really is a sticking point, D3 can be born.
> 
> I do feel that we need, in general, more developers working on the compiler itself. So many of the problems need compiler changes, and the learning curve to me just seems so high to get into it.

I've been programming for 40 years. Every language, and every implementation, has had problems, often requiring significant effort to deal with them. The issue for me is, can I get my work done?

For example, @safe isn't 100%. But simply having buffer overflow checking eliminates a vast array of problems. It's the #3 security bug of all time. dmd's source code does not use @safe, and I've recently noticed string handling code that had buffer overflow bugs in it as a result.

Nobody is going to guarantee the airplane you're flying on won't crash. But that doesn't mean all the efforts made to approach such a guarantee are pointless or doomed. The faults that result in an accident steadily get rarer and weirder.

Some have suggested that proofs could be constructed to prove @safe is correct in all cases. It's a good idea, but I have no idea how to construct such a proof, nor do I have any idea how to show that the proof itself covers every issue. The proof would inevitably be as complex as D itself is, putting this right back where we are now.

Criticism of @safe would be much more damning if using it caused unsafe behavior, but I am unaware of any such bugs.

Note also that the whole point of dip1000 is expanding the coverage of @safe.

On 8/23/2018 6:22 AM, Shachar Shemesh wrote:
> (we used to file bugs in Bugzilla. We stopped doing that because we saw nothing happens with them)

Quite a number of Weka filed bugs have been fixed.

Here's the 2.080 list of 46 bugs fixed:

https://dlang.org/changelog/2.080.0.html#bugfix-list

The ones that don't get fixed are the ones not posted to Bugzilla. This is true of every major language I know of. Furthermore, *anyone* with a mind to can fix any bug and post a PR for it.

On 8/23/2018 9:22 AM, Shachar Shemesh wrote:
> So telling me to keep filing them is simply a non-starter. I've got bugs that simply don't reproduce in watered down examples. I will not spend two days just to create a test case that demonstrates the bug outside the Weka code base. If nothing else, my boss won't allow me to spend that time.

In my experience with debugging code, if drilling down to find the cause of the problem is not done, there is no way to conclude whether whether it is a compiler bug or a user bug.

(Of course, compiler internal errors are always compiler bugs.)

Drilling down and finding it to be a compiler problem also usually suggests a practical workaround for it.

On Thursday, 23 August 2018 at 07:27:56 UTC, JN wrote:
> On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
>> 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.
>
> I think a large part is defining what kind of users D wants to attract. There are two main groups of programmers, and there is a vast rift between those groups. One group is people who are closer to OOP programming and languages such as Java, C#, Javascript. These people are OK with things like garbage collectors and in cases where it matters, have learned to work around it (avoid allocations in hot loops, etc.). I feel like D1 was attractive for these people for having the convenience they are used to from their languages (batteries included standard library, automatic memory management), with additional features that their language/environments struggle with (C interop, native binaries), everything packed
> with a very clean syntax.
>
> The second group are the C/C++ programmers, the 'zero cost abstraction' group. For this group of programmers, any overhead is a disadvantage, garbage collector is unusable for most usecases (whether true or not, that's the perception). D1 appealed to those people, for having a clean syntax and the features they know without having to include the monster that is Boost. Battlefield was different back then too. Around D2 came the competition, be it Rust, Go, or C++17. Go is appealing more to the first group of programmers, since it has a GC, and mostly sticks to webservice usage. Rust is heavily appealing to the zero-cost abstraction group and C++17 obviously appeals to C++ folks.
>
> Is it possible to make a language that both groups would be happy to use? Perhaps, or perhaps the gap is too wide. Is adding features like dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there are features that aren't really used, and should be reworked or cut from the language instead (has anyone ever used contracts?).
>
> D's not UNIX (DNU?), but the first rule of UNIX philosophy is "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features'.". It may or may not be relevant here.
>
>
> BTW. on the offtopic note - the thread title doesn't look too good. Imagine being a newcomer, and the first thread you see on the forum is titled "D is dead".

Not sure about your taxonomy.  There are quite a few people involved in D who are native code C/C++ developers spiritually and by prior work focus who moved to D and don't mind, in fact maybe relish the GC.  One might include Walter and Andrei in this. I don't want to speak for Atila but I would like to see his face if you tell him that he is deep down a Java programmer at heart, as I don't believe that's quite right.  I don't think he despises the GC even though he has written libraries that make it easier not to use it.

It's silly to think that languages are in a death match competition against each other in some zero-sum game because there's no justification for it.  There have never been so many programmers in the world as today, and in twenty years i doubt there will be fewer.  There have also never been as many practitioners who write code as part of their job doing something else as today.  Furthermore the amount of code written depends on the extent to which one can express ones ideas efficiently in code.  I personally would have programmed much less since 2014 if I had to write in a language I didn't find agreeable, and I would have hired fewer programmers too - quite a lot of code exists now that simply wouldn't exist without D.

How can you possibly form an opinion on the different sorts of programmer ?  Most programmers aren't active on social media and don't work for companies that talk in public about their work.

Go for example just isn't a relevant alternative to what I am doing except perhaps for DevOps.  It solves a different kind of problem and is intended to be used by a different sort of person - Google hire a lot of programmers without much experience and have to find a way to get useful work out off them.  That's different from my own challenges.

For me the relevant alternatives might be Julia and Python.  And even then they aren't very close substitutes.

Implicitly D is even a competitor for VBA because our little DSL written in D solves many of the problems VBA and Excel are used for in a much better way.  One could have done that in many other languages too, but it is in D because it was originally written for another purpose and turns out it solves this problem too.

There's a chap here with a family business where its PHP versus D.

For Bastian it was a modern Pascal dialect Vs D versus Ada.

Most code is written in business and academe.  The beautiful thing about being up and coming is you don't need to take on the contender.  You just need to find a few more adherents from divers sources.  It's absolutely by no means what you want to be thought of as a threat until it's too late.  You want most people to write you off whilst having a very high appeal to those to whom you do appeal.

Does D have a very high appeal to certain kinds of programmer?  "So I can work from home and write D?  Sounds good, when should I start?".  Another guy. "What are your compensation expectations?" "I earn X but if it's working in D then we can talk about it - I could take a pay cut".  These aren't callow youth filled with unrealistic ideas about what it's like to be a programmer or what it's like working in D.

I think the niche of D is defined differently from conventional categories that people have come up with.  It's especially suited to some domains yes (these happen to be rapidly growing domains - they should make an ETF based on the share prices of companies using D if only they were public) but I think the appeal is based on values, taste and virtues.  As regards the latter you have to be able to endure a bit of discomfort to get very far with D.  So for what I am doing personally the very things that people grumble about on Reddit are net positives for me.  I need people who know how to learn and can figure things out without being instructed step by step what to do.

Many businesses are quite different from each other, particularly SMEs that create the jobs.  Even in my little part of the world there's a massive difference between companies in the sector and they do things in quite different ways because they have different problems, goals and people.

The world of social media is a very different place from the world of principals making decisions about how to solve their business challenges.  And I tell you that faced with an understanding of these problems the same people that might write on media about the problems of D may have a different assessment when it comes to the practical question of whether D is indeed a good answer to the practical commercial problem you face.

It's very hard to generalise.  If one is in the business of making predictions one ought to make them concrete and back them with money as a wager.  Otherwise it's just talk.  And beyond talk I don't think concrete actions are more interesting.  In open source more even than business sometimes problems are also opportunities and it's not deluded happy talk to suggest there's some benefit in trying to be the change in the world that you wish to see.

On 8/23/2018 11:29 AM, Steven Schveighoffer wrote:
> What this simply means is your identification of the problem is simply wrong -- it's not that you can't make subtypes with structs (you can), it's that you can't accept rvalues by reference, and accepting by reference is required for inheritance.

You're quite right that correct identification of the problem is critical before designing a solution.

On 8/23/2018 9:19 AM, Jonathan M Davis wrote:
> D was designed to have RAII, and it does. It's just that the implementation
> is buggy (which is obviously a serious problem), so depending on what your
> program is doing, it's not going to work correctly. It's not like we opted
> to not have RAII in D, and I'm sure that it will be fixed at some point. So,
> while it can certainly be argued that we've dropped the ball by not getting
> it fully fixed by now, I don't really see how it could be termed a missed
> opportunity.

As far as I know, the only known bug in RAII is https://issues.dlang.org/show_bug.cgi?id=14246 where constructors are not properly unwinding partially constructed objects.

My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over.

(Having throwing destructors is even worse, it's just madness. Although it is allowed in C++, it doesn't actually work.)

My personal opinion aside, it is a feature in D, and should work correctly, and is a serious issue for those that use throwing constructors. (It's not a disaster, though, as scope(failure) can be used to work around it.)

On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote:
> My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over.

Throwing constructors are fundamental for making RAII work in a composable fashion.

If constructors are not allowed to throw and you want to avoid manually creating a "uninitialized" state – which is error-prone and defeats much of the point of an RAII strategy –, all dependencies need to be injected externally, that is, constructed independently and then passed into the constructor. Sometimes, inversion of control is of course the right call – cf. the hype around DI –, but sometimes you'd rather cleanly abstract the implementation details away.

Banning them from the language only pushes the complexity of handling semi-constructed objects into ad-hoc user code solutions, which I'd argue is worse in terms of usability and potential for bugs.

I suppose you view this as advantageous because you place more weight on the language not having to explicitly deal with this scenario in the text of the specification?

 — David