On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

Now watch this thread grow into oblivion with more than 100 replies... 20+ years of reading D newsgroups/forum taught me that serious stuff should not be discussed here.

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

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.

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

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

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).

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.

On Thursday, 11 January 2024 at 14:34:57 UTC, jmh530 wrote:

Don't focus on the exact list of issues. It's indeed going to differs, but there is a pattern, and what matters is the pattern. These issue are all implementation problem with current features that we have now today. I could have added 10x more by spending a little more time. For instance, demangling support for various debuggers would be tremendously valuable.

Large D project suffers much more from poor or problematic implementation of current feature than they do from the lack of this or that language gizmo.

In addition, improving these things is direct value added to users at little no no cost to the them. They get the same things as before, it just works better.

On the other hand, the cost of new feature - even desirable ones, is greatly underestimated by what I can only assume is a self selected crowd of people who use little tools when coding.

On Thursday, 11 January 2024 at 17:08:50 UTC, Dejan Lekic wrote:

Unfortunately, you are correct.

On Thursday, 11 January 2024 at 14:55:46 UTC, IGotD- wrote:

But that doesn't work. If a GC cycle kicks in in between the thread starting and you having the chance to attach it, you may end up collecting live objects. This is what killed the project, BTW.

Having thread that are not managed by the GC is a fine thing to want, but you got to do it the other way around by detaching the thread from the GC.

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

I would only want the simplest string interpolation but I imagine we are long past that point i"foo:$foo ($LINE)" if your are constructing strings your probably doing something slow(if not use binary data), debug related, or compatibility with some outside nonsense like making json or bash commands, where you guess and check. Like I wouldnt have let it be a debate for 5 years about speed, template expansion, or adding math to it, etc.

but I believe named arguments + templates will make for very very nice api's no one else can manage. I think named arguments are the strongest evidence that d is moving forward at all(note: relative).

On Thursday, 11 January 2024 at 13:09:56 UTC, FeepingCreature wrote:

Sure on the other hand, of the top level languages, very few do have named arguments.
C, C++, javascript, Jave, C#, Rust, PHP, Go, none of them has named argument. Sure, some of the usual suspect do, such as python, but they are a minority, and the conclusion remains: named arguments may be nice to have, but aren't what's preventing anyone from using D.

There is a design mistake I see people making again and again, and it goes way beyond software: they design for what their current most satisfied users want. But that's really dumb, these people are already happy with the product! Anyone in this forum fall into that bucket, by the way. You got to observe how D is used int he wild by people not frequenting this space. What problem do they encounter? What frustrates them? What make the stop using it? These are the people you want to design for if you want to actually improve the product.

On Thursday, 11 January 2024 at 17:45:09 UTC, max haughton wrote:

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.

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.

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.

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

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