named arguments, string interpolation, please stop.

[max haughton]

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:
> I have been in the D community for a very long time. I have 
> seen D successfully deployed in companies, and the pain points 
> associated with it. I have seen D fails to catch on in 
> companies and why that is has well.
>
> Let me tell you, none of this has anything to do with feature D 
> has or does not have. At large, D has more features than most 
> languages

I don't think D is that big by modern standards (anymore at 
least), but anyway I agree. String interpolation however is one 
which I think passes the test; I argue this point below.

Also mentioned briefly is a note that the system (the way D as a 
piece of software is laid out, people can be surprisingly 
irrelevant in this sense) is biased towards shit outcomes, the 
convexity is not in the right direction.

>  - Template symbols are generated as weak, which prevents 
> inlining (!).

Practically this just gets ignored with the exception of gdc 
assuming Iain kept that change, which can also be told to ignore 
it.

>  - Pretty much no cross module inlining, making helper function 
> absurdly costly.

LDC can do that, no? Either with LTO or the 
-enable-cross-module-inlining flag.

>  - The GC implementation is nowhere close to where it needs to 
> be.

This is indeed important, I agree. I am working on making the 
druntime test suite less brittle in part with the aim of being 
able to trust the "swap in your own GC" stuff more (a secondary 
interest but it is in my mind).

> There is nothing features like string interpolations or named 
> argument can bring to the table that could pay for the 
> implementations problem of existing feature. The cost benefit 
> analysis is just a big L for D: the fail to address the main 
> pain points, while causing massive breakage in the tooling 
> ecosystem (syntax highlighting support in 3rd party IDE, code 
> formatter, etc...), and it cost real time and resource to 
> upgrade these, or come at the cost of other quality of life 
> stuff nullifying their benefit (for instance, the quality of 
> syntax highlighting for D has degraded significantly in vim and 
> sublime text over the past few years).

Isn't this cost benefit like assuming a car company can't make 
the brakes better while also making the seats more comfortable?

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)

And on top of that provides real value - the patterns Adam's 
proposal enables are a genuine win all kinds off stuff beyond 
just format!"" style string interpolation i.e. the applications 
when talking to databases and so on are obvious but there is 
massive transformational potential all over the shop.

Javascript goes about it with a more abstract, but less conducive 
to introspection, but similar idea, even in a incohesive language 
with no type system it has great power i.e. was the difference 
between writing a simple function versus either writing or being 
a compiler for a recent project I did.

In the abstract sense I've never really cared that much about 
named arguments (i.e. rarely use them in languages that have it), 
but as a concrete example about tooling - the PR to enable named 
arguments supports in all the "official" tools was done literally 
years before the upstream work in the compiler to actually do the 
semantic analysis on them.

### The ecosystem, tools etc:

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.

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?

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