On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
After months doing a different project, i need a programming
language for a new client with specific needs. D comes to mind.
As usual that involves downloading the compiler (dmd and ldc).
[...]
My personal opinion: Too much in the D landscape is so
individualist and not properly cross platform tested, that it
results in pure frustration for the end developer.
If you write OOP with few templates like often done in C#,
Delphi, or more declarative style like Go or C, then DCD works
fine. Your frustration probably comes from the fact that popular
techniques in D are not supported by DCD: Template
Metaprogramming and CTFE. They are not well supported because
they "just" require to have a compiler built in the completion
engine. You can also add "auto everywhere" to the problems
(plenty of std.algorithm, std.typecons, std.range are not
supported at all)
This problem won't be fixed (ever: i'm honnest since i work a bit
on dparse dcd etc. i didn't see the "big" thing coming) so the
best advice i can give you is "do not to use the things that are
not supported by DCD in the public API". Use them for private
internal details. And avoid "auto".
Now, let's talk about the bugs. The important things in DCD are
done by a library called D-Symbol. This library needs more love.
https://github.com/dlang-community/dsymbol/pulls. There are 5
valid bug fixes opened since the end of the summer and that
haven't been handled. A movement had started in July / August but
apparently has stopped in September for some reasons.
I don't think that complaining about specific editor plugins will
help. People who write these plugins have adapted DCD to their
product but they cant just sit and wait that the completion gets
better. At some point if you work on a IDE you have deal with
certain low level language stuff. It's not just about piping
process.
(Note: this paragraph is addressed to editor plugins and IDE
writers).
