June 14, 2022

On Tuesday, 14 June 2022 at 07:09:23 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 14 June 2022 at 06:46:45 UTC, bauss wrote:

>

I completely agree with this. It bothers me A LOT that it's the view of most people around here.

Why stop there? Why not remove any constraints in the language? After all you can just stop making mistakes. "Just don't do it."

Why do we need @safe, dip1000 etc.? Just verify the memory yourself, if you accidentally screw up then that's your fault, surely it isn't the language's fault.

@nogc? Nah we don't need that, just don't allocate using the GC.

When you end up adding more and more stuff to a language it is considered better to go back to the drawing board and start over.

Otherwise you’ll end up with a mess...

D is honestly a mess compared to when I first started using it over a decade ago, back then it was simple and you could easily do something in it.

Now you have this huge amount of attribute soup that you either need to sprinkle everywhere or you have to completely ignore.

The community and libraries etc. also feel a lot more divided, even compared to when tango was a viable alternative to phobos; at least that's how it feels from my point of view.

Also it's like D chooses the most complex implementations for every new feature that has to be added.

I came to D because it was easier to use and get things done in than any other languages, but over the past couple years I've slowly stopped starting new projects in D because it's becoming a drain to use and all its selling points are no longer selling points because other languages are either on pair with D or does it better.

D was on the path to greatness, but no more. It's spiraling down a bad path and it's honestly sad. It had so much potential and I'm not sure it'll ever recover.

The only way for D to ever succeed would be to start D3 ASAP and start by figuring out how to get rid of the attribute soup etc. because all it does is adding clutter and clutter is what makes a language difficult to use. C++ wasn't hard because of the technical stuff, but because there's a lot of clutter in the language with templates etc. IMHO.

June 14, 2022
On Tuesday, 14 June 2022 at 07:09:23 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 June 2022 at 06:46:45 UTC, bauss wrote:
>> I completely agree with this. It bothers me A LOT that it's the view of most people around here.
>>
>> Why stop there? Why not remove any constraints in the language? After all you can just stop making mistakes. "Just don't do it."
>>
>> Why do we need @safe, dip1000 etc.? Just verify the memory yourself, if you accidentally screw up then that's your fault, surely it isn't the language's fault.
>>
>> @nogc? Nah we don't need that, just don't allocate using the GC.
>
> When you end up adding more and more stuff to a language it is considered better to go back to the drawing board and start over.
>
> Otherwise you’ll end up with a mess...

well, that cycle does seem to be the case.

e.g. the universe is a result of 'things' combining together to make other things, and those things combining to make yet more things, and those things combining to (at some point) make atoms, and atoms combining to make molecules, and then molecules adding to make .., and ..  .. ...

Sure, it'll all come crashing down at some point (well, presuming a non-infinite universe, which i doubt is the case)

But we exist cause these things were adding themselves to each other.

At some point, the universe will implode and it'll all start all over again (at least that's why things seems to suggest).

The trick is, to make that point is so far into the future, that it doesn't really matter in your everyday considerations ;-)

i.e. adding a thousand new features to D every day, might be going too far.
June 14, 2022
On Tuesday, 14 June 2022 at 07:45:26 UTC, forkit wrote:
>
> ...
> Sure, it'll all come crashing down at some point (well, presuming a non-infinite universe, which i doubt is the case)
>

oops. replace 'doubt' with 'expect'

" .. which i expect is the case)"
June 14, 2022

On Tuesday, 14 June 2022 at 07:34:32 UTC, bauss wrote:

>

D is honestly a mess compared to when I first started using it over a decade ago, back then it was simple and you could easily do something in it.

It is my viewpoint that D would have been more successful if it had chosen to be simple system level language without GC/templates and instead focused on high quality builtins and high level optimizations… but that ship has sailed for sure!?

Rust is taking that space, except it isn't all that convenient. I don't have much belief in Zig and the other newcomers… C++ is just too far ahead at this point for me to view minor system level languages as interesting. And by not being interesting, I mean that I am not even willing to download and give them one spin…

There is also much less need for system level programming today than 10 years ago, so it is a shrinking market with more competition… Only 2 or 3 can succeed in building an eco system in that space and also reach an acceptable level of portability (full support for various hardware, iOS, Android, compilation to FPGA, etc).

