On Saturday, 24 November 2018 at 17:43:05 UTC, bachmeier wrote:
> I think the problem with D is that the work that needs to be done is not clearly defined, you don't get credit in any way, and even if you do it, there's no reason to think you've done it "right", so it might all be for nothing. If you can fix those three things, you might be able to get people to contribute to things they don't care about.
That is a good observation. D would benefit if some one implemented systems from video games. Games are really good at defining goals, guiding players toward achieving them, tracking progress and rewarding them at any small improvement. The problem is that people in D community are developers not psychologist. Second problem is that implementing such systems require work and we already have too many tasks that need to be done.

On Saturday, 24 November 2018 at 17:09:08 UTC, H. S. Teoh wrote:
> On Sat, Nov 24, 2018 at 04:46:02PM +0000, welkam via Digitalmars-d wrote:
>> On Saturday, 24 November 2018 at 15:19:26 UTC, Chris wrote:
> [...]
>> > Basic and important things seem to be at the bottom of the list (XML
>> > parser)
>> there was attempt on rewriting xml module but it never crossed finish line.  Its from Aug 22, 2016 https://github.com/dlang/phobos/pull/4741
> [...]
>
> Actually, if you're interested in XML, you should check out Jonathan Davis' dxml module:
>
>> Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
>> Github: https://github.com/jmdavis/dxml/tree/v0.2.0
>> Dub: http://code.dlang.org/packages/dxml
>
> It doesn't handle DTDs due to design constraints, but if you can live with that, it should work much better than std.xml.
>
> (I'm hoping Jonathan pushes for this to be merged into Phobos, as it's far superior to std.xml IMO. But that has yet to happen.)
>
>
> T

