August 17, 2022

On Wednesday, 17 August 2022 at 19:17:40 UTC, monkyyy wrote:

>

when I spefically call dub bad

But "Dub is bad" falls into the same category. It's too vague and won't lead to a productive discussion. Something like this would have a chance of pushing things forward:

  • Dub doesn't do [feature]. This is a problem because [how it impacts your projects].
  • When I use Rust, I can take advantage of [feature]. They implement it by [implementation details].
  • We could do this by [suggested changes].

The debate in this case would be whether the feature should be added to Dub and if so, how that should be done.

August 17, 2022
On Wednesday, 17 August 2022 at 19:31:06 UTC, matheus wrote:
> On Wednesday, 17 August 2022 at 16:58:02 UTC, Paul Backus wrote:
>> ...
>> For example, if I rename a variable or a function, I can rebuild the project with :make and then use a command like `:cdo s/oldName/newName/g` to iterate over the resulting errors and replace the old name with the new name. This is a lot faster than having to look at the file + line number of each error message and navigate there by hand.
>
> I may have misunderstood you, but usually in an IDE, all the references of the modified/renamed "thing" i.e: variable, function, method etc. will be replaced automatically through the project or an option will be given for this.
>
> I barely use IDE either, but I have seen this feature.

Yes, I'm aware that this feature exists in many IDEs, at least for other languages. Obviously if your tooling has a dedicated "global rename" feature, you should use that instead of messing around with error messages.

However, as far as I know, nothing like this exists for D, at least not yet. So being able to approximate it with the tools we *do* have (Vim, D compiler) is a useful stopgap.
August 17, 2022

On Wednesday, 17 August 2022 at 20:31:50 UTC, bachmeier wrote:

>

On Wednesday, 17 August 2022 at 19:17:40 UTC, monkyyy wrote:

>

when I spefically call dub bad

But "Dub is bad" falls into the same category. It's too vague and won't lead to a productive discussion. Something like this would have a chance of pushing things forward:

  • Dub doesn't do [feature]. This is a problem because [how it impacts your projects].
  • When I use Rust, I can take advantage of [feature]. They implement it by [implementation details].
  • We could do this by [suggested changes].

The debate in this case would be whether the feature should be added to Dub and if so, how that should be done.

Ive definitely made a list; and I have my build script

August 18, 2022

On Wednesday, 17 August 2022 at 16:00:58 UTC, Paul Backus wrote:

>

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:

Cannot accesse
https://gist.github.com/pbackus/12e407ae96a54ced6ea9b3f72be25264,

I can't access gist.github. Can you provide another GitHub address?

August 18, 2022

On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:

>

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:

>

This is a longer than average post where I mostly express personal concerns about things that you probably heard 100 of times...

One problem is that this type of post is too vague. Saying the tooling is "disappointing" is the equivalent of saying you think the compiler should be improved. What you say might well be true, but it's hard to know exactly what you are saying.
.....

For many years I've heard here that IDEs are not a priority issue and that vim is enough for everyone. And so we are here.

Is anyone of the new generation using Vim for Windows? I don't think so.

Specifically I would say about the terrible support for visual debugging on Windows, it really only exists in Visual D (many thanks for it) which was released relatively recently.

There is a similar, though less acute, problem with profiler.

August 18, 2022

On Thursday, 18 August 2022 at 06:46:49 UTC, Siemargl wrote:

>

For many years I've heard here that IDEs are not a priority issue and that vim is enough for everyone. And so we are here.

Plenty of people note that they use vim, but I don't believe anyone here has been claiming it's enough for everyone.

>

Is anyone of the new generation using Vim for Windows? I don't think so.

I would expect few people primarily developing on Windows use vim. Even older generations.

>

Specifically I would say about the terrible support for visual debugging on Windows, it really only exists in Visual D (many thanks for it) which was released relatively recently.

There is a similar, though less acute, problem with profiler.

I want to reiterate what I posted above: the D ecosystem has developed organically over the years as contributors have put out their projects. There have been no resources to oversee and guide it nor to implement it. Visual D, code-d & serve-d, and all of the IDE and editor plugins and syntax files have been part of that.