>

D was on the path to greatness, but no more. It's spiraling down a bad path and it's honestly sad. It had so much potential and I'm not sure it'll ever recover.

Depends on SDC, if SDC implements the core language and don't sacrifice compiler internals to support other cruft then I guess you could attract compiler devs that would evolve it into a clean slate D3.

>

The only way for D to ever succeed would be to start D3 ASAP and start by figuring out how to get rid of the attribute soup etc. because all it does is adding clutter and clutter is what makes a language difficult to use.

You could reimagine D3 as a high level language with the possibility of going system level. If you design from that angle then all the clutter will vanish as you cannot tolerate clutter in a high level language design.

Clutter in D has for the most part been added in the name of "system level".

(Which is a bit odd, because system level programming is even more in need of clean simplicity due to the drastic consequences of making a misstep.)

>

C++ wasn't hard because of the technical stuff, but because there's a lot of clutter in the language with templates etc. IMHO.

Well, there isn't all that much incomprehensible clutter in C++ anymore if you want to avoid it, but you still have to deal with "evolved surprises", so it isn't easy for beginners.

C++ cannot become acceptable for high level programming though, as it has a heavy focus on enabling compiler optimizations. As a programmer you have to focus heavily on the correctness of your code, rather than relying on wrongdoings being caught. That makes C++ unsuited for evolutionary programming. You basically need a design before you code in C++. So C++ is not a good alternative for D programmers who like to experiment and prototype.

June 14, 2022

On Tuesday, 14 June 2022 at 07:34:32 UTC, bauss wrote:

>

Now you have this huge amount of attribute soup that you either need to sprinkle everywhere or you have to completely ignore.

Totally agree with this, it puts me off using D. TBH I haven't started a project in D for a while now, I am simply reaching for Python or C++20. Both get the job done and while not great C++ is at least moving in the right direction.

>

The community and libraries etc. also feel a lot more divided, even compared to when tango was a viable alternative to phobos; at least that's how it feels from my point of view.

I much prefer Phobos over Tango but I agree the core development community seem very divided. Instead of trying to grow the user base with a great experience, adding syntax sugar and frition reducing features like int[$] arr = [1, 2, 3]; etc. But no, a massive amnount of energy is spent on chasing C? Seriously?? C interop is hugely important but D already interop'd with C seamlessly enough....clearly not enough for a core few because that is the main focus for D development right now.

>

Also it's like D chooses the most complex implementations for every new feature that has to be added.

I came to D because it was easier to use and get things done in than any other languages, but over the past couple years I've slowly stopped starting new projects in D because it's becoming a drain to use and all its selling points are no longer selling points because other languages are either on pair with D or does it better.

This is also my experience, unfortunately it is at the point where I do not start new projects in D.

>

D was on the path to greatness, but no more. It's spiraling down a bad path and it's honestly sad. It had so much potential and I'm not sure it'll ever recover.

Totally agree but I wouldn't say sad, it just is. I have moved back to C++ for hobby projects and I'm rather enjoying C++20. I also like the fact I'm staying up to date the latest C++. There are a lot more C++ jobs than D jobs out there.

>

The only way for D to ever succeed would be to start D3 ASAP and start by figuring out how to get rid of the attribute soup etc. because all it does is adding clutter and clutter is what makes a language difficult to use. C++ wasn't hard because of the technical stuff, but because there's a lot of clutter in the language with templates etc. IMHO.

Agreed, I like the improvements in C++20 but it has a long way to go to make things readable That said int func(auto value) {} is pretty easy to read template. D code now with attributes, I wouldn't know where to start and TBH would probably just ignore them.

June 14, 2022
On Tuesday, 14 June 2022 at 08:35:53 UTC, norm wrote:
>
> Agreed, I like the improvements in C++20 but it has a long way to go to make things readable That said `int func(auto value) {}` is pretty easy to read template. D code now with attributes, I wouldn't know where to start and TBH would probably just ignore them.

It's easy.

Start with:

module myModule;
@safe:

...
now when things don't work, you just comment out @safe:

now the magic happens ;-)

