On Tuesday, 2 November 2021 at 11:51:07 UTC, Robert burner Schadek wrote:
> Because political therefore bad?

Depends on the long term outcome. If you solve a current-day political issue by adding technical debt then you probably found the less optimal solution and stuck to it because it looks easy. If this creates a culture for less design and more evolution, then that is bad, as long term stability is important.

For instance: "with this solution we can always change it later, so we don't really have to be certain about what we do" is a political strategy that is easy to sell, but is very costly long term.

On Tuesday, 2 November 2021 at 12:07:31 UTC, Ola Fosheim Grøstad wrote:
>
> For instance: "with this solution we can always change it later, so we don't really have to be certain about what we do" is a political strategy that is easy to sell, but is very costly long term.

I think here lies the fundamental need for leadership.

I would argue that with the PR, linked in this forum thread,
the set of D developers will be empty before we find out whether
this can be reverted without problem or not.

I also can not proof that my solution means less problems in the long run.
I can only make an argument for it.

This is where the "making a decision" by leadership comes in.

Now for the baiting, in the end I can only hope that leadership makes the
bold choice that actually gets us good ;-)
Because, I really don't want to have write C++ or rust for a living.

On Tuesday, 2 November 2021 at 12:07:31 UTC, Ola Fosheim Grøstad wrote:
> For instance: "with this solution we can always change it later, so we don't really have to be certain about what we do" is a political strategy that is easy to sell, but is very costly long term.

Huh? For me, it just comes out as trying to avoid the pitfalls of the waterfall model.

If a project wants to avoid needless politics and long-term costs, you probably are not saying it should go for waterfall in general.

So I think you're either saying that there is not much uncertainty about future in this particular case, or that the costs of getting it wrong are low even with an all-in approach? Or that D already has one leg in grave, so it's time for desperate moves?

On 11/2/21 1:12 AM, Walter Bright wrote:
> On 11/1/2021 7:51 PM, Andrei Alexandrescu wrote:
>> On 10/30/21 9:59 PM, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>>
>> Made a change to the PR - now the new package is called "std.v2alpha" so as to clarify the transition process:
>>
>> 1. Add std.v2alpha
>> 2. Add to std.v2alpha while continuing with the normal pace of releases
>> 3. When everyhing in v1 was ported to v2, rename v2alpha to v2 and release.
>>
>> That way we can implement complex versions without blocking the release process for a long time.
> 
> Or just `std2a`. It should not be a sub-package of std.

Correctamundo. It's up to us. Off the top of my hed there'd be a few practical issues with managing separate roots - makefile, build and test, and such. Package-level protection won't work across versions, which is a bummer - possibly a showstopper. But we can definitely look into it.

On 11/2/21 2:53 AM, Robert burner Schadek wrote:
> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/8309
>>
>> Destroy!
> 
> I said it before
> 
> https://forum.dlang.org/post/wmqipfssxluzohrhxryy@forum.dlang.org
> 
> I say it again, this is NOT a technical problem this is a management and leadership problem.
> 
> Destroyed!

I agree with most of your points and definitely love the enthusiasm. But it seems to me you are looking at a one-off revolution and what we must define is a reproducible process. One does not exclude the other.

On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu wrote:
>> Destroyed!
>
> I agree with most of your points and definitely love the enthusiasm. But it seems to me you are looking at a one-off revolution and what we must define is a reproducible process. One does not exclude the other.

Not it all, std2 sounds to me like std.experimental just with a different name.

For many of the changes you proposed of these posts, and years in general, I agree
with you or am not ashamed I don't know enough to make any contribution, and by
experience trust your decision.

I disagree on the reproducible process.
I think it is a trap.
IMO no breaking change is the same, therefore no reproducible process exists.

Removing std.string.soundex is different than killing auto-decoding.
I run in this trap, myself sooooo often.
"If I only had tool X, which takes me 1 month to build, task Y would be so simple and I have use it so often"
Or I can duck tape it right now, and the thing I want to be build is out of commission before the duck-tape fails.

Worse still, they are different but maybe in a completely different way.
For instance, how often is popFront called on a string.
Searching for soundex in D files on github is a lot easier, not perfect, but with a deprecation cycle, likely not a problem.

Again, I'm trying to say, that the D compiler as a library thing should be able to tell me how many cases of auto-decoding are there.

As we don't have that right now we could do something as shown here https://github.com/dlang/phobos/pull/8309/files#r741295406
and build all of code.dlang with the next dmd/phobos release and see how often that shows up.
Summit PR's to fix.
After the deprecation cycle we get D 102.0.0 or so and move on.

On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu wrote:
>
> and what we must define is a reproducible process.

I think this is the central conflict discussed by agile.

On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu wrote:
> On 11/2/21 2:53 AM, Robert burner Schadek wrote:
>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>> 
>> I said it before
>> 
>> https://forum.dlang.org/post/wmqipfssxluzohrhxryy@forum.dlang.org
>> 
>> I say it again, this is NOT a technical problem this is a management and leadership problem.
>> 
>> Destroyed!
>
> I agree with most of your points and definitely love the enthusiasm. But it seems to me you are looking at a one-off revolution and what we must define is a reproducible process. One does not exclude the other.

I'm curious if you could define the problem and, as a forum, we could look at other major languages to see how they solved it. Example languages: Python2/3, C/C++, Java, C#, Perl, PHP, Go, Javscript/Typescript, Fortran, COBOL, Ada, and Ruby.

The solution seems to be to remove a language feature that is now obsolete, but only from the standard library. Is that correct? What problems is having this auto-decoding feature causing?