October 30, 2022

On Saturday, 29 October 2022 at 17:19:11 UTC, Stefan Hertenberger wrote:

>

On Saturday, 29 October 2022 at 16:02:34 UTC, Sergey wrote:

Inside D's GC

Thank you!

Does anyone know how many bullet-points already implemented from the list?

October 30, 2022

On Sunday, 30 October 2022 at 13:33:21 UTC, Imperatorn wrote:

>

I still think D as a language is superior. But a lot of the tooling around it needs some work.

But imo it's worth fixing that because D could soon be popular again.

I haven't written a lot of Swift code, but I am not enthusiastic about some of the stuff Apple have let it inherit from Objective-C.

D also has baggage (e.g. @keywords) , so if by "fixing" you mean streamlining then I would be hopeful. If there is no streamlining involved then I would expect other languages willing to streamline and clean up to trend.

I don't really think "it is just historical baggage" and "not willing to break" will work out well in the long run, for any language. This applies to any language that has not reached critical mass, not only D.

October 30, 2022
On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules wrote:
> On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:
>> ..
>> ...
>> Why does D need to be standardized? I mean, it would be great if it was, but why would it be a "non-starter" otherwise?
>
> So my arguement was for making a D like implementation of 'C with modules', into an ISO standard (not making D into a ISO standard).
>
> You ask why?
>
> Because an international standard *ensures* that 'quiet changes' do NOT occur.

You know what else ensures that quiet changes do NOT occur? Using the same version of the compiler. It also prevents you from having to choose between using compiler extensions or limiting yourself to functionality that didn't have the consensus of the committee. And when an updated standard comes out, which adds modules, you don't have to decide which "standard" you're using.

October 30, 2022

On Sunday, 30 October 2022 at 14:12:39 UTC, bachmeier wrote:

>

On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules wrote:

>

On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

>

..
...
Why does D need to be standardized? I mean, it would be great if it was, but why would it be a "non-starter" otherwise?

So my arguement was for making a D like implementation of 'C with modules', into an ISO standard (not making D into a ISO standard).

You ask why?

Because an international standard ensures that 'quiet changes' do NOT occur.

You know what else ensures that quiet changes do NOT occur? Using the same version of the compiler. It also prevents you from having to choose between using compiler extensions or limiting yourself to functionality that didn't have the consensus of the committee. And when an updated standard comes out, which adds modules, you don't have to decide which "standard" you're using.

Stuff breaks when things change as loudly as possible, ie, with a large number of warnings beforehand; I doubt a silent change in any moderately popular compiler will ever go unnoticed, since it would be liable to affect something, somewhere, and someone will come and complain

October 30, 2022

On Sunday, 30 October 2022 at 15:00:49 UTC, Tejas wrote:

>

On Sunday, 30 October 2022 at 14:12:39 UTC, bachmeier wrote:

>

On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules wrote:

>

On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

>

..
...
Why does D need to be standardized? I mean, it would be great if it was, but why would it be a "non-starter" otherwise?

So my arguement was for making a D like implementation of 'C with modules', into an ISO standard (not making D into a ISO standard).

You ask why?

Because an international standard ensures that 'quiet changes' do NOT occur.

You know what else ensures that quiet changes do NOT occur? Using the same version of the compiler. It also prevents you from having to choose between using compiler extensions or limiting yourself to functionality that didn't have the consensus of the committee. And when an updated standard comes out, which adds modules, you don't have to decide which "standard" you're using.

Stuff breaks when things change as loudly as possible, ie, with a large number of warnings beforehand; I doubt a silent change in any moderately popular compiler will ever go unnoticed, since it would be liable to affect something, somewhere, and someone will come and complain

Nothing breaks, either loudly or quietly, whatever those terms mean, if you don't change the compiler. It is common for people to invent reasons to justify what they want to do.

October 30, 2022

On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

>

Hi guys,

Just wanted to remind you that, D maybe isn't that bad.

[...]

My original question remains, is D really that bad? I don't think so. I think the frustration comes from not being able to fix some things. But, I think it's doable, while others seem not to think so.

October 30, 2022

On Sunday, 30 October 2022 at 16:00:24 UTC, Imperatorn wrote:

>

My original question remains, is D really that bad? I don't think so. I think the frustration comes from not being able to fix some things. But, I think it's doable, while others seem not to think so.

It is doable if you come up with a design that is wholesome and can get Walter on board, but I dont think it can be done in the forums or issue by issue.

The D semantics are fairly standard for the most part so it would be weird to assume that it could not be "fixed".

October 30, 2022

On Sunday, 30 October 2022 at 17:18:40 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 30 October 2022 at 16:00:24 UTC, Imperatorn wrote:

>

My original question remains, is D really that bad? I don't think so. I think the frustration comes from not being able to fix some things. But, I think it's doable, while others seem not to think so.

It is doable if you come up with a design that is wholesome and can get Walter on board, but I dont think it can be done in the forums or issue by issue.

The D semantics are fairly standard for the most part so it would be weird to assume that it could not be "fixed".

You might be right. I don't know. I guess the "goal" has to be more precise to be able to judge whether we are on the right track or not.

October 30, 2022
On 10/30/2022 1:29 AM, Paulo Pinto wrote:
> Swift and Objective-C, the system programing languages of Apple also have multiple pointer types.

Do you have a reference? I did some googling, and didn't come up with anything.
October 30, 2022
On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote:
> On 10/30/2022 1:29 AM, Paulo Pinto wrote:
>> Swift and Objective-C, the system programing languages of Apple also have multiple pointer types.
>
> Do you have a reference? I did some googling, and didn't come up with anything.

https://mobikul.com/pointers-in-swift/