This was a functioning and useful model once upon a time, but it stopped being that a while ago. We recognize that and we intend to change it. Improving the user experience is a high priority goal. It's not going to happen overnight. We have a number of hurdles to get over in order for things to start happening, but we are moving in that direction.

Please keep an eye on the Announce forum, the blog, our twitter account, and/or our YouTube channel. I'll be documenting progress in the summaries of our foundation meetings and in general announcements and news videos. Hopefully by this time next year we'll have our ecosystem management team in place, and they'll be up and running overseeing the work that needs to be done.

August 18, 2022

On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:

>

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:

>

This is a longer than average post where I mostly express personal concerns about things that you probably heard 100 of times...

One problem is that this type of post is too vague. Saying the tooling is "disappointing" is the equivalent of saying you think the compiler should be improved. What you say might well be true, but it's hard to know exactly what you are saying.

The first step to improvement is being clear about what the tooling should do. Then, importantly, reference tooling that works for other languages and provide explicit information about how to do that for D. Really, it doesn't help to talk about "tooling". To push for change, you should pick the small part of the tooling that is causing you the biggest headaches and provide clear steps for improving that.

Correct. As it usually happens, the matter got lost in emotional waves.

What I am missing as a casual D user is a working autocompletion with doc hints akin to what one can see in bloated IntelliJ IDEs. IntelliJ Scala plugin is a great example of how a proper language support can be done. It is so good that IntelliJ is exclusively advised and used for Scala development these days. It saves time, it helps you to navigate in a huge project and what's most important learn the language.
For D the best thing we have is the code-d plugin for VSCode. For Vim we have personal hacks. The code-d plugin is good, and of course it could be better.

August 18, 2022

On Thursday, 18 August 2022 at 06:46:49 UTC, Siemargl wrote:

>

On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:

>

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:

>

This is a longer than average post where I mostly express personal concerns about things that you probably heard 100 of times...

One problem is that this type of post is too vague. Saying the tooling is "disappointing" is the equivalent of saying you think the compiler should be improved. What you say might well be true, but it's hard to know exactly what you are saying.
.....

For many years I've heard here that IDEs are not a priority issue and that vim is enough for everyone. And so we are here.

Is anyone of the new generation using Vim for Windows? I don't think so.

Specifically I would say about the terrible support for visual debugging on Windows, it really only exists in Visual D (many thanks for it) which was released relatively recently.

There is a similar, though less acute, problem with profiler.

Not only the new generation but the guys in late 20s (my colleagues) don't use vim but use IntelliJ or VSCode exclusively to do everything including console git magic.

Getting new people on board is hard when you can't provide adequate accessibility. Persuading experienced engineers to use D is impossible (I tried) once they see that the language IDE support comfortably sits on hacks and one-man tools for years. This is the first sign of the immaturity and a confident "no" for developing anything serious beyond shell scripting.

August 18, 2022

On Thursday, 18 August 2022 at 07:31:57 UTC, Mike Parker wrote:

>

On Thursday, 18 August 2022 at 06:46:49 UTC, Siemargl wrote:

>

[...]

Plenty of people note that they use vim, but I don't believe anyone here has been claiming it's enough for everyone.

[...]

I don't feel especially good to be the complainer instead of doing something to change things for the better. If only I had 24h in a day. But it's a relief to know the things will be addressed.

August 18, 2022

On Thursday, 18 August 2022 at 08:01:15 UTC, tastyminerals wrote:

>

I don't feel especially good to be the complainer instead of doing something to change things for the better. If only I had 24h in a day. But it's a relief to know the things will be addressed.

It's fine. Consumers of D shouldn't have to expect to contribute, and they should expect that any complaints they have about the state of things will be addressed in one form or another.

The problem is that we aren't there yet. We're in this chaotic limbo where we're moving along as if we're still a community of contributors, which we haven't been for a long time, while valid complaints from consumers go unaddressed.

We'll get there eventually.