www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D tooling is disappointing

reply tastyminerals <tastyminerals gmail.com> writes:
_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](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 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.
Aug 17 2022
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Aug 17 2022
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
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.
Aug 17 2022
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.

[1]: 
https://forum.dlang.org/post/mailman.72.1630470149.21945.digitalmars-d-announce puremagic.com
[2]: 
https://gist.github.com/pbackus/12e407ae96a54ced6ea9b3f72be25264
Aug 17 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
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
Aug 17 2022
parent reply Paul Backus <snarwin gmail.com> writes:
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.
Aug 17 2022
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
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.
Aug 17 2022
prev sibling parent reply matheus <matheus gmail.com> writes:
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.
Aug 17 2022
parent Paul Backus <snarwin gmail.com> writes:
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.
Aug 17 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
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?
Aug 17 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 18 August 2022 at 02:30:50 UTC, zjh wrote:

 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?


Here is a link to the same content on Pastebin:

https://pastebin.com/qgGeT6bb

There are 3 files, separated with `----------`.
Aug 18 2022
parent zjh <fqbqrr 163.com> writes:
On Thursday, 18 August 2022 at 11:18:29 UTC, Paul Backus wrote:

 On Thursday, 18 August 2022 at 02:30:50 UTC, zjh wrote:...


Thank you for `sharing`.
Aug 18 2022
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.
Aug 17 2022
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
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
Aug 17 2022
parent reply bachmeier <no spam.net> writes:
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.
Aug 17 2022
parent monkyyy <crazymonkyyy gmail.com> writes:
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
Aug 17 2022
prev sibling next sibling parent reply Siemargl <inqnone gmail.com> writes:
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.
Aug 17 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Aug 18 2022
parent reply tastyminerals <tastyminerals gmail.com> writes:
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.
Aug 18 2022
parent Mike Parker <aldacron gmail.com> writes:
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.
Aug 18 2022
prev sibling parent tastyminerals <tastyminerals gmail.com> writes:
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.
Aug 18 2022
prev sibling next sibling parent tastyminerals <tastyminerals gmail.com> writes:
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.
Aug 18 2022
prev sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:

 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.


Well this list could be improved/implemented (note this may be 
obsolete since I haven't done much D programming recently):
1. Autocompletion
There is already a rudimentary autocompletion support in language 
server projects albeit rudimentary, due to the fact that the LSP 
cannot infer in all cases what kind of type is the field/variable 
from which you try to invoke a method, or access a field. So 
compiler would be a tremendous help here if it could infer the 
type of variable for which field/method autocompletion is done, 
considering that D usually is heavy on templates. Note that this 
inference should work on lambda heavy code as well.

2. Automatic import of symbol and import cleanup
It is really annoying when you need to manually write import 
statements to include a symbol from a module. It would be nice 
given some external knowledge (dub deps for example) that IDE 
would first autocomplete list of symbols you want to use, and 
when a symbol never imported prior to now is used, it will 
automatically import it (write an import statement for that 
symbol).
Cleanup part is useful when you don't use a symbol anymore and 
therefore it is not required to import it in respective scope.
No, `import std` is not a solution.

3. Refactoring utilities
- Interface implementation
There is already some rudimentary implementation, but not enough. 
 From what I remember these implementations were struggling a lot 
with classes that implemented templated interfaces.

- Symbol renaming
Same issue as others. No reliable way to rename a field/method in 
a class. You have always a chance to either rename more places 
than you need, or less than you need, resulting in a compilation 
error, or worse in accidental renaming of innocent variable in an 
irrelevant function (hello javascript).

- Member movement
More advanced use though. Mainly for static methods in 
structs/classes, and module level elements. You'd like to move a 
variable/method/function from one class/struct/module to another 
one, and expect that all uses of said subject to be rewritten to 
point to new struct/class/module that subject was moved to.

- Inlining of functions
Given a function/method, when inlining it, expect that all places 
where this method/function is invoked should be replaced with 
it's contents, adapted to the calling site.

- Code extraction
You have to manually extract now, interfaces, abstract classes, 
and object delegates (oop pattern).

Please note that these are general specifications of what each 
feature should do. It can be even more refined for D use cases.
Aug 18 2022
prev sibling next sibling parent reply jordan4ibanez <jordan4ibanez002 gmail.com> writes:
The only real problem I have with D tooling is that when I open 
large files, it slows to a crawl. I've never heard vscode max out 
my pc's fans before
Aug 19 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/19/22 18:39, jordan4ibanez wrote:

 The only real problem I have with D tooling is that when I open large 
 files, it slows to a crawl. I've never heard vscode max out my pc's fans 
 before
 


Same problem with d-mode in Emacs. Recommended advice was to use small 
files. (I am not revealing who said that. :) )

Ali
Aug 19 2022
next sibling parent jordan4ibanez <jordan4ibanez002 gmail.com> writes:
On Saturday, 20 August 2022 at 01:54:40 UTC, Ali Çehreli wrote:

 On 8/19/22 18:39, jordan4ibanez wrote:

 The only real problem I have with D tooling is that when I 
 open large files, it slows to a crawl. I've never heard vscode 
 max out my pc's fans before
 


 Same problem with d-mode in Emacs. Recommended advice was to 
 use small files. (I am not revealing who said that. :) )

 Ali


