D Editions

[Federico]

On Friday, 7 June 2024 at 00:53:51 UTC, Atila Neves wrote:
> On Thursday, 6 June 2024 at 04:21:23 UTC, Federico wrote:
>> On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:
>>> https://github.com/atilaneves/DIPs/blob/editions/editions.md
>>>
>>> Destroy!
>>
>>
>> I hope you will tolerate this unsolicited intrusion of mine,
>
> There's a "Destroy!" right there, so I can't see how the 
> "intrusion" would have been unsolicited. ;)
>
>> 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.
>
> I agree that should be a goal.
>
>> And this is what makes D unusable (and indeed practically 
>> unused).
>
> 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...
>> 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.
>
> I agree. What in the proposal makes you think that it wouldn't 
> work?
>
>> 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).
>
> Those would be editions.
>
>> From experience, I would find it very difficult to convince a 
>> company to use code written in D.
>
> I would also find it difficult to convince most companies to 
> use Haskell or Clojure, but I'm not sure how that's relevant.

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.