You didnt knew but I watched almost all Dconf videos, all Andrei and Walter presentations on D and I know about Jonathan`s work. I just wanted to refute that people dont care about rewriting xml

On Saturday, 24 November 2018 at 16:26:43 UTC, H. S. Teoh wrote:
> On Sat, Nov 24, 2018 at 10:25:23AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> 4. The longer we wait, the worse it will be.
>> 
>> There is no way to fix autodecoding without breaking code. So we have to make that sacrifice to make progress. The most painful thing I think would be a possible deprecation path where you have to be explicit about how you want things decoded in order to avoid messages.
> [...]
>
> This isn't actually as bad as it sounds. Just make strings non-ranges (temporarily), and require .byCodePoint or .byCodeUnit for iteration. Then once the deprecation cycle is over and autodecoding is no more, allow strings as ranges again. It will be painful, yes, but painful is better than silent subtle breakage that nobody knows until it explodes in the customer's face.

I'm also on the side of depreciating of autodecoding. It's a significant deficit for systems doing high performance string manipulation. This is unfortunate, as otherwise D has many nice facilities for these applications. I'd be happy to provide additional feedback on this topic, as this an application area where I have experience.

--Jon

On 11/24/2018 6:52 AM, Chris wrote:
> On Friday, 23 November 2018 at 23:49:16 UTC, Walter Bright wrote:
>> On 11/23/2018 4:59 AM, Chris wrote:
> 
> 
>> Fixing autodecode will break about everything. But you don't like breaking changes.
>>
>> What do you suggest?
> 
> If you put it this way, as you tend to, of course, I look like a lunatic. The breaking changes I don't like (and no-one does) are changes that seem completely random to the user. Normal, "innocent" code just breaks.

Your last statement will come true if autodecode is removed.

I'm not saying you're wrong, but I've been bombarded with messages for 15 years that consist of:

1. stop doing enhancements, just fix bugs
2. add in my favorite enhancement

1. don't break existing code
2. add in my favorite enhancement that breaks existing code

usually in the same message from the same person.


> But autodecode is not even open for discussion anymore.

It is open. Nobody has shut down discussion of it. The trouble is nobody yet has come up with a reasonable migration path that doesn't result in normal, innocent code silently breaking.

BTW, you can defeat autodecode for your own programs by using the .byChar filter:

https://dlang.org/phobos/std_utf.html#byChar

On 11/24/2018 7:19 AM, Chris wrote:
> Of course you cannot do everything alone. I never expected that. But ARM was never really high on the agenda.

It cannot be high on the agenda without a self-motivated, competent person to work on it.


> But it is essential enough that it should have gotten a higher priority than just to wait until someone stepped up.

I have a lot of history with people asking me "what can I work on?" I give them a list of suggestions, and they work on something not on that list, i.e. what they want to work on.

The D community is a volunteer one. I cannot order anyone to work on anything.

For example, you can step up and work to improve any aspect of D that matters to you.


> I see a lot of other things happening like the re-implementation of the D compiler in D. Fine. But do I as a user really care if it's written in D or C++?

Not directly, no. But there are a number of problems working on that code due to it being half in D, half in C++, such as:

1. C/C++ is just a clumsy language to work in when one is used to D.
2. Half in one language, half in the other, means you have to main two sets of declarations of the data structures, and there's hell to pay if they get out of sync.
3. There's lots of technical debt in the old backend. Redoing it in D makes that a lot easier to improve.
4. I don't have to deal with C/C++'s portability problems when it's in D. I've spent a stupid amount of time just dealing with size_t.


> I don't understand how things are prioritized in D. Basic and important things seem to be at the bottom of the list (XML parser), other things get huge attention while they are of dubious value to many users. This is why I don't completely buy the "we don't have enough resources" argument. The scarce resources you have are not used wisely in my opinion. And it is a pity when I see that D has loads of potential (C/C++ interop, Objective-C interop etc.) but other new languages overtake D because they focus on practical issues too.

It's fairly straightforward. Things that get attention do so because a self-motivated and competent person decides to solve it. Commercial organizations that rely on D tend to spend money solving their problems with D, not others. The D Foundation does have some money to spend, but you may not realize just how much a competent compiler engineer costs!

On Sunday, 25 November 2018 at 06:56:10 UTC, Walter Bright wrote:
> On 11/24/2018 7:19 AM, Chris wrote:
>> Of course you cannot do everything alone. I never expected that. But ARM was never really high on the agenda.
>
> It cannot be high on the agenda without a self-motivated, competent person to work on it.
>
>
>> But it is essential enough that it should have gotten a higher priority than just to wait until someone stepped up.
>
> I have a lot of history with people asking me "what can I work on?" I give them a list of suggestions, and they work on something not on that list, i.e. what they want to work on.
>
> The D community is a volunteer one. I cannot order anyone to work on anything.

Sure, you don't have that hard power but you have plenty of soft power, which you don't seem to be using well:

https://en.m.wikipedia.org/wiki/Soft_power

Two big communication mistakes I've seen from you and Andrei that I've been banging on for years now, which I think others are also alluding to:

1. Little to no clear communication on what the roadmap moving forward is, though the Vision statements have filled that gap somewhat. Of course, they seem to have stopped right when they were getting useful and less vague.

You're right that many will just disregard your roadmap, but this ignores that there are others who are simply looking for a way to pitch in, like junior devs, and will gladly pick off something on a list you make. But this is why it's important to provide concrete tasks, rather than vague goals like "improve safety," so they can dive in easily.

2. Little notice of what you two are actually working on now, PRs often just show up out of the blue. This precludes others from either avoiding doing that work because you're already doing it, or pitching in to help you out. Presumably you two have some kind of TODO list that you could just share publicly?

Another possibility in this vein is putting together a list of things you either don't want or would like to see in the language, like Swift's list of commonly rejected changes:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

This is actually the hard power you do have, as the gatekeepers for dmd and Phobos.

I understand that as an engineer this may all seem unnecessary overhead, but if this project is ever to scale beyond where it's at now, it will have to be done.

On Sunday, 25 November 2018 at 04:23:37 UTC, Walter Bright wrote:
> On 11/24/2018 6:52 AM, Chris wrote:
>
> Your last statement will come true if autodecode is removed.


> I'm not saying you're wrong, but I've been bombarded with messages for 15 years that consist of:
>
> 1. stop doing enhancements, just fix bugs
> 2. add in my favorite enhancement
>
> 1. don't break existing code
> 2. add in my favorite enhancement that breaks existing code
>
> usually in the same message from the same person.

You're mixing apples and oranges again. `autodecode` is an important change. You and Andrei have had no problems with breaking valid code for less. You seem to be in complete denial about `autodecode`.

`autodecode` is not the same as a random request by a random user. `autodecode` is essential but you tend to conflate it with random stuff and argue as if it were a random issue, a pet feature. Ironically enough, a lot of random stuff and pet features get more attention / higher priority than basic issues like autodecode.

>
> > But autodecode is not even open for discussion anymore.
>
> It is open. Nobody has shut down discussion of it. The trouble is nobody yet has come up with a reasonable migration path that doesn't result in normal, innocent code silently breaking.

Well, this is not the impression I get. Several people have suggested migration paths, reasonable ones, there are people who want to help out (I used to be one of them), and yet the paths are not even discussed. All we hear is "It will break a lot of code, and isn't that what you wanted to avoid?" In every thread about aotudecode it becomes clear that people want to get rid of it, yet nothing is ever done. I've been vocal about this and other things, but how many more users are there that don't air their opinions but want to see some change?

> BTW, you can defeat autodecode for your own programs by using the .byChar filter:
>
> https://dlang.org/phobos/std_utf.html#byChar

Ordinary D code already has enough workarounds. Maybe this is something nobody ever brings up, but I've looked at vibe.d code and seen comments like "workaround for issue #1234", my own code has it and it often goes unnoticed because the fix takes so long that you simply forget about it, and when you finally see it you may not have the time to "fix the fix". It's not good for code hygiene.

On Saturday, 24 November 2018 at 18:02:59 UTC, welkam wrote:
> On Friday, 23 November 2018 at 23:49:16 UTC, Walter Bright wrote:
>> On 11/23/2018 4:59 AM, Chris wrote:
>>> Then there was the whole issue of string handling and autodecode and the way the leadership / big guys in the community dealt with it. I was of the opinion that such an essential issue had to be fixed immediately (of course with a proper path to fix it). I even offered to be the guinea pig and document the transition. But no.
>>> 
>>> Then there were the dreaded dmd updates. "Shit, what will break now?" this question would be my constant companion.
>> Fixing autodecode will break about everything. But you don't like breaking changes.
>>
>> What do you suggest?
>
> The real reason he is upset is because reality didnt match with his internal view(expectations). This creates anger, disturbance(dont know better words). Then "left brain" tries to come up with reasons to explain this feeling and thats what you get in his posts. Left brain coming up with reasons.
>
> People in neuroscience know for some time now that brain comes up with possible sounding explanations that are not the real reasons. Here are example from split brain. Talking about left explaining stuff start at 1:16
> https://www.youtube.com/watch?v=wfYbgdo8e-8
> Another example from Sam Harris. 19:55-20:10
> https://youtu.be/gfpq_CIFDjg?t=1195
>
> If you want these kinds of post to go away start managing expectation (almost impossible) or improve D (the thing you already doing)

You guys do realize that when he said "Then there were the dreaded dmd updates." he was talking about unexpected breakages right? Fixing autodecoding would be a very welcome and expected breaking change. These are not contradictory statements. Paraphrasing it as "Fixing autodecode will break about everything. But you don't like breaking changes." is just twisting his words.

On Sunday, 25 November 2018 at 06:56:10 UTC, Walter Bright wrote:
> On 11/24/2018 7:19 AM, Chris wrote:
>> Of course you cannot do everything alone. I never expected that. But ARM was never really high on the agenda.
>
> It cannot be high on the agenda without a self-motivated, competent person to work on it.
>
>
>> But it is essential enough that it should have gotten a higher priority than just to wait until someone stepped up.
>
> I have a lot of history with people asking me "what can I work on?" I give them a list of suggestions, and they work on something not on that list, i.e. what they want to work on.
>
> The D community is a volunteer one. I cannot order anyone to work on anything.
>
> For example, you can step up and work to improve any aspect of D that matters to you.
>
>
>> I see a lot of other things happening like the re-implementation of the D compiler in D. Fine. But do I as a user really care if it's written in D or C++?
>
> Not directly, no. But there are a number of problems working on that code due to it being half in D, half in C++, such as:
>
> 1. C/C++ is just a clumsy language to work in when one is used to D.
> 2. Half in one language, half in the other, means you have to main two sets of declarations of the data structures, and there's hell to pay if they get out of sync.
> 3. There's lots of technical debt in the old backend. Redoing it in D makes that a lot easier to improve.
> 4. I don't have to deal with C/C++'s portability problems when it's in D. I've spent a stupid amount of time just dealing with size_t.
>
>
>> I don't understand how things are prioritized in D. Basic and important things seem to be at the bottom of the list (XML parser), other things get huge attention while they are of dubious value to many users. This is why I don't completely buy the "we don't have enough resources" argument. The scarce resources you have are not used wisely in my opinion. And it is a pity when I see that D has loads of potential (C/C++ interop, Objective-C interop etc.) but other new languages overtake D because they focus on practical issues too.
>
> It's fairly straightforward. Things that get attention do so because a self-motivated and competent person decides to solve it. Commercial organizations that rely on D tend to spend money solving their problems with D, not others. The D Foundation does have some money to spend, but you may not realize just how much a competent compiler engineer costs!

Sorry, but D tends to D-motivate people. One example is std.xml. Another issue I've brought up over the years. You talk about highly motivated volunteers and when you get one what does s/he get? Review limbo for ever, because everything else is more important than that volunteer's work. Dip1000, the C++ > D transition, whatever. And when people ask about std.xml or any other work in limbo the answer is "The person didn't push hard enough!". That's cynical. How is that supposed to motivate anyone? Do you and Andrei sometimes think about how this sort of behavior is perceived by users? Believe me, it doesn't go unnoticed and it makes you think twice about contributing. It's normal psychology. And it's a rinse and repeat pattern in the D world.

Guess why - and this speaks volumes - Johnathan M. Davis couldn't be bothered to put dxml through a review process? Johnathan told us that he wasn't "too enthusiastic" about it. Why wasn't the new std.xml ever reviewed + accepted back in the day?

Contribute! You may not know, but D users are usually too busy finding workarounds for bugs, fixing broken code and coming up with their own solutions for basic things. I wrote a small XML parser for my own specific needs, because I couldn't wait anymore. We've kept your and our dream alive by working around difficulties ourselves in the hope that some day things would improve. But in vain.

On 26/11/2018 1:58 AM, Chris wrote:
> Guess why - and this speaks volumes - Johnathan M. Davis couldn't be bothered to put dxml through a review process? Johnathan told us that he wasn't "too enthusiastic" about it. Why wasn't the new std.xml ever reviewed + accepted back in the day?

If you're referring to std.experimental.xml, simple it was horrible code that wasn't complete and I did try to improve upon it. It just wasn't good D code. It wouldn't pass the review even if feature complete.