On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
> On Thu, Jan 18, 2024 at 02:02:56PM +0000, Dibyendu Majumdar via Digitalmars-d wrote: [...]
>> It only proves my point, because the only people not nice on these forums are these so called contributors, many of who actually have made no contribution but are happy to make a lot of demands as if its their right!
>
> That's irrelevant.  Some of the people who left recently were *very* active contributors, who have had a lot of work merged and who did a lot of user support on their own free time.  We're not talking here about the regular whiners who show up out of nowhere with strange or unreasonable demands ...

while not
> lifting a finger themselves. (Personally I just hit the delete button for those, it's not worth my time.)

how do you know even those folks aren't contributors financially and other means? Would be a mistake to assess complaints based on such credentials.

Walter has a saying that people complain because they have interest in the language and care about it. I think that's a very positive way to look at it.

I unsubscribed from this forum, since I find it to make me angry and not lead anywhere productive, but people linked me to this so I'll give one more reply to set the record straight.

There's a ST:TNG scene that comes to mind relating to all this:

https://www.youtube.com/watch?v=Owyj_5TuHQw

"It's not you I hate, Cardassian. I hate what I became because of you."

I used to be nice to people online. I used to not cuss online. I kinda miss the old me.

On Thursday, 18 January 2024 at 16:31:11 UTC, Mike Parker wrote:
> Adam was unhappy that Walter wanted a spec, so Atila agreed to put the editions proposal on hold to get it done (and please, let's not rehash the argument about reading code vs. writing specs).

It was never about reading code vs writing specs. Let's review the facts.

I published an implementation *in an effort to clarify an existing spec* - implementing the YAIDIP as written by John Colvin and Andrei Alexandrescu, which is an evolution of DIP1027 - on October 19th. https://github.com/dlang/dmd/pull/15714

In the process of working with that implementation, I found flaws in the design (in particular, it was incapable of handling tuple arguments, which includes nested strings, because they threw off the odd-even rule specified) and fixed them in a separate branch on October 20th (note that there are other potential ways to fix this issue, but since this was already a solution we debated and found working during the original dip1036 review, I stuck with it - that's why the PR is called "1036e", since it built on those existing principles). https://github.com/dlang/dmd/pull/15715

Note that DIP1036 was written primarily between September 2020 and March 2021. This is not a new topic, many of us have spent a significant amount of time on the topic over a period of many years. https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

There are, of course, several differences between the PR and the original dip1036 (whereas PR 15714 kept quite strictly to the YAIDIP's text), but we'll get to those soon.

So, remember, the code was written on October 20th.

To better show how the feature works in practice, I wrote the first of several user-facing examples on October 21st. https://github.com/adamdruppe/interpolation-examples/commit/ca4441508c9726519e769184cc7314fc0bf146b7

On October 23rd, Walter stated that the PR "Lacks 1: complete and accurate specification, or even a description. 2: comments. 3: test cases". https://github.com/dlang/dmd/pull/15715#pullrequestreview-1693080343

(Frankly, I think that very request is obnoxious, because on October 22nd, Walter posted his dip1027 implementation. I've said before that him doing this is a real slap in the face of the whole DIP process - his DIP was reviewed and rejected. He's been beating that dead horse for many, many years, never incorporating... or even *acknowledging* the feedback from reviewers. You probably recall my listing the receipts for this on New Year's Eve.

But nevertheless, compare the first draft of PR 15722 with the first draft of PR 15715. They're very similar, down to the semantic function both using the same `new MixinExp` hack (well, I thought it was a hack, until I saw Walter did it the same way, so apparently he thought it was a decent way to do it!). So I found it difficult to believe he was simultaneously capable of writing one implementation and incapable of understanding an independent, yet *very similar* implementation. Even if there were questions, he surely has significant foundation to ask them specifically and engage in a productive dialog. But instead, it was a vague drop and run. This is why there's an "us vs them" mentality - Walter acts not like a partner for peace, but rather as an obstacle to overcome. The DIP process structurally reinforces this - he is like the final boss to defeat after a grueling gauntlet to get to the prize.)

However, despite my skepticism, on October 24th, I started fulfilling that request, adding the first tests, which also double as basic documentation and examples on the compiler side, showing some specific edge cases that differentiate it from the original dip1036 text. https://github.com/dlang/dmd/commit/75f6f326695b5354c9ffb38ed4ec47b057881549

Additionally, on October 24th, I edited the first comment on the PR to incorporate a plain text description (similar in style to Walter's 1027 PR's introduction). (Click the "edited" drop down on the comment on Github to see the history with dates attached. Note that at the time Walter made the request, the plain text description was indeed not there. But shortly after he requested it, I edited it in to be easy to find.)

I added additional documentation, both comments on the implementation, more tests for specific edge cases that needed clarification, and VERY IMPORTANTLY a full user-facing documentation page on *October 26th*. https://github.com/dlang/dmd/commit/2ff8e2d1598d4b2cd581320095f526c8547c2c46#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1

I've posted this link several times, and never got an acknowledgement from any of you that it exists.

Click that. Check the date on it. Read the contents on it. This is NOT code one has to reverse engineer. This is a description, written up as a standard D documentation block, for users to understand how the feature works.

Again, THIS IS NOT ASKING SOMEONE TO REVERSE ENGINEER THE CODE nor is it true that I refused to write documentation. There ARE examples, tests, comments, and two plain text descriptions, one aimed at the code reviewer and one aimed at the end user.

This is the #1 thing driving me nuts about this whole thing. Walter requested a description on Monday, October 23rd. I answered that request by *Thursday, October 26th*. The examples and documentation I wrote over those three days form a significant fraction of Atila's DIP text! <https://github.com/atilaneves/DIPs/blob/string-interpolation/Interpolation.md> (This dip was mostly written between December 18th and present day.)

Then, when we were on the DLF call on November 10th, more than two weeks AFTER I had *already written the requested documentation*, Walter again demanded a nebulous "spec" instead of engaging with the work that was already done.

I'd say "you have no idea how angry this makes me", but you were on that call. You certainly have some idea of how angry it makes me.

Now, I confess, my kneejerk reaction on that call, the sudden outburst of anger, was not an ideal response. I'm ashamed of the angry outburst. It surprised even myself. I was otherwise prepared with the documentation and examples written, but I was evidently not emotionally prepared.

Nevertheless, can we please, PLEASE, finally acknowledge the *verifiable fact* that I did NOT refuse to write documentation, but rather quite the contrary, actually *did* write the requested documentation within 72 hours of receiving the request.

If you all have a specific problem with this, you never communicated what it is. Do you (plural you, not you specifically, Mike) just not know it exists? Do you find the formatting unacceptable? The content insufficient? If so, in what way?

I'm actually inclined to think it you all honestly don't even know it is there. This would be consistent with many other cases where leadership made a request, the request was fulfilled, then silence. There's little follow-up.

You might notice that on those DLF calls, I prepared ahead of time for each one, starting with follow up on old business, then introducing new business. I kept the notes from the previous meeting and checked the links ahead of time so I could see what was done and what still needed to be done.

I suggest you do the same. But not just with meetings. Do it with any time - when you request something, put a note on your calendar to follow up on it some time later. In fact, it is best to communicate your schedule to the person you're requesting, such as "This needs documentation and test. I will check back in on Friday."

That's actually one useful bit of deadlines: they're a good time to schedule the follow up. Look back at the original request and see if it was done. E.g., reload the pull request page and glance it over for new pushes, then you can talk to the person you requested the work out of, knowledgeable of what was done to keep the conversation on topic and productive.

IIRC this was the key feature of the DIP redesign back when Dicebot proposed it - the old dips, before dip1000, were often left in limbo. The new process, with you taking up the role as dip manager, included various steps and timeframes to ensure something happened.

The new DIP process has also failed - i think the us-vs-them structure, frontloading the grinding work just to have it dismissed or misunderstood in an adversarial battle instead of refined in a cooperative, iterative process is the key to why - but ensuring you do get an answer in a predictable timetable is a good idea.


Anyway, I'm going back off this forum too. I have better things to do than argue in circles again as well.

On Fri, Jan 19, 2024 at 12:17:13AM +0000, aberba via Digitalmars-d wrote:
> On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
> > On Thu, Jan 18, 2024 at 02:02:56PM +0000, Dibyendu Majumdar via Digitalmars-d wrote: [...]
> > > It only proves my point, because the only people not nice on these forums are these so called contributors, many of who actually have made no contribution but are happy to make a lot of demands as if its their right!
> > 
> > That's irrelevant.  Some of the people who left recently were *very* active contributors, who have had a lot of work merged and who did a lot of user support on their own free time.  We're not talking here about the regular whiners who show up out of nowhere with strange or unreasonable demands ...  while not lifting a finger themselves. (Personally I just hit the delete button for those, it's not worth my time.)
> 
> how do you know even those folks aren't contributors financially and other means? Would be a mistake to assess complaints based on such credentials.

I said specifically I was *not* talking about them. :-D

The "regular whiners" I was referring to are those who show up out of nowhere and start asking "does D have X, Y, Z?" and then proceed to whine "why is X like this? It should be more like X2!  And Y should be more like Y2! And Z shouldn't even exist!  D sux, fix it or I'm leaving!"


> Walter has a saying that people complain because they have interest in the language and care about it. I think that's a very positive way to look at it.

Well, that's why I'm still here and complaining. :-D  Or at least, I try to post positive things about D when I can... but sometimes when you've been around for a long time and seen things, it's hard not to voice problems that you feel should have been obvious to everyone but for some reason aren't. (Or so it appears.)


T

-- 
The best compiler is between your ears. -- Michael Abrash

On 1/18/2024 1:49 AM, GrimMaple wrote:
> Funny thing is, DMD is super easy to build on Windows. You just have to somehow figure out to `rdmd build.d` in the `compiler` directory and then it's all good. Phobos/Druntime on the other hand simply cannot be built on windows, because instructions tell you to use `make` that "comes with dmd`, and it just doesn't :)

The instructions are on a wiki - anyone can fix it.

https://wiki.dlang.org/Building_under_Windows

https://issues.dlang.org/show_bug.cgi?id=24347

Andrei left us years ago. Complaining about him is pointless.

Andrei is a first rate programmer. If he says some work is not good enough, asking him "why" and "how can I make it good enough" is a much more worthwhile reaction than getting angry and leaving.

I know I've told some contributors their work isn't good enough, and tried to explain why. Some have, as a result, greatly improved the quality of their contributions. Some have gotten angry and left.

I don't miss the latter.

All of us can improve our code, and should be willing to objectively consider suggestions for improvement. My talk at DConf2023 was all about my own discoveries on how to write better code. Those who watch my PRs will see a continual progression on implementing them.

When I was in my 20s, I thought the code I wrote was god's gift to the world. The very idea is laughable to me now.

DMD/Phobos/etc is a large, complex project. We simply cannot afford to accept low quality contributions, as the project will become unmaintainable. Anyone should be proud when their contributions meet our high standards. We're willing to help those who do not get better - but if they don't want help, I'm sorry about that, but that's the way it goes.

Note that I am *not* saying that everyone who has left has left for that reason. There have been many reasons.

People leave for many reasons. Often their situation and interests change, and they move on, just like the employees of any company. I'm glad they were here when they were, and wish them well in their next endeavor.

Of course, we also have several "lifers", which are great!

BTW, I do not accept any compensation from the DLF, and pay my own way to the conferences.

On Sunday, 21 January 2024 at 12:35:53 UTC, Dom DiSc wrote:
> ...
> Oh please.
> Everybody submitting a PR can easily run dfmt on it. This done there should be no more "too long lines", "multiple expressions in one line", "not correct indented code", "curly braces not on their own line", etc. pp.
> If someone submit PRs without running dfmt, (s)he should be advised to do so. End of discussion.
> ...

I always thought that the code should be accompanying with a style file (Or markup?), something like HTML and CSS, and each one could defined the style they are pleased, for example I prefer curly braces on their on line, like 1TBS/OTBS style, and sometimes for _simple_ things I do prefer multiple expressions in one line.

Matheus.