Coming from C#, that suits me perfectly - it's either unsafe, or it isn't.

I don't mind what D is doing with the other attributes.

I like attributes. The more the merry'ier... it gives me choice.

I just need to know what those choices actually are, and do they work.

June 14, 2022

On Tuesday, 14 June 2022 at 08:35:53 UTC, norm wrote:

>

Totally agree with this, it puts me off using D. TBH I haven't started a project in D for a while now, I am simply reaching for Python or C++20.

Do you combine Python and C++, i.e. call C++ code from Python? Or do you "chase" higher level and lower level aspects in different projects?

>

etc. But no, a massive amnount of energy is spent on chasing C? Seriously?? C interop is hugely important but D already interop'd with C seamlessly enough....clearly not enough for a core few because that is the main focus for D development right now.

It is being done for fun. It is not unreasonable that people do things they find interesting in their own spare time.

The problematic part is that incomplete features are being merged instead of being polished in an experimental branch. Even more problematic when it is stated that the feature perhaps will never become complete (macro expansion). Such experiments should never be done on the main branch and that pretty much defines almost all of D's challenges.

There is quite a difference between this practice and C++ compilers making features available for preview when they are following a formal spec!

>

Totally agree but I wouldn't say sad, it just is.

It is a bit sad if you count all the hours put into attempts to build an eco system around it. The current approach guarantees a mode of perpetual instability, and that prevents an eco system from emerging.

It would be much easier to build an eco system if you had one big fat breaking change to set the record straight (D3) than what is perceived as random movements. If people feel you are moving about randomly they become passive.

June 14, 2022
On Tuesday, 14 June 2022 at 06:49:59 UTC, bauss wrote:

> People also completely misunderstand what we're asking for.

No. No we do not. We understand *exactly* what you are asking for.


>
> I really don't understand why people are so much against it when it can be added without interfering with existing code, but it surely will help.

I can't speak for anyone else, but I don't think it adds *any* benefit to the language whatsoever. I have read all of the arguments for it and I don't find any of them compelling enough that the feature would bring significant advantage over putting classes with "strictly private" members in their own modules.

But again, I'm just a guy expressing his opinion. Walter and Atila are the ones you need to convince.

Talking about it endlessly in the forums has zero chance of getting the feature in. You guys posting about it in every other thread apparently feel strongly about it, so write a DIP. Get feedback from others who support it and try to craft a rationale that Walter and Atila will find compelling enough to accept (i.e., show that the benefit outweighs the added cost in maintenance and language complexity, why the arguments against it are wrong, etc.).

Once you submit it and it's had enough time in Draft Review that you're satisfied with it, I'll even give it priority over any other DIPs in the queue.
June 14, 2022
On Tuesday, 14 June 2022 at 10:29:14 UTC, Mike Parker wrote:
>
> I can't speak for anyone else, but I don't think it adds *any* benefit to the language whatsoever. I have read all of the arguments for it and I don't find any of them compelling enough that the feature would bring significant advantage over putting classes with "strictly private" members in their own modules.
>

Just because it doesn't add a benefit to you doesn't mean it doesn't add a benefit to anyone else.

I don't see a benefit in @nogc, importC etc. for that matter, yet I still see the value in those and wouldn't/haven't propose for them to be removed/not implemented.

I don't see the problem in adding things that helps one group of developers, if that thing doesn't ruin it for anyone else.

I think it's really ignorant to have a stance like that with a programming language that strives to be general-purpose. The whole point of a programming language to be general-purpose is that you might not need all the features or see value in all features, but you have them at your disposal if needed, because you want to appeal to as many people as possible.

I can't say I'm shocked, because it's the usual view with D, barely anyone in the community is willing to compromise.
June 14, 2022
On Tuesday, 14 June 2022 at 10:29:14 UTC, Mike Parker wrote:
>
> Once you submit it and it's had enough time in Draft Review that you're satisfied with it, I'll even give it priority over any other DIPs in the queue.

Personally I would do it, but I unfortunately do not have enough time on my hands that I could even do that and I do believe it would be the right way to do it instead of these long discussions about it here in the forum.

If anyone is willing to do it, then I for sure wouldn't mind helping but I don't have enough time to write a whole DIP by myself.