We are forking D (page 20)

On Wednesday, 10 January 2024 at 12:08:07 UTC, Paolo Invernizzi wrote: > > I care, for example, because that would be an improvement in my company codebase. But it's not an improvement _in the D ecosystem_ to hear shouts during 3 month (we loose lots of users this way), lost goodwill, over a menial feature that was always possible as part of the scriptlike package 9 years ago. https://github.com/Abscissa/scriptlike/blob/master/examples/features/StringInterpolation.d I care a lot about D mind you and I see no evidence that any feature is worth that kind of shouting contest. It's going to be very fun when everyone come to agree ImportC was a good idea in the end.

On Wednesday, 10 January 2024 at 13:02:55 UTC, Guillaume Piolat wrote: > ... It's going to be very fun when everyone come to agree ImportC was a good idea in the end. There was a debate/contest against this? I thought most wanted a easy way to use C inside D without hassle. Sometimes I see complains about not be completed though. Matheus.

On Wednesday, 10 January 2024 at 13:02:55 UTC, Guillaume Piolat wrote: > On Wednesday, 10 January 2024 at 12:08:07 UTC, Paolo Invernizzi wrote: >> >> I care, for example, because that would be an improvement in my company codebase. > > > But it's not an improvement _in the D ecosystem_ to hear shouts during 3 month (we loose lots of users this way), lost goodwill That are speculations, users come and go. The lost of Adam and a fork is a fact. The discussion is about losing _long term_ contributors, and try to find out why and how to keep them contributing. But that's fine, we agree that we disagree. >, over a menial feature that was always possible as > part of the scriptlike package 9 years ago. >https://github.com/Abscissa/scriptlike/blob/master/examples/features/StringInterpolation.d I know about Nick solutions, I remind you we are using mixins too. > I care a lot about D mind you and I see no evidence that any feature is worth that kind of shouting contest. It's going to be very fun when everyone come to agree ImportC was a good idea in the end. Again, the point is not about features, is about caring about contributions. It's not a shouting contest, is trying to prevent people to uprise until the point of shouting. Let's start from a common point: we all care about D, let's try to be positive and find out if there's a good way to move forward and solve the kind of problems that we are facing with this situation. I honestly ask, you have suggestions?

On Tuesday, 9 January 2024 at 21:11:39 UTC, Walter Bright wrote: > The modern consensus is that iostreams was a misuse of operator overloading. I don't know where you got the idea that there is a concensus. I've never met an unindoctrinated programmer with such a prejudice. For most people, it is natural to adapt to the fact that a name can have a different meaning in different contexts. The appeal to aesthetics doesn't work, either. Aesthetics is highly subjective and depends on the environment. In reality, some of your decisions that limit the language in order to impose your aesthetic preferences on the programmer often result in the most unaesthetic hacks I've ever seen.

On Wednesday, 10 January 2024 at 13:38:51 UTC, Max Samukha wrote: > On Tuesday, 9 January 2024 at 21:11:39 UTC, Walter Bright wrote: > >> The modern consensus is that iostreams was a misuse of operator overloading. > > I don't know where you got the idea that there is a concensus. Aren't std::print and std::format intended to supplant iostream?

January 10

Re: We are forking D

Posted by Nick Treleaven
in reply to GrimMaple

Permalink

Nick Treleaven

Posted in reply to GrimMaple

Permalink

On Wednesday, 10 January 2024 at 11:01:07 UTC, GrimMaple wrote:

On Tuesday, 9 January 2024 at 21:56:55 UTC, Walter Bright wrote:

The trouble is there are some coding problems that only I can resolve. For example, nobody else is crazy enough to have embedded a C compiler into D. Heck, I thought it was a crazy idea for a couple decades.

Have you ever considered that this is the case because you deliberatly created an environment where other people simply don't want to resolve problems?

You may believe that but you can't know that your sentence is true. There's a good principle: 'Never attribute to malice that which can adequately be explained by incompetence'. It does both you and the recipient no good to insist on malice.

Do you think that getting your changes reverted enables positive thinking for trying to fix anything?

There are times when reverting things is necessary for the good of users in future, even if it upsets some people.

> >

Would anyone else have implemented an ownership/borrowing system for D? It exists as a prototype in the compiler now, though it's been fallow for a bit as too many other things are happening. I know its design is controversial (Timon doesn't like it at all!), and it hasn't yet proven itself.

Has anyone ever cared about ownership/borrowing in a language that already fixed problems that borrowing fixes? Just use the GC -- and there isn't a need for ownership checks.

Then why do people use Rust? People here use @nogc and -betterC. Some kind of ownership/borrowing system is the go-to solution for memory-safety without a GC.

Interestingly enough, being too involved in D made me somewhat afraid of making contributions at all. I was pleasantly surprised when my changes were silently merged into other projects despite me just dropping them out of nowhere. This is the way I see an open-source project shall be to have any form of success.

OTOH, users have complained about features not being finished or not interacting with other features how they want. So it's a great thing for users when language maintainers are careful when people want to add features or break compatibility. Fortunately I think the DLF have accepted the need for editions, so compatibility won't be so much of an issue.

On Wednesday, 10 January 2024 at 13:30:02 UTC, Paolo Invernizzi wrote: > > Let's start from a common point: we all care about D, let's try to be positive and find out if there's a good way to move forward and solve the kind of problems that we are facing with this situation. Exactly. > I honestly ask, you have suggestions? Yes, but I don't think I would be more relevant than what the DLF say itself. What I observe is that we've given ample space to a discourse that fantasize a horrible destiny for D, and sometimes just plain impoliteness, while from where I stand all kinds of issues go away over time, 50 of my 64 Buzilla entries have been solved (and the other don't matter), and in D industry meetings some have nothing to ask for! And everyone seems to be liking D. How do you reconcile that? The core of the doom discourse is that somehow core team limits D, I feel instead that the community fails to be supportive when it needs to and even accept users behaving in a unprofessional way... If it were for the common good it would be worth it, but I think we're learning eventually that putting up with bad behaviour is not worth it.

On 11/01/2024 4:32 AM, Guillaume Piolat wrote: > The core of the doom discourse is that somehow core team limits D, I feel instead that the community fails to be supportive when it needs to and even accept users behaving in a unprofessional way... > > If it were for the common good it would be worth it, but I think we're learning eventually that putting up with bad behaviour is not worth it. Agreed. I have been trying to foster positive growth factors in the community over the last year due to this. Negativity, especially when it is not earned, does not create growth. Trying to be positive, and encouraging is quite a change.

On Tuesday, 9 January 2024 at 22:10:45 UTC, Lance Bachmeier wrote: > If you contribute this work to the fork, you'll have folks to try it out and provide feedback, and you won't have to add experimental flags to the compiler or mess with the compiler at all. My impression so far is that the openD fork may diverge too far from dmd to be able to merge changes upstream. They've already changed the layout of the repositories - combining phobos and ldc into the compiler one. Maybe my git knowledge is not perfect, but it seems to have made merging openD changes back into dmd much more awkward.

On Tuesday, 9 January 2024 at 23:14:56 UTC, Paolo Invernizzi wrote: > On Tuesday, 9 January 2024 at 21:56:55 UTC, Walter Bright wrote: > Nobody is asking you ... > Literally NOBODY is ... I don't like this style of making a point. It tends to claim more weight than it might actually have. Who's "nobody"? I rather you say speak for yourself with "I" Let's just merge whatever DIP is available lol.

Forums