Oh I understand that haha. I have a Noctua NH-D15 with Thermal 
Grizzly on top of a 5600x at 4.4GHz and a 15,000 line file was 
making my fans ramp up to 100%. I was shocked. Not really because 
of the fans but because everything else was going smoothly, very 
strange. You would think such a high cpu usage would be slowing 
the whole system down. I'm not sure why it's happening. Perhaps 
whatever the logic loop is in the executable is recursing on 
itself? Maybe it gets stuck trying to run logic checks on things 
that aren't changed? I am just spitballing ideas
Aug 19 2022
prev sibling parent bauss <jacobbauss gmail.com> writes:
On Saturday, 20 August 2022 at 01:54:40 UTC, Ali Çehreli wrote:

 On 8/19/22 18:39, jordan4ibanez wrote:

 The only real problem I have with D tooling is that when I 
 open large files, it slows to a crawl. I've never heard vscode 
 max out my pc's fans before
 


 Same problem with d-mode in Emacs. Recommended advice was to 
 use small files. (I am not revealing who said that. :) )

 Ali


That's problematic with importC though, since you don't have 
control over the initial source size.
Aug 23 2022
prev sibling next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <dlang laurent.treguier.email> writes:
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..._

 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 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.


I don't hang around this forum much anymore, but as luck would 
have it I took a peek today and saw this recent post.

I used to work on D tooling myself, precisely because I also 
thought it was not good enough, and unlike a good chunk of the D 
folks, I love having some fancy IDE do all kinds of things like 
context-sensitive auto-completion, project-wide symbol renaming, 
dynamic linting without having to compile anything...

In my opinion, there are 2 major issues, both of them have been 
touched upon in this thread I think.

One of them is the small community that doesn't mind the lack of 
advanced tooling, paired with a strong DIY mentality. Many people 
new to D probably faced this exact issue, they come and realize 
the tooling is subpar, then get told to work on it themselves if 
they want something better, and quickly move on to greener 
pastures.

The second is the language itself. D code is often littered with 
a lot of template-heavy code, which makes type inference 
difficult, and can thus cripple the capabilities of the editor as 
tons of variables have opaque types for which auto-completion and 
linting become impossible. The syntax itself had a few tricks up 
its sleeve as well IIRC, I remember relying sometimes on code 
conventions for my syntax highlighting.

I have no clue where serve-d is at currently, but back when I was 
working on D tooling, both it and my language server were using 
the same trio of DCD, D-Scanner and DFMT, which themselves had 
their own quirks as well, adding an extra layer of brittleness.

