On Thursday, 21 December 2023 at 12:29:25 UTC, Mike Parker wrote:
> Alright, this is getting out of hand.

It has been out of hand for *years*. Nice that you're finally recognizing it, too late for several quality contributors. Not too late for me....yet.

Phobos had a big inrush of development many years ago, but since then it has been a trickle, leaving wide gaps in functionality and questionable design that everyone agrees should be changed, yet it remains entrenched. Sure, some nice things are added, some bugs fixed, but they are few and far between. Is this because of a lack of people power? No! There's lots of people willing, some even *eager* to contribute to Phobos, but they are instead turned away or given contradictory requirements that are impossible to fulfill even with a million dollar budget, and certainly not going to happen with volunteer time.

The state of D documentation is still a mess - the official website still has two versions of the docs, both of which are broken in their own ways, and it has been.... i think about 9 years now just sitting like that. The bugs in ddox have never been fixed, the decision to transition just sitting in limbo. Is this because of a lack of people power? No! I cared enough to fix it myself 7 years ago. Spent about a hundred hours over my Christmas break doing it. Got rejected with a message where they openly admitted they didn't bother looking at it.

Language bugs and features that have been in popular demand for ages sit unmerged. Is this because of a lack of people power? No! The discussions have been had, the code written. All the dictator has to do is lift his arbitrary holds and let the PR manager click the green button. Instead, more red tape gets added to the tangle until the ongoing time commitment to keep rebasing the PRs is proven to be a sunk cost fallacy, throwing good time after bad, and the contributors quit trying.

This has been the pattern repeated, over and over again, since before I joined the D. Remember Tango?

Insomuch as there is a lack of people power, it is the *result* of D's dysfunctional development, not the cause.

With all the talk about IVY and reformation this year, I really hoped things would be different.

Well, the year isn't over yet. There might still be hope.

> So, let's be clear, Adam isn't being ignored here. Walter is going to review the spec once Atila finishes it. And then he will make a decision on it.

The problem is that the entire D community is help up because one stubborn fool is held up by the rest of you as a "dictator".

> I'm sorry that Adam feels it isn't happening fast enough, but his string interpolation implementation is not the only thing that needs attention right now. It's going to get a fair shake, even if it doesn't happen as quickly as he or anyone else would like.

It would take about five seconds to click the button and move on to the next issue. Don't pretend this is some necessary process imposed by God that must be followed to the letter. You all are *choosing* to waste gobs of multiple people's time over an arbitrary hold.

You could choose instead to ... just not do that.

On Thursday, 21 December 2023 at 12:29:25 UTC, Mike Parker wrote:
> On Thursday, 21 December 2023 at 10:59:29 UTC, DrDread wrote:
>> [...]
>
> Alright, this is getting out of hand. Walter asked for a spec so he could fully grasp the implementation, and Adam refused to write it. Atila volunteered to do so. He explained he was going on vacation for a few weeks and would get to it when he got back. He got back, got caught up on work, and has since been working to write the spec from Adam's implementation.
>
> [...]

Is a spec required when submitting a feature?


Looks like it a lot of work. Must it be done initially even when the implementation will likely be rejected?

On 12/21/2023 7:13 AM, Siarhei Siamashka wrote:
> Its main selling point is the compilation speed. However the out-of-the-box performance of `rdmd helloworld.d` is very far from perfect and looks inferior compared to `go run helloworld.go`. 

It's a good point. One of the likely suspects is object.d. It started out as a small, single file. But it has bloated up to biblical proportions, which have to be compiled by every separately compiled D module. (If all the modules to a project are presented on the same command line, object.d only gets compiled once, and that effort is amortized over the other modules.)

For example, object.d has unit tests in it. Unit tests are a great feature of D, but there they are in the wrong place. object.d should be split into object.d and object.di. The unit tests and definitions go in object.d, the declarations go in object.di.

Another culprit is writefln(). For all its faults, printf() is compact, fast, does not allocate memory, and:

```
extern (C) pragma(printf) int printf(const(char)* format, ...);
```

If anyone wants to pick up the flag on this,
https://issues.dlang.org/show_bug.cgi?id=24296

is all the compiler needs to see to use it. writefln() is anything but. We can do better.

Another problem is nobody ever profiles dmd anymore. There are no instructions in build.d in how to run the profiler.

On 12/21/2023 2:59 AM, DrDread wrote:
> It really was not unclear. but you are missing the point here.
> it doesn't matter if it was or wasn't unclear, we are losing contributors because of this whole attitude.
> there an implementation now so you cannot misunderstand it. people are running their own compiler fork because it's too much pain to get anything into dmd.
> and you refuse to just look at the implementation and insist on having a specification again, but people are doing this in their free time, and are annoyed their work is constantly getting dismissed.
> 
> that'S why i said, if you really want to insist on a spec getting written, please just go and ask the D language foundation to pay adam to write one. or we will just again lose all the good work and probably more contributors.
> 
> we need a change to attract contributors.

