Jump to page: 1 24  
Page
Thread overview
D tooling is disappointing
Aug 17, 2022
tastyminerals
Aug 17, 2022
Mike Parker
Aug 17, 2022
Paul Backus
Aug 17, 2022
H. S. Teoh
Aug 17, 2022
Paul Backus
Aug 17, 2022
Adam D Ruppe
Aug 17, 2022
matheus
Aug 17, 2022
Paul Backus
Aug 18, 2022
zjh
Aug 18, 2022
Paul Backus
Aug 18, 2022
zjh
Aug 17, 2022
bachmeier
Aug 17, 2022
monkyyy
Aug 17, 2022
bachmeier
Aug 17, 2022
monkyyy
Aug 18, 2022
Siemargl
Aug 18, 2022
Mike Parker
Aug 18, 2022
tastyminerals
Aug 18, 2022
Mike Parker
Aug 18, 2022
tastyminerals
Aug 18, 2022
tastyminerals
Aug 18, 2022
Alexandru Ermicioi
Aug 20, 2022
jordan4ibanez
Aug 20, 2022
Ali Çehreli
Aug 20, 2022
jordan4ibanez
Aug 23, 2022
bauss
Aug 22, 2022
Laurent Tréguier
Aug 22, 2022
Tejas
Aug 22, 2022
JN
Aug 23, 2022
Paulo Pinto
Aug 24, 2022
zjh
August 17, 2022

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

Many of us use vim for quick scripting and if so, you know about handy vim-dutyl plugin. If you're a MacVim user, you might already know about sad d-completion-daemon status in MacPorts. There is no maintainer for the only usable D autocompletion plugin for Vim. Truth to be told, the actual vim-dutyl looks abandoned too.

I also use VSCode on Mac, it has a great code-d extension installed. But unfortunately, it doesn't really work popping up with notorious

>

Could not initialize dub for /Users/tasty/Dev/document-sender-app. Falling back to limited functionality!
Cannot use dub with invalid configuration

Tried fixing it but without success. I had some issues with the code-d plugin on Windows some years ago too. Then it was updated, and now it works fine. The problem is that I use Mac for daily work and I love scripting, and I believe D is an excellent scripting language.

Now, here I would like to step back and just express that I am, a casual D user, is pretty sad by the state of the D tooling. It's nowhere close to much younger languages that have a decent IDE support. Now, I am confident that whoever works hard today on D is aware of this. And yet I think it is important to stress again, that great IDE support, autocompletion, and doc hints for such a rich standard library as Phobos are very important. It is the lobby, the entrance gates to any newcomer interested in learning the language. And we are not even talking about productivity gains that proper language support can deliver.

If someone asks me about current D language tooling, I would have to confess that it is lackluster. But, hey, some of us use nano to program in D, right?

Having read numerous posts about how D is not popular, the community is small, there is not enough people and such. I hope the people who invested far more than me into this great language, focus on something that can be achieved with the resources that you have right now. Because, you know, it feels sad to read dozens of comments about how better to implement some language feature in the upcoming DIP while looking at the state of its support in IDE. And let's not forget that D is >20 years old. I wish someone at DConf talked about this mundane, casual but really important problems that D has.

This is nowhere a critic to the tons of work that WebFreak001 does, but rather feedback or probably an accumulated disappointment with things that I believe can be easily tackled with a community effort.

August 17, 2022

On 8/17/22 6:45 AM, tastyminerals wrote:

>

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

I appreciate your position, and hear what you are saying.

This is by no means a response or excuse, just possibly an explanation.

I think many many D users are hard-core coders that come from C/C++ background, many of them old timers that use old editors they are comfortable with. For me, the default vim code completion is enough. I don't use VSCode, though I have used it to teach a D class, and it works well enough on windows (with the occasional issue adding dub dependencies).

I wish that more people spent time on tooling, and I think this is where having a large organization invested in maintaining a language helps -- it just takes more warm bodies to throw at such problems. But personally, I can't say it's a demotivator. Of course, I'm more heavily invested in the D language than most.

I hope the situation gets better, but I don't see it happening except organically. Rainer has maintained Visual D for a long time, WebFreak does VSCode, I think someone else posted about support for Intellij, so the volunteers are there. My recommendation is to support them with some feedback, help with development, and maybe some donations as well.

