On Fri, Dec 23, 2022 at 05:21:43PM +0000, monkyyy via Digitalmars-d wrote:
> On Friday, 23 December 2022 at 16:51:40 UTC, Don Allen wrote:
> > 
> > I do hope this project finally finds a way to right itself. It will take the addition of the right person or people, not an easy task, but not impossible. Good luck.
> 
> I believe the main hope is with forks or new compiler projects

The size of the community is small enough that forking may well kill the language.  For new compiler projects, maybe you should contribute to deadalnix's SDC?  It's a D compiler built from scratch according to the published spec.  But still quite limited in how much D code it can compile, last time I checked (that was a while ago, though).


T

-- 
If I were two-faced, would I be wearing this one? -- Abraham Lincoln

On Friday, 23 December 2022 at 16:51:40 UTC, Don Allen wrote:
> ...
> This episode prompted me to do some reading about the history of this project. Around the time Andrei Andreescu left the project, he wrote a pretty frank message about the state of the D world then and what he thought was needed. This prompted an exchange of messages with others interested in D. My point in bringing this up is that that exchange makes what has happened here feel like deju-vu all over again. Nothing has changed.
>
> ... Reading the Andreescu thread demonstrates that I am not the first to make this observation.
> ...

Could you please provide the link for that Thread?

Matheus.

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

When we are going to fix D's biggest mistake? Like D community itself scaring away its own contributors by doing the unreasonable?

On 12/23/2022 6:24 AM, GrimMaple wrote:
> What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.

Expecting people with large C code bases to translate their C code to D is never, ever going to work. With ImportC, their C code bases can become "user friendly" with D code, making using D viable with a considerably larger user base.

After all, look at the success of C++ with its integration with C.

On Fri, Dec 23, 2022 at 08:13:20PM +0000, matheus via Digitalmars-d wrote:
> On Friday, 23 December 2022 at 16:51:40 UTC, Don Allen wrote:
> > ...
> > This episode prompted me to do some reading about the history of
> > this project. Around the time Andrei Andreescu left the project, he
> > wrote a pretty frank message about the state of the D world then and
> > what he thought was needed. This prompted an exchange of messages
> > with others interested in D. My point in bringing this up is that
> > that exchange makes what has happened here feel like deju-vu all
> > over again. Nothing has changed.
> > 
> > ... Reading the Andreescu thread demonstrates that I am not the first to make this observation.  ...
> 
> Could you please provide the link for that Thread?
[...]

I'd also like to find out what message exactly Don is referring to here, since as far as I know Andrei never left D, he still pops in here every now and then with something D related. IIRC he after a period of time in the trenches he just decided to prioritize his personal life instead.


T

-- 
Question authority. Don't ask why, just do it.

On Friday, 23 December 2022 at 20:34:10 UTC, Walter Bright wrote:
> On 12/23/2022 6:24 AM, GrimMaple wrote:
>> What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.
>
> Expecting people with large C code bases to translate their C code to D is never, ever going to work. With ImportC, their C code bases can become "user friendly" with D code, making using D viable with a considerably larger user base.


And what problem will that solve? People in C aren't going to use alien syntax, much less using D because it allows that syntax.

D can't run on every platform as C or C++ does. Unless you're thinking about killing the language itself and making """betterC""" the only usable component in D.

Just check how much time D lost while trying to get into Android (which is unfortunately broken again).
Now we're living the Web era without real D support in WASM. D with the ability to be used as an alternative to Javascript/Typescript programmers would be specially useful as it is not a hard language to work with.


The runtime problem must be solved somehow for we can stop dividing D and betterC libraries. A lot of projects were duplicated after betterC announcement.

I'm still really bothered with the many people that quit the language because of stubbornness and no real comunitty problem.

On Friday, 23 December 2022 at 20:37:31 UTC, H. S. Teoh wrote:
>

I think you have to take Andrei at his word.

https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com

At the same time, it's not unreasonable to wonder if there is something 'not stated' ;-)

But regardless, it can only be conjecture.

Presumably nothing has changed further since this announcement by Andrei?

One thing is for sure... The future of the D Programming language is primarly stuck with Walter.

But I think some are overreacting a little.... let Walter add this thing... I mean who cares.. really? I certainly don't.

I use C if I want to use C.
I use D if i want to use D.
I do NOT use D cause I want to use C.

On 12/22/22 04:23, Walter Bright wrote:
> 
> Every time I try to clean up technical debt, a cadre arises objecting that it breaks existing code.

The technical debt in DMD is how the code and AST is structured, not the features it supports. This is much harder to clean up than removing isolated features and I think you are among the people slowing down such efforts. One reason why is that there are a lot of pull requests that would be broken by large-scale refactorings. Those open pull requests are also technical debt.

OTOH, removing completely isolated lexer features does nothing to clean up technical debt.