Every organized and professional product I know of requires a specification to come with every formal proposal for a language change.

There are excellent reasons for that. It works to do it this way.

For example, consider Python Enhancement Proposals:

https://peps.python.org/pep-0001/#what-belongs-in-a-successful-pep

"Specification – The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for at least the current major Python platforms (CPython, Jython, IronPython, PyPy)."

On Thursday, 21 December 2023 at 23:04:30 UTC, Walter Bright wrote:
> It's a good point. One of the likely suspects is object.d.

object.d is not significantly to blame.

First, important to establish a baseline. Just make an empty file and compile it:

$ time dmd -c empty

real    0m0.011s

Even if you brought the import time of object.d to absolute zero, you'd have *at most* 10ms to gain from it. This is less than 5% of the test times.

Even if you do a compile and link:

$ time dmd empty -main

real    0m0.163s

Most this time is spent in the linker, not the compiler. druntime's pre-compiled lib could potentially be smaller to reduce link times, but changing object.d will do very little for this.

> have to be compiled by every separately compiled D module.

Secondly, even if it were true that object.d were to blame, this would be an incorrect path. object.d is never *compiled*, it is merely imported.

Which means:

> For example, object.d has unit tests in it.

This is irrelevant. The unit tests are skipped with extreme rapidity. So are function bodies. The things the .di process strips out are already automatically skipped by the existing import process!

I went into more detail recently here:
http://dpldocs.info/this-week-in-d/Blog.Posted_2023_10_09.html#ctfe-caching

> Another culprit is writefln(). For all its faults, printf() is compact, fast, does not allocate memory, and:

This is a more fruitful line of attack, but anyone looking into this, remember to be empirically driven. Test your assumptions - you'll probably be surprised at what actually makes a difference.

> Another problem is nobody ever profiles dmd anymore. There are no instructions in build.d in how to run the profiler.

...but as you collect data, make sure it doesn't lead you astray. I remember when the dmd profiler said freeing memory was a significant cost, so everyone just stopped trying. Memory usage ballooned... and there was no actual impact on speed in the real world, because it turns out the specific `free()` implementation in the profile had a bug that no other implementation shared. Simply building dmd with the ldc compiler and using the Microsoft and GNU  C libraries completely erased that difference.

On 12/21/2023 9:14 AM, aberba wrote:
> Is a spec required when submitting a feature?

Yes, unless it is trivial.

> Looks like it a lot of work.

They're not that much work, they're certainly a lot easier than an implementation.

> Must it be done initially even when the implementation will likely be rejected?

It is normal for organized language communities to require a spec for any language changes. I'm not aware of any that don't.

On Thursday, 21 December 2023 at 17:14:32 UTC, aberba wrote:
> Is a spec required when submitting a feature?

Well, it defines how you define "spec". Like I said earlier in this thread, I *did*, in fact, write several different explanations, including ddoc intended for users to understand:

https://github.com/dlang/dmd/pull/15715/files#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1

There's also several examples of what is and isn't supposed to work:

what isn't supposed to work:
https://github.com/dlang/dmd/pull/15715/files#diff-31ab43241663a2bcdd12070866771b2018119e8d53db31ce8be4b7b4fe43b11c

what is supposed to work, including some specific edge cases:
https://github.com/dlang/dmd/pull/15715/files#diff-4f34bcd1d367aaf71ec21d197bb1f9fa43020ffa76e189633fe60a8e9d315b82

You're fairly new to this discussion... can you understand the feature from those links?

On 22/12/2023 12:04 PM, Walter Bright wrote:
> On 12/21/2023 7:13 AM, Siarhei Siamashka wrote:
>> Its main selling point is the compilation speed. However the out-of-the-box performance of `rdmd helloworld.d` is very far from perfect and looks inferior compared to `go run helloworld.go`. 
> 
> It's a good point. One of the likely suspects is object.d. It started out as a small, single file. But it has bloated up to biblical proportions, which have to be compiled by every separately compiled D module. (If all the modules to a project are presented on the same command line, object.d only gets compiled once, and that effort is amortized over the other modules.)
> 
> For example, object.d has unit tests in it. Unit tests are a great feature of D, but there they are in the wrong place. object.d should be split into object.d and object.di. The unit tests and definitions go in object.d, the declarations go in object.di.

I want to see a significant chunk of object.d removed.

I have a proposal on how to proceed on this, I have already talked with Adam Wilson about it, so even if you don't hear from me directly you'll hear from him about it ;)

This isn't just for speeding imports up, it will also help custom druntime implementers quite significantly (as in, they'll stop complaining entirely).