October 28, 2021

On Thursday, 28 October 2021 at 09:48:42 UTC, SealabJaster wrote:

>

...

Please read the following by no means as a personal attack.

Much of what you have written in the post above sounds defeatist to me.

Why try, we never gone make it to Mars?
But if we try, we might aim for Mars and make it to the Moon.

I should have added a leadership section to my post,
but at heart I'm an engineer at those things are difficult for me.

I would say though that the role of leadership in this instance is
to push for transformation, to set the long term vision, even and maybe
especially, if it is met with strong disagreement by parts of the community.
I rather would see people being annoyed by safe being the default and
forced GC usage, than see nobody on the forum, because nobody cares anymore.

The defeatist in me thinks, if D doesn't transform it will slowly but surely die
a quiet death.

"Change or go bust"

The optimist in me would say, that if people aren't angry with you for your decisions you haven't tried hard enough to do the right thing.

October 28, 2021

On Thursday, 28 October 2021 at 09:48:42 UTC, SealabJaster wrote:

>

I really appreciate this vision, but from experience of lurking this forum, I can tell you that, particular the older programmers, won't see much worth in a lot of your suggestions regarding the compiler changes (assuming we'd ever even have the manpower to make it possible in the first place).

Yes, there is a distance between those that still use emacs/vi and those that expect AI-like visualized editing. And this distance will only increase as editors become more "intelligent" over time and require better static analysis from tooling. The distance is increasing year by year, so it isn't even about status quo, but where will you be in 10 years? If there is a noticeable distance today, then there will be a huge distance in 10 years.

Anyway, the compiler has hit an evolutionary wall. When the language can no longer evolve because of internal compiler structure then you need to change priorities; meaning design a new architecture and restructure/rewrite compiler components and freeze language changes.

The cost of modifying the compiler will increase over time if you don't change the architecture. The effort spent on making a compiler modular does pay for itself over time.

It is basically the difference between having a long term plan for the architecture or just evolve iteratively without a plan as you go along. There are few examples of the latter ending well.

>

I believe that's similar to how the vision documents went. "Here's a wishlist, please-maybe-possibly-if-you-want-to do it Community, best of luck and lots of love - from, the D foundation"

The vision document was too much of a list of details rather than a vision of the end-result. You need to have a strong vision for the end result in order to plan and make the best priorities.

>

If only posts like this could come from those who have the power, time, and motivation to organise a strong, coherent, unified vision. And if only we had the manpower to make our strongest wishes come true.

It is difficult to get manpower without first projecting a strong vision.

Anyway, kudos to Robert for putting a lot of thought into his post.

October 28, 2021

On Thursday, 28 October 2021 at 10:38:20 UTC, Robert burner Schadek wrote:

>

On Thursday, 28 October 2021 at 09:48:42 UTC, SealabJaster wrote:

>

...

Please read the following by no means as a personal attack.

Much of what you have written in the post above sounds defeatist to me.

I'm very much a pessimist, so this is pretty on point >:D No offense taken btw.

But from my personal perspective of D, it's "slowing down" and reaching a "stuck"/stagnation state.

One can only hope that the leadership will take the helm and provide us a proper vision going forward.

October 28, 2021

On Thursday, 28 October 2021 at 10:39:21 UTC, Ola Fosheim Grøstad wrote:

>

On Thursday, 28 October 2021 at 09:48:42 UTC, SealabJaster wrote:

>

I really appreciate this vision, but from experience of lurking this forum, I can tell you that, particular the older programmers, won't see much worth in a lot of your suggestions regarding the compiler changes (assuming we'd ever even have the manpower to make it possible in the first place).

Yes, there is a distance between those that still use emacs/vi and those that expect AI-like visualized editing. And this distance will only increase as editors become more "intelligent" over time and require better static analysis from tooling. The distance is increasing year by year, so it isn't even about status quo, but where will you be in 10 years? If there is a noticeable distance today, then there will be a huge distance in 10 years.

I think this sort of ties into that discussion about fringe languages and polyglot programmers.

The less appealing to those exploring new languages, especially those that are mono-linguists or are only proficient in languages with good tooling, the less likely they are to come to D, no matter how much we gloat about the language.

Sure we might pick up a few old school C++ programmers, and maybe the odd curious Pythonista, but what access to we have to the newer generation(s) of programmers? a.k.a the future?

Even C has better autocomplete than D, which, granted, is due to its simplicity, but still it's technically easier for someone to get into a new C library than it is a D library because they have to scour source code/online documentation instead of being able to do the comfy thing and stay within their text editor/IDE.