-Steve

August 17, 2022

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

>

This is nowhere a critic to the tons of work that WebFreak001 does, but rather feedback or probably an accumulated disappointment with things that I believe can be easily tackled with a community effort.

The problem as I see it is that we long relied on people rolling up their sleeves and doing the things that need to be done. That was a major characteristic of the D community. In that environment, people work on what they need or what interests them. That was great for several years and allowed the ecosystem to get off the ground, but we're long past the time where relying on that sort of community self-direction is viable. Something should have been done much sooner. But it wasn't, and here we are.

But now, yes, it's on the radar. Improving the user experience is a big item in the vision document. If you saw my DConf talk, I mentioned the plan to assemble an ecosystem management team. Their raison d'etre will be to establish priority projects, provide direction, and ensure the priority ecosystem tasks they lay out get seen through to the end. It will be a team of mostly volunteer managers overseeing volunteer contributors, so it will still be subject to some of the same issues that arise with any group of volunteers, but my hope is that it provides a clear path to onboarding and motivating more contributors while gradually improving the user experience and the overall state of the ecosystem.

That's still around the next bend, though. First we need to get some other parts of the house in order. That's what we're working on right now. We still aren't in a position such that things are moving forward as quickly and efficiently as anyone would like, but we are making progress and things should start picking up steam by the end of this year.

August 17, 2022

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

>

Many of us use vim for quick scripting and if so, you know about handy vim-dutyl plugin. If you're a MacVim user, you might already know about sad d-completion-daemon status in MacPorts. There is no maintainer for the only usable D autocompletion plugin for Vim. Truth to be told, the actual vim-dutyl looks abandoned too.

I use Vim for D programming with dmdtags for navigation, some simple config files for compiler integration and quick doc access, and Vim's built-in completion features. It's not as polished an experience as you'd get from a real IDE, but it's enough to get work done.

August 17, 2022
On Wed, Aug 17, 2022 at 04:00:58PM +0000, Paul Backus via Digitalmars-d wrote:
> On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:
> > Many of us use vim for quick scripting and if so, you know about handy [vim-dutyl](https://github.com/idanarye/vim-dutyl) plugin. If you're a MacVim user, you might already know about sad [d-completion-daemon status in MacPorts](https://i.imgur.com/qUtRpG3.png). There is no maintainer for the only usable D autocompletion plugin for Vim. Truth to be told, the actual vim-dutyl looks abandoned too.
> 
> I use Vim for D programming with [`dmdtags`][1] for navigation, [some simple config files][2] for compiler integration and quick doc access, and Vim's built-in completion features. It's not as polished an experience as you'd get from a real IDE, but it's enough to get work done.
[...]

I also use Vim, occasionally with dmdtags (only for large projects). I don't bother with compiler integration because I use SCons for builds, and it's fast enough to just suspend Vim with ^Z and run scons by hand. Or occasionally `dmd -unittest -run` when I need to work on one specific module and have fast turnaround time.

Unfortunately, that means I'm totally useless when it comes to "real" IDEs, and I wouldn't even know where to begin to contribute to D's tooling.  It's hard to get motivated to contribute something I don't even use, and harder yet to not just make a hash of things when I try to contribute anyway.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
August 17, 2022
On Wednesday, 17 August 2022 at 16:13:01 UTC, H. S. Teoh wrote:
> I also use Vim, occasionally with dmdtags (only for large projects). I don't bother with compiler integration because I use SCons for builds, and it's fast enough to just suspend Vim with ^Z and run scons by hand. Or occasionally `dmd -unittest -run` when I need to work on one specific module and have fast turnaround time.

In my experience, the main benefit of compiler integration isn't speed, it's having Vim's quickfix list automatically populated with the compiler's error messages, which allows you to use commands like :cnext, :cprev, and so on for navigation.

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.
August 17, 2022
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

Worth noting that configuring this is simple; you can make a makefile, of course, or just `:set makeprg=dmd\ -i\ %` and find significant joy.
August 17, 2022

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.

August 17, 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.

>

say what spefically is bad
But when I spefically call dub bad people get squeamish; and like all the projects are volunteer based and poeple defend such things naturally. It would just be hard to be spefic for most people who are conflict avoident

August 17, 2022
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.

Matheus.
« First   ‹ Prev
1 2 3 4