named arguments, string interpolation, please stop.

[deadalnix]

On Thursday, 11 January 2024 at 17:45:09 UTC, max haughton wrote:
> [...]
>
> Isn't this cost benefit like assuming a car company can't make 
> the brakes better while also making the seats more comfortable?
>

Car companies pretty much never change the UI, even accross 
brand. Imagine a car manufacturer working and making acceleration 
happen by pressing a button on the steering wheel instead of 
using a pedal rather than work on more confy seats or better 
brake and you have a good analogy of what we are doing.

I'm sure there are a lot of reasons for making such a change, for 
instead people with no feet can no accelerate! Nevertheless, it's 
unlikely to go well for that company.

> A good GC might be the best part of half a million dollars 
> worth of programmer-budget whereas (say) string interpolation 
> is basically free i.e. its a tiny lowering right at the 
> beginning of semantic analysis, not like adding dependent types 
> - the complexity is not a fractal (whereas some changes mostly 
> definitely are)
>

I don't think so. Here is the problem we have, we don't read 
either the research papers on the topic or the implementation 
other have done. Building something new from scratch? Sure, you 
are right. Reading boehm, the dotnet runtime, tcmalloc and 
jemalloc, and reusing the techniques in there, not where close to 
that cost.

We don't have to reinvent the wheel.

> Most of the issues with tooling in this sense when things 
> change is purely just brought about because things are too 
> separated. Along those lines I am planning to try to merge in 
> all the tools as they use the dmd frontend more and more. The 
> current layout of dfmt et al, and the compiler/s themselves is 
> fundamentally biased towards making this kind of change 
> difficult, fix that and there would be a lot less to complain 
> about.
>

It will always be. All kind of people work on all kind of tools 
and most are willing to do a best effort to support D. However, 
that support is dwindling, when it should be growing. Time 
passing is playing in our favor there, we could just be cruising 
and accumulate support.

Most of these tools will not use the D frontend or whatever else 
to do that, for the simple reason that most of these tools will 
have their own idiosyncratic way of doing it. People are always 
going to come up with new idea about what tools can do, and we 
can benefit from that.

In fact, the gradual loss of support is a good indicator that the 
features don't pay for themselves. if they did, people would be 
upgrading. There are ac ouple of lever one can use to solve this:
1/ Reduce the cost of upgrade, for instance by delivering the new 
goodies in batch infrequently.
2/ Work on feature that deliver more value, which probably 
involve high quality implementation of said features, and on that 
front I bring you attention to the original post.

> Wrt to Vim and so on I've very rarely been using the syntax 
> highlighting that comes with an editor so no idea on that front.
>
> Is highlighting in sublime text worth halting any change? I 
> assume its done lexically so if a token looks a different 
> colour does it matter?
>

Vim and sublime are widely used text editors. Both probably have 
more users than D by at least an order of magnitude.

> There is an LSP easily within reach of any sufficiently modern 
> or sufficiently configurable editor, these are extremely 
> popular and standardized now.

Yes. Who maintain these for each editor? Nobody because cost > 
benefits. And for as long as this is the case, the ecosystem will 
shrink.