I had an initial interview yesterday about a job (fingers crossed!) and I was like "ideally I'd use D everywhere, but it's not really going anywhere anytime soon, and it's ecosystem is complete garbage, so I'd probably use Go or C#".

This is the opposite direction we want things. We want others to come to us, not for us to go to others.

>

Anyway, the compiler has hit an evolutionary wall. When the language can no longer evolve because of internal compiler structure then you need to change priorities; meaning design a new architecture and restructure/rewrite compiler components and freeze language changes.

I can't say too much since I haven't worked on the compiler enough, but it does seem similar to other complaints regarding a lack of compiler devs.

>

It is difficult to get manpower without first projecting a strong vision.

Indeed

>

Anyway, kudos to Robert for putting a lot of thought into his post.

Agreed, it definitely seems like this was on his mind for a while to come out of nowhere with a post like that.

October 28, 2021

On Thursday, 28 October 2021 at 11:03:35 UTC, SealabJaster wrote:

>

Even C has better autocomplete than D, which, granted, is due to its simplicity, but still it's technically easier for someone to get into a new C library than it is a D library because they have to scour source code/online documentation instead of being able to do the comfy thing and stay within their text editor/IDE.

To add to this: C and C++ tooling are capable of parsing and evaluating macros to a decent level, yet D tooling can't even figure out simple templates, and often can't even figure out return types when you use an auto variable. We have plenty of room for growth, but I fear this is only a bandaid without a proper compiler-as-a-library to build with.

October 28, 2021

On Thursday, 28 October 2021 at 11:03:35 UTC, SealabJaster wrote:

>

I think this sort of ties into that discussion about fringe languages and polyglot programmers.

Yes, more advanced IDEs have made it possible for me to have fun with more languages for sure! Less cognitive/memory load. So advanced IDEs enable more polyglot programming.

Maybe "good programmers" in the future switch between many languages with little loyalty. I don't know. Anyway, if this becomes a trend, then it also would makes fringe languages that are good in particular domains more interesting.

I can't predict, but it is possible.

October 28, 2021

On Tuesday, 26 October 2021 at 06:05:08 UTC, bauss wrote:

>

The only problem I see when versioning the standard library is that some packages will rely on specific versions of the standard library and it could make it difficult to use packages that rely on different versions of the standard library.

You’re saying it like it’s not a big deal but I’m afraid it’s going to be a huge source of pain. Imagine not being able to get some DateTime, or Complex, or File from one package and pass it to another because one depends on std1 and the other depends on std2. Or imagine dealing with different versions of the same exception class. It appears to me that versioning the standard library is a bullet train straight to dependency hell.

October 28, 2021

On Thursday, 28 October 2021 at 11:30:18 UTC, Ogi wrote:

>

On Tuesday, 26 October 2021 at 06:05:08 UTC, bauss wrote:

>

The only problem I see when versioning the standard library is that some packages will rely on specific versions of the standard library and it could make it difficult to use packages that rely on different versions of the standard library.

You’re saying it like it’s not a big deal but I’m afraid it’s going to be a huge source of pain. Imagine not being able to get some DateTime, or Complex, or File from one package and pass it to another because one depends on std1 and the other depends on std2. Or imagine dealing with different versions of the same exception class. It appears to me that versioning the standard library is a bullet train straight to dependency hell.

Yes you're probably right that it is a much greater issue than I first claimed.

I should probably have emphasized that it is a massive issue!

October 28, 2021
On Thursday, 28 October 2021 at 08:50:31 UTC, Robert burner Schadek wrote:
> I think this version schema is fundamentally wrong and looks to me like a quick way to the D1 standard library mess.

The problem there was you couldn't use the two together. The point of this versioning thing is to try to come up with a scheme where you CAN use them together.

October 28, 2021

On Thursday, 28 October 2021 at 10:38:20 UTC, Robert burner Schadek wrote:

>

I rather would see people being annoyed by safe being the default and
forced GC usage, than see nobody on the forum, because nobody cares anymore.

Although I don't favour D's GC or approach to memory management I do agree that drawing a line in the sand is more important. Letting the wind take control, ending up with a fragmented eco system is not a good option.

But if you fully embrace higher level "semantics" then D also needs to set a vision that provides more of a higher level language (like adding better constructs for functional programming).

I think Perl waited too long before changing. Perl was big around 2000, and essentially allowed Python to take over. Python made the right decision to make breaking changes and fix unicode strings, such weaknesses opens up for a take-over.

If you have weaknesses in areas where you aim to be best, well, you need to fix them before somebody else does it. "Wait and see" is usually too late (because of the inertia).