In order to go beyond their limits, at some point I tried 
experimenting with using DMD as a library, in the hope to get 
template resolution and such, however this wasn't easily done 
either, because DMD was never meant to be used inside of a 
language server. Firstly, it has a global state that doesn't play 
well with the nature of language servers (long-running processes, 
just like web servers). And secondly, it sometimes uses stdout, 
which is typically what language servers use communicate to 
editors, meaning DMD would have to be patched in order to be 
technically usable (without even thinking about how to then use 
its capabilities).

The last idea I had was to use tree-sitter [1] to make a server 
"from scratch", without using a tool for something it was not 
meant to be used for, and only using a parsing library. I never 
finished my tree-sitter syntax file for D though, some specific 
string syntaxes had to be done in code directly outside of the 
syntax file, and as I was working on another project, I gave up.

The problem of D's tooling is old, and will probably never be 
completely solved. As you said at the start of your post, this is 
hardly the first time this comes up. I predict it's also not 
going to be the last.

If I ever came back to D, I would probably try to use tree-sitter 
again to make some new D tooling: it is made specifically for 
parsing code at every keystroke in an editor while being embedded 
without any dependency. That's my conclusion for anyone crazy 
enough to dive into this...

[1] https://tree-sitter.github.io/tree-sitter/
Aug 22 2022
next sibling parent Tejas <notrealemail gmail.com> writes:
On Monday, 22 August 2022 at 10:11:01 UTC, Laurent Tréguier wrote:

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

 [...]


 I don't hang around this forum much anymore, but as luck would 
 have it I took a peek today and saw this recent post.

 [...]


There is already a (WIP) grammar for D via tree-sitter 
https://github.com/CyberShadow/tree-sitter-d

Someone also wrote bindings for it(tree-sitter, not the grammar)

https://github.com/aminya/d-tree-sitter
Aug 22 2022
prev sibling parent reply JN <666total wp.pl> writes:
On Monday, 22 August 2022 at 10:11:01 UTC, Laurent Tréguier wrote:

 The problem of D's tooling is old, and will probably never be 
 completely solved. As you said at the start of your post, this 
 is hardly the first time this comes up. I predict it's also not 
 going to be the last.


I don't think you can truly "solve" this problem in a language 
that has templates. Look at C++, it has much bigger tooling 
budget than D and still most IDEs have only rudimentary 
autocompletion that breaks as soon as any templates come into 
play. I think the issue is that you can even think of a solution 
that will work for a template, like array\<int>, but in reality 
underneath that array\<int> is a scary type of 10 or more 
templates nested together. The fact that many methods return auto 
type doesn't help either.

That said, when autocomplete works in D, it usually works better 
than comparable C++ autocomplete.
Aug 22 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 22 August 2022 at 22:24:23 UTC, JN wrote:

 On Monday, 22 August 2022 at 10:11:01 UTC, Laurent Tréguier 
 wrote:

 The problem of D's tooling is old, and will probably never be 
 completely solved. As you said at the start of your post, this 
 is hardly the first time this comes up. I predict it's also 
 not going to be the last.


 I don't think you can truly "solve" this problem in a language 
 that has templates. Look at C++, it has much bigger tooling 
 budget than D and still most IDEs have only rudimentary 
 autocompletion that breaks as soon as any templates come into 
 play. I think the issue is that you can even think of a 
 solution that will work for a template, like array\<int>, but 
 in reality underneath that array\<int> is a scary type of 10 or 
 more templates nested together. The fact that many methods 
 return auto type doesn't help either.

 That said, when autocomplete works in D, it usually works 
 better than comparable C++ autocomplete.


Visual Studio, QtCreator and Clion are quite good at it.

Visual Studio can since 2017 version even customize the template 
parameters for a specific set of types when debugging what the 
template might look like.

https://devblogs.microsoft.com/cppblog/template-intellisense/
Aug 23 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
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..._

 Many of us use vim for quick scripting and if so, you know 
 about handy [vim-dutyl](https://github.com/idanarye/vim-dutyl) 
 plugin.



I think an excellent D's `vim` `plug-in` will greatly increase 
the adoption rate of `D`.
Aug 23 2022