On Monday, 3 June 2024 at 02:36:08 UTC, Steven Schveighoffer wrote:
...[snip]

It was not my intent to hijack this thread, so I've started a new one in general here: https://forum.dlang.org/post/zljtammlddzxjmpfzqsv@forum.dlang.org

I hope it addresses some of what you mention.

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

I hope you will tolerate this unsolicited intrusion of mine, but as an outsider to your world, I feel the need to say something.

Not long ago, I approached this language because, after examining its fundamentals, I judged it to be the perfect evolution of "my" C language. A few days later, I changed my mind, not because I was wrong in judging the D language, but because D is unusable. And it is unusable because you do everything to make it so.

Let me explain: the primary requirement for a programming language is not its flexibility, power, ease of learning, etc. No, the primary requirement is its stability and the certainty that code written for a release will be compiled by all compilers and libraries that support it.

And this is what makes D unusable (and indeed practically unused). As soon as it is born, a fork of its system library... as soon as it starts to receive support from major IDEs, a fork of the language. Now I see your willingness to make it "dynamically scalable"... my friends, this way, you're going nowhere.

Let's talk about the initiative related to this thread: it doesn't work. It's not acceptable that using the same language, I would write code that wouldn't be compiled by the machine of the programmer at the desk next to mine. This would be possible if I were programming in C and he in D, but if we both work in Dv2, the language standard must be the same for everyone.

Of course, there can be a Dv3, Dv4... Dv2001, but someone has to standardize each version and, once done, there must be a freeze that prevents changes (except for debugging).

Maybe I am too conservative for a lively language like this, it happens to us sixty-year-olds. But being sixty has an advantage: we know the business world well. From experience, I would find it very difficult to convince a company to use code written in D. Companies are more conservative than sixty-year-olds and do not like investments that change from one day to the next. Asking a programmer what version of D they work with is inconvenient, it is much more practical not to accept D.

Now I retreat, apologizing for the inconvenience caused.

Regards, U.

On Thursday, 6 June 2024 at 04:21:23 UTC, Federico wrote:

There's a "Destroy!" right there, so I can't see how the "intrusion" would have been unsolicited. ;)

I agree that should be a goal.

What makes you think that? Especially since in a world where those things are true I wouldn't have my current job(s).

As soon as it is born, a fork of its system library...

I agree. What in the proposal makes you think that it wouldn't work?

Those would be editions.

I would also find it difficult to convince most companies to use Haskell or Clojure, but I'm not sure how that's relevant.

On Friday, 7 June 2024 at 00:53:51 UTC, Atila Neves wrote:

Unsolicited because, having abandoned the study of this language, I am not part of the community. Abandoned with great regret, I must add.

I am a very concrete person, Atila, so I judge things by results and not by potential, or at least I do so when enough time has passed to say that a final assessment can be made.
Now, should D have achieved significant penetration, at least in terms of potential? Absolutely yes, as I have already said, this language represents the natural evolution of C and is suitable for any field.
Of course, there are some incomprehensible choices, but no one is forced to use those features. The "core" of the language is what any C programmer would want to have in their hands... Bright did an extraordinary job!
And yet it did not happen. The penetration of D is modest to say the least, despite being the ideal candidate for the migration of C programmers seeking a more modern environment without significantly sacrificing efficiency already two decades ago, this affirmation did not happen.
It is correct to say that D has underperformed its potential.
And we must not think that we C programmers did not desire an evolution of the tool. Many switched to C++ (not me because I find it inelegant and very inefficient) and more recently to Rust, in this case deservedly.
And here begins D's problem: D is superior to C++, it is more elegant, more efficient, and its implementation of the object-oriented paradigm is more "natural" than what we can find in C++. And yet there was almost no migration from C/C++ to D! Why? The first serious blow came with the Phobos-Tango affair. Incomprehensible!
No one likes everything about the official libraries of C, just as I imagine is the case with any other language, but for this reason, no one wakes up tomorrow morning and creates a fork. What happens is the addition of other libraries while leaving the official ones unchanged.
There is no "stdlib_v2" that implements functions with syntax and semantics different from the standard stdlib.h.
Let's come to the present day.
D finally acquires support from the professional development environment for Microsoft, which is not Visual Studio Code but Visual Studio Pro/Enterprise, the plugin for the other professional programming environment on Linux, the Jetbrains IDEs, starts to work... and what does your community do? A nice fork of the language! Instead of writing E, which would be rational, they start developing modifications to the main language. And that's not all, because the maintainer of the Jetbrains plugin declares on GitHub that he wants to follow OpenD. So we will have a D language for Windows and a D language for Linux. Fantastic, ideal for protecting software investments!
At that point, I, a novice language student, come here to the official forum to try to understand what is happening, and I find this magnificent thread discussing the dynamic scalability of the language.
The only possible reaction: put D aside, albeit with much regret.
Why this would not work I have explained: if you want to safeguard investments, there cannot be "dynamic evolution." The correct (and accepted by companies) way to evolve a language is to convene a conference at intervals of 3 to 6 years, more precisely when there are new developments in the computer paradigm that render the previous version obsolete, find a synthesis of the various proposals, and produce ONE document that describes the next step to which ALL compilers claiming compliance with that version must adhere.
It is true, there are successful languages that do not follow this "discrete" evolution scheme, such as C#/.NET Framework and the already mentioned Rust. But there is a notable difference: the governance and/or the strength given by the already acquired adopter base.
C# means Microsoft, just as Swift translates to Apple, Go to Google, and so on.
In these cases, it is the weight of the company behind the language that ensures both the critical mass of users and the security of the path taken.
Rust's story is a bit different. Rust was widely adopted because it seriously addressed security needs just when software security was experiencing the worst crisis in its history. In this case, it is the mass of its users that guarantees both the future and the support in development tools (with the absence of Visual Studio because Microsoft certainly does not view it sympathetically).
Now Atila, despite its not short lifespan an
 its undeniable qualities, D does not find itself in any of those fortunate conditions. On the contrary, it seems to me, it still has to offer developers a reason for its adoption, which certainly cannot pass through uncertainty about the path followed.

I apologize for having made it unbearably long.

On Friday, 7 June 2024 at 15:01:03 UTC, Federico wrote:

I am a very concrete person, Atila, so I judge things by

While your perspective is welcome, this forum is specifically for discussing DIP ideas. A discussion of D's prospects is off topic in this thread. Please see the forum rules linked at the top of the page if you're viewing from the web interface.

Normally, I'd delete the post outright. In this case, though, I'll just ask that anyone wanting to continue this discussion please start a new thread in the General forum. I will delete any further off-topic posts, though.

Thanks!

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

I would just like to comment on one aspect of the DIP for now: the "Examples" section is a bit of a sore sight currently. It's difficult to get excited about the idea when the proposed actions it unlocks is "we're changing two defaults and removing three features without providing an immediate replacement".

Regarding the removal of lazy, I'm particularly curious about the consequent fate of assert and enforce, two prominent current users of `lazy. It seems like either way would involve a compromise:

• Will assert fully become "compiler magic", unimplementable in user code, and enforce replaced with an explicit delegate variant?
• Will both assert and enforce require an explicit delegate, thus making unit tests quite a bit more syntactically noisy?
• Will both assert and enforce become "compiler magic" (and therefore unimplementable in user code)?