www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dscanner - DCD - Dfix ... Editor support or the lack of it.

reply Benny <benny.luypaert rhysoft.com> writes:
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).

So, lets install Visual Studio Code:

* Code-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).
   - ... and nothing else...


So lets try the next plugin:


* Serve-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).
   - ... and nothing else...


Frustration level increasing. Lets try the next one:


* D-Language Plugin:
   - Syntax highlight *check*
   - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).
   - ... and nothing else...


Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do 
not properly work or some other issue.


Then lets try IntelliJ Community Edition. After a long time 
getting all the dependancies and compiling them... Dscanner - DCD 
( client and server ) - Dfix ...


* D Language Plugin:
   - Syntax highlight *check*
   - Way too many items like writefln, import etc all being marked 
as unknown. Clearly wrong.
   - ... and nothing else...
   - Socket error (std.socket.xxx) on closing IntelliJ


Conclusion is that it feels like the whole D infrastructure is 
very, very poorly supported.

Other issues like delays that some of the D plugins seem to 
introduce:

* Like "loading ..." popups that do nothing but always show up ( 
Visual Studio Code )
* Like pressing "dot" expecting a response, waiting 2 seconds and 
then finally something happening ( IntelliJ plugin ) but simply 
dumping every possible name and variable ( zero intelligent code 
support )

I assume that this is again broken DCD or Dscanner.

And no, no errors in the console of VSC or anything like that.

Let me summarize my personal D editor experience in the last 1+ 
year.

* Attempts at getting D editor support going: 6 or 7.
* Amount of times things worked out of the box. One! And this was 
limited to about a few minutes and after that all suggestions 
broke again.
* Amount of times dscanner or dcd or other plugins broke because 
of DMD newest version broke: 4
* Tested on different machines: 4! They all have one thing in 
common: Windows 10
* Tested on different Windows installations: 3
* Tested on different "version" of Windows 10: 3
* Amount of times complaining to the plugin authors: Too many to 
count.
* Time spend on these tests / issues: Easily 50 hours or more.
* Frustration level: Again, like each time before EXTREME!

Please do not give me the company line that i need to report 
issues. I did so many times. It is tiring playing guinea pig, 
complaining and reporting, waiting for things to get fixed and 
still seeing things break again or simply not working properly.



working plugins for the above mentioned editors but D is always 
that frustrating problem child. And i can not blame the plugin 
authors because the issues always seem to stem from the D plugins 
( dcd, dscanner, ... ).

Like dscanner changing its binary location between builds from 
folder root to /bin folder, breaking the plugin authors there 
system as it expected it in the folder root.

Maybe things work great in a few very specific editor but in my 
personal experience, D its editor support is non stop 
frustrating. And i suspect that this complaint is not new.

Clearly there is infrastructure in place for automated testing 
the compiler but it feels like there is a total lack of 
infrastructure for everything that surround it. Beyond maybe a 
few editors that the core team uses?

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.
Jan 25 2018
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
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).

 [...]
While the several tools out of the box do not work well together, the involved developers Delphi...). I also struggled with the problem how to configure DCD in the DLang plugin for IntelliJ today. This might be the reason for the items marked as unknown. I created an issue here https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356 The DLang ecosystem is getting better and better and you also can help by testing, writing constructive issues or even providing fixes. Kind regards André
Jan 25 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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.
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).
Jan 25 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote:


 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.
Maybe there has been a misunderstanding but i am not talking about CTFE or Metaprogramming. Basic OOP does not even work. And that is after testing D plugins going back a year or more with several DMD/Dub releases at the times. On Thursday, 25 January 2018 at 17:32:24 UTC, Andre Pany wrote:
 While the several tools out of the box do not work well 
 together, the involved developers

 Delphi...). I also struggled with the problem how to configure 
 DCD in the DLang plugin for IntelliJ today.
 This might be the reason for the items marked as unknown.
 I created an issue here 
 https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356
Most of the plugins mentioned here are also made by community or individual members. The issue ends up being that its not so much the Editor plugins that create the problems but whatever language server that is behind it. Please look up several of the plugins there originals and you will see a lot are made by individuals? For instance OmniPascal... In my eyes its not the plugin authors there problem because they need the official tooling support from D. Compile a set of tools and notice how many deprecated calls show up. Or issues when a new D compiler version gets released. Or a new Dub version that breaks the tooling left or right. This is what i mean by "not properly cross platform tested". There seems to be a total lack for any tool "chain testing" beyond individual stand alone tests. How else does one explain the constant issues i have personally faced ( and reported ). I have been in the position to use D in several projects but in my experience its not worth taking the risk ( when issues like this keep happening ). This also affect not just the tooling but also the whole public dub packages. When a new language like Rust is more tooling friendly and its extended platform integrates great with the editor plugins... Its not like Mozilla has hundreds of Engineers on Rust. Its extreme highly community driven. It seems to be that they understand the value of better tooling and friendly platform support. Whereas its my impression that a lot of resources get focused on making D its compiler / language better but the rest seems to be ignored. I am sorry if this sounds cruel but for now D is on the back burner and my next project will probably be in Rust. Its a real shame but when even things like editor plugins barely work it makes me doubt the rest of the platform. And i do not even like Rust as a language but one can not deny it is a better supported platform. One can only express their hope that there will be a revitalization in the D management and the priorities. From my point of view it feels like D is falling behind when compared to other languages like Rust/C++/Go/... D really needs a project leader that knows the language and starts focusing the resources beyond just the compiler. Anyway, good luck in the future.
Jan 25 2018
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
 When a new language like Rust is more tooling friendly and its 
 extended platform integrates great with the editor plugins... 
 Its not like Mozilla has hundreds of Engineers on Rust. Its 
 extreme highly community driven.
Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor.
 One can only express their hope that there will be a 
 revitalization in the D management and the priorities. From my 
 point of view it feels like D is falling behind when compared 
 to other languages like Rust/C++/Go/... D really needs a 
 project leader that knows the language and starts focusing the 
 resources beyond just the compiler.
It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case.
Jan 25 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Thursday, 25 January 2018 at 21:42:33 UTC, bachmeier wrote:
 Even one paid developer makes a big difference. You don't need 
 hundreds. Making the problem harder is that many current D 
 users don't have an interest in those tools. Therefore you're 
 drawing from a small pool of part-time volunteer labor.
 
 It's entirely up to the community. This is not something Walter 
 or Andrei should be concerned with. I had hoped the D 
 Foundation would lead to a better organization of the 
 community, but to this point, that doesn't seem to be the case.
It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees. I just looked up some community sourced project: Nim gets on average 1500 to 2000$ per month Crystal seems to be doing 2000 to 3000$ per month That is only counting salt.bountrysource and no direct donations. Just noticed this thread on Reddit and somebody asked about D. http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ According to the author off the ranking: 18. Rust 0.73% 58. D... 0.047% No wonder that Rust seems to be more popular and D seems to struggle in popularity.
Jan 25 2018
parent reply bachmeier <no spam.net> writes:
On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
 It was my impression that D Foundation has sponsoring from 
 different companies. No clue how much but its strange to run a 
 Foundation and not being able to pay one or more full time 
 employees.
If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me.
Jan 25 2018
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 25 January 2018 at 22:21:18 UTC, bachmeier wrote:
 On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
 It was my impression that D Foundation has sponsoring from 
 different companies. No clue how much but its strange to run a 
 Foundation and not being able to pay one or more full time 
 employees.
If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me.
No one has. The work on tools happens here since 8 months: https://github.com/dlang-community. I was in the team until September and i can say without any doubt that there's no money involved. I someone is paid for making tools then it's a kind of "Manhattan-project". So impossible, it would split people and create tensions.
Jan 25 2018
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
 On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote:


 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.
Maybe there has been a misunderstanding but i am not talking about CTFE or Metaprogramming. Basic OOP does not even work. And that is after testing D plugins going back a year or more with several DMD/Dub releases at the times.
Curious because based on my own experience, a reasonable D programming style gives reasonable results with DCD. Maybe you missed how to configure things ? For example in CoEdit, everydays deps should be registered there: http://bbasile.github.io/Coedit/widgets_library_manager#description. In addition the dependencies of a DUB project are automatically handled at level 1 and if already fetched. I haven't used Delphi (which you mention in your first message) for a while (2012 last time) but even in this big commercial IDE there was a dialog where paths for libs had to be registered. And at this time this dialog was way less friendly than the one i made for CoEdit!
Jan 25 2018
prev sibling next sibling parent reply Rubn <where is.this> writes:
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
 It seems to be that they understand the value of better tooling 
 and friendly platform support. Whereas its my impression that a 
 lot of resources get focused on making D its compiler / 
 language better but the rest seems to be ignored.
Well the entirety of what is used in basically every editor was developed by one person. Until recently all those projects were solely maintained by that one person. Rust's compiler can be integrated with tools if I'm not mistaken, at least I know it was being worked on a while back when I looked it up. Comparing to Rust isn't exactly fair, it is a lot more financially well off with Mozilla back it. When the tools are community run it is going to be like this. No one actually wants to work on it, they would rather be working on their own projects. Not working on tools that make working on their own projects a tiny bit easier. The tools are at a point where they are decent enough to use. You seem to be short tempered, you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working.
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
  - ... and nothing else...
This is just not true... https://imgur.com/z6CZbjL.gif
Jan 25 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote:
 You seem to be short tempered
You think after two days trying to get a series of plugins to work?
 you tried 2 plugins rather quickly, without even trying to see 
 if there were configurations or other options you could use to 
 get features working.
Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours.
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
  - ... and nothing else...
This is just not true... https://imgur.com/z6CZbjL.gif
Well, if that actually worked, i will not be complaining here.
Jan 26 2018
parent Rubn <where is.this> writes:
On Friday, 26 January 2018 at 15:37:15 UTC, Benny wrote:
 On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote:
 You seem to be short tempered
You think after two days trying to get a series of plugins to work?
 you tried 2 plugins rather quickly, without even trying to see 
 if there were configurations or other options you could use to 
 get features working.
Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours.
Well one is an older version, which is why it's the same author. The Jetbrains plugin wasn't developed for a long time, I don't know the current state of it. Did you bother at all the create an issue on the respective github repos stating your issue? Did you look at the source at all for the plugins? They aren't terribly complicated, you could diagnose some issues yourself.
   - Limited name suggestion ( VSC functionality not the 
 plugin ) only by forcing VSC (ctrl+space).
  - ... and nothing else...
This is just not true... https://imgur.com/z6CZbjL.gif
Well, if that actually worked, i will not be complaining here.
Well, if it didn't work, that gif wouldn't exist.
Jan 26 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
 I am sorry if this sounds cruel but for now D is on the back 
 burner and my next project will probably be in Rust.
If you can cope with Rust ergonomics, I see no reason to not try it. IDEs always worked perfectly for you? My experience is different even with paid state of the art flagship IDEs.
Jan 27 2018
prev sibling next sibling parent reply Johannes Loher <johannes.loher fg4f.de> writes:
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
 Maybe things work great in a few very specific editor but in my 
 personal experience, D its editor support is non stop 
 frustrating. And i suspect that this complaint is not new.
Indeed, this complaint is not new. Because the complaint is actually so common, I'd like to share my own experience: I tried several different solutions, including the IntelliJ plugin, Mono-D, Sublimetext with a D-plugin, dlangide and vs code with code-d. With most of them, I had some problems, but in the end, I got all of them working. I had the least problems with code-d (the serve-d variant), which works perfectly after setting the stdlibPath in the settings (provided you already have dscanner and dfmt installed on your system and in your PATH). This what also what I've settled for in the end. In my opinion the features offered by it are actually quite good: The autocompletion provided by dcd is more than enough for my needs and in addition to that you get static linting, code formating, debugging (if you also install the native debug plugin from the same author) goto definition and some more features. And in my experience this all works without major issues. Sure, you don't get autocompletion for ufcs calls, but that is actually quite difficult to implement... Take this all with a grain of salt: I have only tested this on Linux and OS X, I have no clue about the situation on Windows. But at least my experience was really good, so I'd like to use this opportunity to thank all the authors of the plugins and the underlying tools for doing this (ungrateful) work (and in my opinion doing it very well). I know that probably a lot has still to be done, but the state of affairs is not as bad as all the complaints make it sounds. The reasons for the problems you describe still being so common have already explained thoroughly by others: Its mainly that there are no paid developers working on it and therefore not enough people working on it. So the solution is actullay quite simple and it is the same answer that most complaints about problems with D get: Either do it yourself, or pay somebody to do it. That is the quickest way to fix things.
Jan 25 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote:
 Take this all with a grain of salt: I have only tested this on 
 Linux and OS X, I have no clue about the situation on Windows.
In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing.
 But at least my experience was really good, so I'd like to use 
 this opportunity to thank all the authors of the plugins and 
 the underlying tools for doing this (ungrateful) work (and in 
 my opinion doing it very well). I know that probably a lot has 
 still to be done, but the state of affairs is not as bad as all 
 the complaints make it sounds.
It probably is not as bad but its clearly a issue anyway. But one guy complaining after trying 6 or 7 times over a year+ ( with constant reporting the issues ), probably means there are more people out there who tried and simply gave up without reporting the issues.
 The reasons for the problems you describe still being so common 
 have already explained thoroughly by others: Its mainly that 
 there are no paid developers working on it and therefore not 
 enough people working on it. So the solution is actullay quite 
 simple and it is the same answer that most complaints about 
 problems with D get: Either do it yourself, or pay somebody to 
 do it. That is the quickest way to fix things.
And that is the same issue with a lot of FOSS languages. But at one moment one needs to say stop. I donated a lot ( for me anyway ) of money to different FOSS projects but that money, what happened to it? In general there is zero accountability where money gets spend on most projects. Just in the last month over 500$ on different projects. But i am not a infinity money machine. And in this case: Does one donate money to the Code-D/Serve-D developer. But its not really his issue. To the D-Language developer? But its not really his issue. Who do you even donate too to have specific problems that are hard to trace fixed. Its not like one asks: "Please add x functionality". Just recently i donated 100$ to a other language project to implement socket support. So far i see nothing happening, while this functionality is more important to me now ( as it blocks my progress on that project ). So even when donating the results can be "i feel ripped off". Do it yourself = Time is money. If i had that much time to learn the base code of a language, i will not be donating money to specific language projects ( also i'am not a good core / system programmer ). I feel its too many times: Complain about issue => Get responds there are no people to do it => Please do it yourself or pay. By that logic i am bankrupt tomorrow with the issues i face in different languages :) Let me not bother you too much with my rants. Like i said, its better ( for me ) to focus on a language that has things better worked out and it does not feel like screaming at the walls. I feel sorry for projects like this that have no big corporate backers because its not a envy position without the money and focus.
Jan 26 2018
parent reply Anonymouse <asdf asdf.net> writes:
On Friday, 26 January 2018 at 16:30:19 UTC, Benny wrote:
 On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher 
 wrote:
 Take this all with a grain of salt: I have only tested this on 
 Linux and OS X, I have no clue about the situation on Windows.
In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing.
Just want to pipe in that I run linux and yeah, I can't relate to any of the OP's grievances, using Visual Studio Code. I installed serve-d and the D tools on the side from repositories, then a few clicks for the code-d beta in vscode, and it just works. Arch/Manjaro. No real complaints about the features offered either. Autocomplete can be a bit too eager at times maybe, suggesting equals_t and various enum members when typing else, recently unitTest (from ModuleInfo) instead of unittest, etc. Syntax highlighting points out unbalanced parens, braces and quotes. Mouseover for documentation works, looking up/peeking at definitions does too. If I could magically wish for one thing it would be UFCS support.
Jan 26 2018
parent Seb <seb wilzba.ch> writes:
On Friday, 26 January 2018 at 17:27:17 UTC, Anonymouse wrote:
 If I could magically wish for one thing it would be UFCS 
 support.
Just an FYI: implementing the universal language server protocol with DMD as a library is the number 1 priority for this year's GSoC: https://wiki.dlang.org/GSOC_2018_Ideas#Language_Server_Protocol_for_D (if the D Language Foundation gets accepted, of course)
Jan 26 2018
prev sibling next sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
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).

 So, lets install Visual Studio Code:

 * Code-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 So lets try the next plugin:


 * Serve-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 Frustration level increasing. Lets try the next one:


 * D-Language Plugin:
   - Syntax highlight *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do 
 not properly work or some other issue.


 Then lets try IntelliJ Community Edition. After a long time 
 getting all the dependancies and compiling them... Dscanner - 
 DCD ( client and server ) - Dfix ...


 * D Language Plugin:
   - Syntax highlight *check*
   - Way too many items like writefln, import etc all being 
 marked as unknown. Clearly wrong.
   - ... and nothing else...
   - Socket error (std.socket.xxx) on closing IntelliJ


 Conclusion is that it feels like the whole D infrastructure is 
 very, very poorly supported.

 Other issues like delays that some of the D plugins seem to 
 introduce:

 * Like "loading ..." popups that do nothing but always show up 
 ( Visual Studio Code )
 * Like pressing "dot" expecting a response, waiting 2 seconds 
 and then finally something happening ( IntelliJ plugin ) but 
 simply dumping every possible name and variable ( zero 
 intelligent code support )

 I assume that this is again broken DCD or Dscanner.

 And no, no errors in the console of VSC or anything like that.

 Let me summarize my personal D editor experience in the last 1+ 
 year.

 * Attempts at getting D editor support going: 6 or 7.
 * Amount of times things worked out of the box. One! And this 
 was limited to about a few minutes and after that all 
 suggestions broke again.
 * Amount of times dscanner or dcd or other plugins broke 
 because of DMD newest version broke: 4
 * Tested on different machines: 4! They all have one thing in 
 common: Windows 10
 * Tested on different Windows installations: 3
 * Tested on different "version" of Windows 10: 3
 * Amount of times complaining to the plugin authors: Too many 
 to count.
 * Time spend on these tests / issues: Easily 50 hours or more.
 * Frustration level: Again, like each time before EXTREME!

 Please do not give me the company line that i need to report 
 issues. I did so many times. It is tiring playing guinea pig, 
 complaining and reporting, waiting for things to get fixed and 
 still seeing things break again or simply not working properly.



 working plugins for the above mentioned editors but D is always 
 that frustrating problem child. And i can not blame the plugin 
 authors because the issues always seem to stem from the D 
 plugins ( dcd, dscanner, ... ).

 Like dscanner changing its binary location between builds from 
 folder root to /bin folder, breaking the plugin authors there 
 system as it expected it in the folder root.

 Maybe things work great in a few very specific editor but in my 
 personal experience, D its editor support is non stop 
 frustrating. And i suspect that this complaint is not new.

 Clearly there is infrastructure in place for automated testing 
 the compiler but it feels like there is a total lack of 
 infrastructure for everything that surround it. Beyond maybe a 
 few editors that the core team uses?

 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.
You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff.
Jan 26 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Friday, 26 January 2018 at 21:59:51 UTC, Dgame wrote:
 You are not alone. The existing D-Tools are either really bad 
 or do not work propely/not out of the box. And I have more 
 important things to do than trying to setup the tools. Maybe 
 someone likes that, but not me. But I have to say that I've 
 used more or less successfully Visual-D and Mono-D a few years 
 ago. But neither of the tools can keep up in any way with Tools 

 works out of the box without annoying setup procedures is 
 crucial for the success of a language nowadays. That's one of 
 the reason why I've moved on. I went back to C++ and nowadays 
 to Rust. C++ is not that clean as D but the Tool support is 
 crucial for anyone who wants to use the language for other than 
 some hobby stuff.
I have been comparing a bunch of languages and there IDEs this afternoon to see how fast and efficient there latest version work ( mostly inspired by the other topics of popular languages ). Wanted to avoid the whole "grass is greener on the other side" as a way to be fair. * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. * Crystal: Visual Studio Code + OmniPascal plugin Color syntax but nothing else. No surprise, Crystal has no Windows compiler so no way to link any meaningful out output on Windows. * Pascal: Yes, freaking pascal! Visual Studio Code + OmniPascal plugin Impressive! Impressive features, type hinting and more. No surprise there. Lots of functionality. * Go: Visual Studio Code + Go Plugin. Again, no surprise. Lots of functionality. Did not try the Jetbrain Gogland IDE because that is a official product so of course Go will work great in that one. * Julia: Visual Studio Code + Julia Plugin. Took a bit more configuring but again more functionality then i ever got from any D plugin. * Swift: Visual Studio Code + Swift Plugin. Like Crystal, no Windows version and limited to Color Syntax. ... got kind of fed up testing because everything that you expect to works on Windows, worked out of the box ( at best with oa Julia one needed to add the compiler path ). If nobody has figured out the trend by now, every language that has a windows compiler in any form has no major issues to offer extended functionality ( or even basic ). Those that do not have windows compiler, fall flat as expected. The exception being D that despite having multiple windows compilers offer ( in my case ) no functionality beyond color syntax. I do not count the VSC ability to list every keyword in your document. Another trend that i noticed from the other thread is that all the above mentioned languages all outperform D in github user activity ranking ( inc the very young one's ). D has always struck me more as a corporate language ( one that is less focused upon open source ). Maybe there is a more open community focus on the other platforms and this drives more interaction and pushes better plugin support? In other words, at best it take me half a hour to get proper editor support in the above mentioned languages ( that offer it in Windows ). Where as D ... well, its been a long topic and anybody who read the first post knows the results. Lets see: * 8+ hours: Struggling with 4 plugins and no results. And still waiting on one of the plugin authors his feedback as he also has a life. * 5 hours: Seven languages with 5 working perfectly and 2 POSIX languages with the expected no result. Yes, that includes the time to download all the compilers, get examples and other stuff. Guess the 8+ hour language ;)
Jan 26 2018
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote:
 * Rust: Jetbrain IntelliJ + Rust plugin.
 It looks like it has become a official supported plugin by 
 Jetbrain. Works perfectly out of the box. Impressive results 
 and issue hinting.
https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
Jan 26 2018
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote:
 On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote:
 * Rust: Jetbrain IntelliJ + Rust plugin.
 It looks like it has become a official supported plugin by 
 Jetbrain. Works perfectly out of the box. Impressive results 
 and issue hinting.
https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
Jan 26 2018
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/26/18 7:50 PM, Dgame wrote:
 On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote:
 On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote:
 * Rust: Jetbrain IntelliJ + Rust plugin.
 It looks like it has become a official supported plugin by Jetbrain. 
 Works perfectly out of the box. Impressive results and issue hinting.
https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-o her-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
While I understand using an IDE is appealing, I want to point to a possible reverse correlation: If I had to write swift code without xcode, it would take me so much extra time, because there are things you just aren't going to get done without the tools. Swift's libraries are also vast and IMO confusingly named. On the other hand, I can write a d project without an IDE much quicker. Perhaps it's because I've been using D for almost 11 years. Perhaps it's because I'm intimately involved with the libraries. Or maybe it's because D libraries are easier to remember. I don't know the real reason, but to me, the command line tools seem to be enough for D. I just find it interesting that someone such as myself who prefers vi, and command line tools, still wants to use xcode for other languages. Is it me or is it the language? Or is it the project (in swift, I'm writing a full iOS app, in D just libraries and command line tools)? That being said, I wouldn't mind an xcode integration for D to try out :) -Steve
Jan 27 2018
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 27 Jan 2018 07:54:37 -0500
schrieb Steven Schveighoffer <schveiguy yahoo.com>:

 If I had to write swift code without xcode, it would take me so much 
 extra time, because there are things you just aren't going to get done 
 without the tools. Swift's libraries are also vast and IMO confusingly 
 named.
Same thing with Java. Without an IDE you see ridiculously long names and a lot of typing. But they do follow conventions that are understood by Java IDEs. The dummy implementation of an interface for example is always called <interface name>Adapter and can be auto-generated. All byte streams end in ...Stream and similar. This makes it easy to have mnemonics handy: "I'm looking for an input, buffered, stream". So you type IBS, auto-complete and the IDE expands that to InputBufferStream and takes care of the necessary import. Some languages are developed with IDE support in mind, but are then limited in expressiveness and not editor friendly. -- Marco
Apr 25 2018
prev sibling parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 1/26/18 5:50 PM, Dgame wrote:
 On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote:
 On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote:
 * Rust: Jetbrain IntelliJ + Rust plugin.
 It looks like it has become a official supported plugin by Jetbrain. 
 Works perfectly out of the box. Impressive results and issue hinting.
https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-o her-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
As an IDE junkie I've noticed this correlation in the past too. I wonder which direction the causation runs--does D tend to appeal to the no-IDE crowd, or do IDE-prefering people abandon D since there hasn't been great IDEs support? Regardless I'm very pleased by the recent trends. The vs-code plugins are good and getting better, and DMD as a library should enable simpler and more complete language support in any IDE. I believe we're getting closer to the point where IDE junkies like me won't feel somewhat short-changed, and that's impressive for a community-driven language like D.
Jan 27 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
 On 1/26/18 5:50 PM, Dgame wrote:
[...]
 My impression so far is that most of the D users love to program in
 a tiny editor without the features which modern IDE's gives you.
 That's impressive, but outdated and even a bit silly if the project
 is bigger.  In any company I've been so far we've used IDE's,
 because their feature-set and tools take so much work away from you
 - I don't want to miss them anymore. Nowadays, the majority of
 programmers who are willing to try new/others programming languages,
 think so too. I'm somewhat sure that this unneccessary hurdle is one
 of D's biggest mistakes.
[...] Not to negate the fact that we *do* need to improve IDE support, but the claim that IDEs are "required" for large projects is false, and so is the claim that non-IDE editors are "tiny". At my day job, I work with a very large codebase (50,000+ source files, and yes, I mean 50 *thousand*, not hundred), and vim has more than sufficed for the past 10 years. And vim does a *lot* more than what some people tend to falsely believe that it's "just" another "tiny" text editor on the order of NotePad. This doesn't excuse our poor IDE support, of course, we do need to improve our IDE support. But it's tiresome to keep reading these unfounded claims that IDE's are somehow inherently superior to powerful editors like vim, which is not necessarily the case. T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Jan 27 2018
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Saturday, 27 January 2018 at 17:55:06 UTC, H. S. Teoh wrote:
 On 1/26/18 5:50 PM, Dgame wrote:
[...]
 My impression so far is that most of the D users love to 
 program in a tiny editor without the features which modern 
 IDE's gives you. That's impressive, but outdated and even a 
 bit silly if the project is bigger.  In any company I've 
 been so far we've used IDE's, because their feature-set and 
 tools take so much work away from you - I don't want to miss 
 them anymore. Nowadays, the majority of programmers who are 
 willing to try new/others programming languages, think so 
 too. I'm somewhat sure that this unneccessary hurdle is one 
 of D's biggest mistakes.
[...] Not to negate the fact that we *do* need to improve IDE support, but the claim that IDEs are "required" for large projects is false, and so is the claim that non-IDE editors are "tiny". At my day job, I work with a very large codebase (50,000+ source files, and yes, I mean 50 *thousand*, not hundred), and vim has more than sufficed for the past 10 years. And vim does a *lot* more than what some people tend to falsely believe that it's "just" another "tiny" text editor on the order of NotePad. This doesn't excuse our poor IDE support, of course, we do need to improve our IDE support. But it's tiresome to keep reading these unfounded claims that IDE's are somehow inherently superior to powerful editors like vim, which is not necessarily the case. T
It's nice that this works for you, but I strongly believe that most of the programmers who are willing to try something new are younger and I also think that most of them don't use VIM/Emacs on a daily basis. It's impressive that you can do it and I'm sure it works for you pretty well, but I doubt that younger programmers do the same - the hurdle to work with those tools is way to high at the start. One of our programmers use VIM too, but on a regular basis he has problems like finding/renaming files/variables or optimize imports or code formatting. I bet you can do that with the right tools and a lot of time as good as an IDE can do it, but the IDE can do that out of the box without consuming your time. It's like I said - if you mainly used VIM/Emacs you think everything is fine and would not try an IDE - but that's not what nowadays happens to new programmers. And to make D appealing to them, D has to offer good IDE support or it will remain as a hobby language with very few exceptions.
Jan 27 2018
next sibling parent JN <666total wp.pl> writes:
On Saturday, 27 January 2018 at 18:18:02 UTC, Dgame wrote:
One of our programmers use
 VIM too, but on a regular basis he has problems like 
 finding/renaming files/variables or optimize imports or code 
 formatting. I bet you can do that with the right tools and a 
 lot of time as good as an IDE can do it, but the IDE can do 
 that out of the box without consuming your time. It's like I 
 said - if you mainly used VIM/Emacs you think everything is 
 fine and would not try an IDE - but that's not what nowadays 
 happens to new programmers. And to make D appealing to them, D 
 has to offer good IDE support or it will remain as a hobby 
 language with very few exceptions.
I think it depends on what we consider good IDE support. We can use C++ as baseline, so syntax highlighting, code completion and territory, with stuff like automatic variable renaming across the entire project, extracting fields into class etc. While I think D IDEs, when they work, aren't that much behind C++ IDEs (never really tried debugging D though), but they don't Given how dynamic D can be with CTFE/mixins, you can't do the kind of safe refactoring that those IDEs allow. The same applies to C++, Rust, and probably Go as well.
Jan 27 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jan 27, 2018 at 06:18:02PM +0000, Dgame via Digitalmars-d wrote:
[...]
 It's nice that this works for you, but I strongly believe that most of
 the programmers who are willing to try something new are younger and I
 also think that most of them don't use VIM/Emacs on a daily basis.
 It's impressive that you can do it and I'm sure it works for you
 pretty well, but I doubt that younger programmers do the same - the
 hurdle to work with those tools is way to high at the start.
You know, before I started using Vim, I hated it and found it difficult and counterintuitive to use. Then one day my then-boss convinced me to give it an honest try. I did, and I still hated it... but I kept at it, and as time went by, it started to "click", and suddenly it dawned on me that it's not "just" an editor; it's an *editing language*. Then new vistas opened up to me, that allowed me to things like routinely edit 8000-line source files without getting lost, and to do so far more efficiently than any GUI can ever hope to be. Even today, I'm learning new things to do with it that can improve my productivity even more. I'd never go back to my babyish days of point-and-grunt. Was it an easy learning curve? I won't lie -- it's not. It takes time and dedication, something this coddled generation seems unable to grasp, it seems. But the rewards far outweigh the investment.
 One of our programmers use VIM too, but on a regular basis he has
 problems like finding/renaming files/variables or optimize imports or
 code formatting.  I bet you can do that with the right tools and a lot
 of time as good as an IDE can do it, but the IDE can do that out of
 the box without consuming your time.
This sounds to me like inexperience. If one doesn't know the ins and outs of his tools, it's not surprising that he has trouble being efficient at doing his work. I use ctags with vim, and it's amazingly efficient: two keystrokes and I'm right at the right file in the right place on top of the definition of an identifier. Less than 1 second. Yet when I work with my coworker, who uses a fancy GUI-based IDE, he has pull up the search function, re-type the identifer that the cursor is already sitting on, then wait for the thing to slowly churn through 50,000 source files looking for a pattern match, then reach for the mouse and drag the scrollbar down a long list of possible matches, then open the file, then navigate to the right place in the file. An order of magnitude slower. Of course, having said that, some of my *other* coworkers who also use vim are equally slow, if not slower, because they haven't learnt how to use it to the max. As I said, that says to me "inexperience" rather than "the tool sux". As for renaming files, what has that got to do with Vim? It's just ctrl-Z, `mv orig.d dest.d`. Maybe followed by `git add dest.d`. Two seconds max. Again, being unable to work with the OS efficiently is not a sign of an inherent flaw of the OS, just the inexperience of the user.
 It's like I said - if you mainly used VIM/Emacs you think everything
 is fine and would not try an IDE - but that's not what nowadays
 happens to new programmers. And to make D appealing to them, D has to
 offer good IDE support or it will remain as a hobby language with very
 few exceptions.
I never said we should not offer good IDE support, in fact I said that we *need* good IDE support. But that in no way justifies the wrong claim that you can't be productive without an IDE. In fact, I find myself *more* productive without needing a memory-hogging, CPU-hogging GUI program that requires taking my hands off the keyboard all the time, just to edit code. But I'm sure you think the same about Vim/Emacs, so we're square. :-) To each his own. T -- Music critic: "That's an imitation fugue!"
Jan 27 2018
next sibling parent reply Benny <benny.luypaert rhysoft.com> writes:
On Saturday, 27 January 2018 at 22:58:27 UTC, H. S. Teoh wrote:
 I never said we should not offer good IDE support, in fact I 
 said that we *need* good IDE support.  But that in no way 
 justifies the wrong claim that you can't be productive without 
 an IDE. In fact, I find myself *more* productive without 
 needing a memory-hogging, CPU-hogging GUI program that requires 
 taking my hands off the keyboard all the time, just to edit 
 code. But I'm sure you think the same about Vim/Emacs, so we're 
 square. :-)
The problem is Teoh that learning a language in Vim or a IDE are two totally different things. I used to program in Notepad because i grew up with PHP and knew it like the back of my hand. The result was very little need to see the documentation. The moment i found PHPStorm, i fell in love. Fast function jumping, remote tools, database at your fingertips, code checkers and hinters and all the other niceties. But for anybody who is not a master of a language or even intermediate, a good IDE can make one so much more productive compared to the same person just relying on a default notepad type environment. The fact that a good IDE expands the methods from a class, it shows you the basic help / buildup of the methods calls so you know exactly where you write what, without the need to visit the developers documentation website. It massif increases the adoption rate of a language, when your new to a language or not a 10 year expert. And for the people who are used to a language, a IDE can still be useful by increasing productivity as you simply do ... example "fu" ... enter ... "function " or automated braked closing, or error indicators when you forget something so you do not wast your time discovering a stupid issue during compilation. Its the same issue i personally have with languages that get lazy and trow out readability in exchange for less keystrokes. You can at times tell what development ides a language uses simply by looking at the language. Everything awkwardly shortcut like "fn" and other shorthand ( but what do make it much more brain taxing for anybody new ). Advanced programmers have the skills to make new languages, unlike beginner programmers but they also are so used to a specific environment that they build up to speed up, over the year, that they assume that everybody else can get going just as fast as they are. As a side note, despite working years in Vim, i still prefer a normal but well equip IDE because there are just some things VIM is not good at ( unless you customize it to hell with 100's of plugins what tends to take years to find your sweet spot and build up the know how to use them all perfectly ). VIM with all the plugins is simply a IDE, just one where you do not move your hands too much away from the keyboard. As your example of your colleagues: a IDE where it takes ages to jump to a definition in a file, is simply a incomplete IDE. Or maybe those colleges have not master the IDE. I know for a fact from myself that there is a massive amount of things still "hiding" in Jetbrain there products or Visual Studio Code that can make me more productive but you learn over time or when you stumble upon it. From my point of view, without a working IDE its much more difficult for a non-specific-language to learn and get better at the language. And again, VIM with the right plugins is a IDE, simple as that. Its annoying that people do not see this. The big difference is that VIM is designed around not moving your hand to your mouse and that is its major strength. On a side note: The issue i had with the plugins, well one of the plugin authors found the issue and it came down to it that the D compiler had a regression that effect DCD. I remember mentioning before as how many times the compiler ends up breaking code. Going over the D release list, you see way too many times: Major release - fix - fix, Major release - fix, Major release - fix - fix... What indicates to me a lack of cross platform testing. Especially the amount of regressions surprises even me. It feels like too much focus is put upon new features and too few upon a test setup that does not only tests the compiler but also all the dub packages.
Jan 27 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 28, 2018 at 12:03:38AM +0000, Benny via Digitalmars-d wrote:
[...]
 The problem is Teoh that learning a language in Vim or a IDE are two
 totally different things.
 
 I used to program in Notepad because i grew up with PHP and knew it
 like the back of my hand. The result was very little need to see the
 documentation.  The moment i found PHPStorm, i fell in love. Fast
 function jumping, remote tools, database at your fingertips, code
 checkers and hinters and all the other niceties.
The problem is that people keep equating Vim with Notepad. It *may* be true that Vim sucks, but the reason implied by the comparison to Notepad makes no sense. It's like saying Windows 10 sux because MSDOS sucked. It simply doesn't follow logically.
 But for anybody who is not a master of a language or even
 intermediate, a good IDE can make one so much more productive compared
 to the same person just relying on a default notepad type environment.
 The fact that a good IDE expands the methods from a class, it shows
 you the basic help / buildup of the methods calls so you know exactly
 where you write what, without the need to visit the developers
 documentation website.
I learned D from scratch using only Vim, Andrei's TDPL book, and reading Phobos source code (which is surprisingly easy to read, compared to other languages' standard lib code *cough*ahem*glibc*sneeze*). At the time I started, the online docs sucked, and might as well be disregarded. Things have progressed a lot since then. I don't understand the fear of needing to *gosh* open your browser and visiting the developers documentation website. I don't hear of people complaining of needing to take driving lessons in order to get a driver's license, and here we're talking about *programming* in a Turing-complete language, which is something FAR more complex than driving a car ever will be. But hey, I'm just an outdated old geezer, what do I know anyway? [...]
 And for the people who are used to a language, a IDE can still be
 useful by increasing productivity as you simply do ... example "fu"
 ... enter ...  "function " or automated braked closing, or error
 indicators when you forget something so you do not wast your time
 discovering a stupid issue during compilation.
Erm, you do realize that Vim has built-in commands for navigating nested brackets and parentheses, right? And automatic bracket closing is just a macro away. You don't even need a plugin for that.
 Its the same issue i personally have with languages that get lazy and
 trow out readability in exchange for less keystrokes. You can at times
 tell what development ides a language uses simply by looking at the
 language.  Everything awkwardly shortcut like "fn" and other shorthand
 ( but what do make it much more brain taxing for anybody new ).
AFAICT, D has a pretty good balance between needlessly unreadably shortened names like that awful *nix `creat()` or `awk`, and Java's NeedlesslyVerboseCompletelyRedundantRepetitiousIdentifiers. I personally prefer shorter names than what D has, but I think what D has does serve pretty well in terms of being comprehensible to newbies, and still being typable without giving your wrist an aneurysm. There used to be a couple of pretty bad names, but IIRC we've weeded them out and replaced them with better ones by now. [...]
 As a side note, despite working years in Vim, i still prefer a normal
 but well equip IDE because there are just some things VIM is not good
 at ( unless you customize it to hell with 100's of plugins what tends
 to take years to find your sweet spot and build up the know how to use
 them all perfectly ). VIM with all the plugins is simply a IDE, just
 one where you do not move your hands too much away from the keyboard.
Actually, I hardly use *any* Vim plugins. Maybe just a couple of standard ones that are already configured by default. But you're right that it's basically an IDE, if your baseline for comparison is Notepad. That's something people don't seem to get, for some reason. But oh well. Their loss, not mine.
 As your example of your colleagues: a IDE where it takes ages to jump
 to a definition in a file, is simply a incomplete IDE. Or maybe those
 colleges have not master the IDE. I know for a fact from myself that
 there is a massive amount of things still "hiding" in Jetbrain there
 products or Visual Studio Code that can make me more productive but
 you learn over time or when you stumble upon it.
The thing about these fancy GUI IDEs is that *somebody* must have thought of a particular feature and implemented it for you, before you can use it. If you happen to need something the developers didn't think of, you're stuck up the creek without a paddle. Editors like Vim, OTOH, provide you an entire editing *language* to build upon; if the defaults don't have some feature you need, you have the power to add the feature yourself without needing to hack Vim source code. It's about empowering the user to be able to fish for themselves, vs. spoonfeeding them with a precooked fish (to mangle the proverb a little). But I suppose the thought of having to do stuff yourself is too scary for some people, who prefer the world handed to them on a silver platter. Oh well, whatever rocks their boat. It's none of my business.
 From my point of view, without a working IDE its much more difficult
 for a non-specific-language to learn and get better at the language.
 And again, VIM with the right plugins is a IDE, simple as that. Its
 annoying that people do not see this. The big difference is that VIM
 is designed around not moving your hand to your mouse and that is its
 major strength.
Yes, being free from the rodent is liberating indeed. It frees up my energy to actually think about the problem rather than constantly engaging in "now where on earth is that nested menu with that obscure option that I can never find?!" and "you mean I actually have to repeat this series of clicks and mouse wiggles 500 times?! whatever happened to programmability?". As far as learning a new language is concerned, though, IMO that has nothing to do with what IDE or editor you use or don't use. The idea is to learn the underlying paradigms and principles in programming languages in general, which is standard curriculum in universities AFAIK, and once you understand that, picking up a new language is easy.
 On a side note: The issue i had with the plugins, well one of the
 plugin authors found the issue and it came down to it that the D
 compiler had a regression that effect DCD. I remember mentioning
 before as how many times the compiler ends up breaking code.
[...] This is why I don't like designing my workflow around reliance on 3rd party plugins or tools. My Vim setup is pretty minimal as far as plugins go; so far I haven't actually used any of the D-specific Vim plugins, and I don't even bother with syntax highlighting, which I find distracts my attention from focusing on the programming problem (but I know this is a very minority opinion). My philosophy is "do the most while relying on the least". It works pretty well both in terms of my coding environment as well as the code itself -- code tends to be cleaner, more robust and less bug-prone if written in that way. It's slightly harder to get started at first, but once you've built a solid foundation, the initial invested effort pays for itself many times over -- the code is more stable, less time is spent debugging, and the code also tends to be more reusable so subsequent development becomes faster. I don't expect anyone else to follow my way of coding, though. This day and age seems to be all about instant gratification, and my philosophy goes against the grain of that. Let them have their IDEs and eye candy, it's their business, not mine. *shrug* T -- Famous last words: I *think* this will work...
Jan 28 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 00:27:51 H. S. Teoh via Digitalmars-d wrote:
 On Sun, Jan 28, 2018 at 12:03:38AM +0000, Benny via Digitalmars-d wrote:
 [...]

 The problem is Teoh that learning a language in Vim or a IDE are two
 totally different things.

 I used to program in Notepad because i grew up with PHP and knew it
 like the back of my hand. The result was very little need to see the
 documentation.  The moment i found PHPStorm, i fell in love. Fast
 function jumping, remote tools, database at your fingertips, code
 checkers and hinters and all the other niceties.
The problem is that people keep equating Vim with Notepad. It *may* be true that Vim sucks, but the reason implied by the comparison to Notepad makes no sense. It's like saying Windows 10 sux because MSDOS sucked. It simply doesn't follow logically.
Comparing vim to notepad would be a comparison that I don't understand at all. Even if you're just talking really basic commands, it makes notepad look like a typewriter. If anything, I would have compared IDEs to notepad due to how poor their code editing capabilities are. IDEs add lots of nice tools for refactoring code and the like, but their actual text editing capabilities tend to be only a bit above notepad. This reminds me of this old stackoveflow question: https://stackoverflow.com/questions/2695919
 Erm, you do realize that Vim has built-in commands for navigating nested
 brackets and parentheses, right? And automatic bracket closing is just a
 macro away. You don't even need a plugin for that.
LOL. One of the reasons that I hate python is that I can't hop between braces in it in vim, because it has no braces. It makes jumping from the top of a function to the bottom a lot harder. Even Pascal has begin and end (which I found out that vim understands when I was mucking around with some stuff in Pascal several months ago).
 Its the same issue i personally have with languages that get lazy and
 trow out readability in exchange for less keystrokes. You can at times
 tell what development ides a language uses simply by looking at the
 language.  Everything awkwardly shortcut like "fn" and other shorthand
 ( but what do make it much more brain taxing for anybody new ).
AFAICT, D has a pretty good balance between needlessly unreadably shortened names like that awful *nix `creat()` or `awk`, and Java's NeedlesslyVerboseCompletelyRedundantRepetitiousIdentifiers. I personally prefer shorter names than what D has, but I think what D has does serve pretty well in terms of being comprehensible to newbies, and still being typable without giving your wrist an aneurysm. There used to be a couple of pretty bad names, but IIRC we've weeded them out and replaced them with better ones by now.
LOL. You should read the grammar specification for Java. It has the longest identifier names I have ever seen. It just seemed so sadly perfect that Java's own grammar specification had ridiculously long identifier names. I think that overall D has struck a good balance with identifier names, but that's always a bit subjective - e.g. there was a rather long bikeshedding thread once where some folks complained that Clock.currTime wasn't currentTime or now. I'd always kind of assumed that if someone were going to complain about it, they'd start arguing about how many r's it had, not that I shouldn't have abbreviated an obvious word.
 As a side note, despite working years in Vim, i still prefer a normal
 but well equip IDE because there are just some things VIM is not good
 at ( unless you customize it to hell with 100's of plugins what tends
 to take years to find your sweet spot and build up the know how to use
 them all perfectly ). VIM with all the plugins is simply a IDE, just
 one where you do not move your hands too much away from the keyboard.
Actually, I hardly use *any* Vim plugins. Maybe just a couple of standard ones that are already configured by default. But you're right that it's basically an IDE, if your baseline for comparison is Notepad. That's something people don't seem to get, for some reason. But oh well. Their loss, not mine.
The only plugin that I really use at this point is minibufexpl, which shows your buffers at the top of the window. It does allow you to then navigate them with the mouse, but I mostly just use it so that I can see which buffers I have open and which I'm on. I don't even use ctags, and I certainly don't use anything like dscanner or dcd. I probably should find more plugins to boost my productivity, but I also should spend more time leaning stray vim commands - just like I should spend more time learning stray *nix commands. There are so many capabilities there that I barely use or don't even know about. I suspect that most vim users use less than 5% of its capabilities given the insane amount of stuff it can do without getting plugins involved at all. But even if I were to heavily use plugins, it wouldn't be like an IDE at all, because it would actually have good text editing capabilities. _That_ is my biggest complaint about any kind of IDE. Their text editing capabilities always seem primitive in comparison to vim. In the past, I've tried to use vim plugins for IDEs, and that helps, but they never seem to work quite right, and ultimately, I end up just using vim. I have yet to find an IDE where I didn't feel like I was playing with primitive tools in comparison to vim. And as such, it's that much weirder to me for someone want to use an IDE. But it _does_ take quite a lot to learn vim. Starting out with it was a lot like when I first switched to dvorak. For a while, I could barely type at all. And I suspect that it's that first encounter with vim or emacs where it feels like you have to fight them to even get what you can get out of notepad is why more folks don't use vim or emacs. But a lot of programmers do eventually end up with one or the other in spite of that.
 As far as learning a new language is concerned, though, IMO that has
 nothing to do with what IDE or editor you use or don't use.  The idea is
 to learn the underlying paradigms and principles in programming
 languages in general, which is standard curriculum in universities
 AFAIK, and once you understand that, picking up a new language is easy.
Learning a new language is always a bit of work, but once you understand the underlying concepts and have use a language or two, it's generally straightforward to learn a new language. Part of my problem is that when I actually want to learn a language, I tend to want to learn it through and through, not just enough to get by, and that takes a lot more effort. On that basis, I don't know something like python worth anything, but I've written a number of smaller python programs before. If anything, the fact that I found D has pretty much ruined me for really learning new languages. Before, I would use a new language for all of my projects for a while - kind of like you do better with a new human language by immersing yourself in it and dealing with everyone in the new language for a while. But after learning D, I don't want to do any of my projects in anything but D, so I never end up immersing myself in any new programming languages. I probably should find more time to spend on messing around with and learning new languages, since that can often be helpful in becoming a better programmer (especially if they use a different paradigm), but I have so much else to do that I haven't.
 and I don't even bother with syntax highlighting, which I find
 distracts my attention from focusing on the programming problem (but I
 know this is a very minority opinion).
As we've discussed before, this is one area where we don't agree at all. I find it incredibly annoying when I don't have syntax highlighting. But I see no reason why that shouldn't be up to the user just like what the colors are should be up to the user.
 I don't expect anyone else to follow my way of coding, though. This day
 and age seems to be all about instant gratification, and my philosophy
 goes against the grain of that. Let them have their IDEs and eye candy,
 it's their business, not mine.  *shrug*
LOL. There's some truth to that, but this reminds me about a talk talking about how every generation complains about attitude problems of the next generation - frequently with pretty much the same complaints. So, I think that to some extent, those sort of complaints boil down to complaining about how the young whippersnappers don't know anything. ;) Either way, I've seen a whole range of what programmers do and prefer in their code editors. The youngest programmers do tend to use the standard IDE for a language (in which case, many of them would initially feel a bit lost with something like D), but that's often just a question of them not having found something better yet. For many of them, even if they don't end up with vim or emacs, they'll end up with something like sublime or notepad++. And yes, some do stick with IDEs, but a lot don't. I think that part of that tends to depend on the programming language or OS that's being used. Personally, I picked up vim in college, and never looked back - and I'm in my mid-thirties, so I'm sure not 20 anymore, but I'm still very much on the younger end of the spectrum, and I'm a diehard vim user. LOL, I ended up using latex for papers in school just because then I could use vim, because the text-editing capabilities of stuff like FrameMaker or OpenOffice sucked in comparison. And I've done stuff like hook vim into my e-mail client so that I can type my e-mails (including this one) using vim. Using other editors feels like being stuck in the stone age. And for me, personally, IDEs simply can't compare to vim. It is true though that most of the core developers around here favor editors like vim or emacs and would prefer to focus their efforts on the language itself or libraries rather than on plugins for IDEs and whatnot, which is part of why D's IDE support isn't as good as some folks would like - the other big component being the lack of a company paying for folks to work on IDE support. I think that in general, that's how you end up with IDEs with first class support for a language. Sometimes, volunteer work will get you there, but that doesn't seem to be how it usually comes about - not from what I've seen in other languages anyway. But there are a few folks like Rainer who put in a lot of time and effort on IDE-related support and tools. - Jonathan m Davis
Jan 28 2018
next sibling parent reply arturg <var.spool.mail700 gmail.com> writes:
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis 
wrote:
 Erm, you do realize that Vim has built-in commands for 
 navigating nested brackets and parentheses, right? And 
 automatic bracket closing is just a macro away. You don't even 
 need a plugin for that.
LOL. One of the reasons that I hate python is that I can't hop between braces in it in vim, because it has no braces. It makes jumping from the top of a function to the bottom a lot harder. Even Pascal has begin and end (which I found out that vim understands when I was mucking around with some stuff in Pascal several months ago).
if you set foldmethod=indent in vim you can navigate to the top or bottom of the fold with [z and ]z, or check help fold-commands.
Jan 28 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 17:32:30 arturg via Digitalmars-d wrote:
 On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis

 wrote:
 Erm, you do realize that Vim has built-in commands for
 navigating nested brackets and parentheses, right? And
 automatic bracket closing is just a macro away. You don't even
 need a plugin for that.
LOL. One of the reasons that I hate python is that I can't hop between braces in it in vim, because it has no braces. It makes jumping from the top of a function to the bottom a lot harder. Even Pascal has begin and end (which I found out that vim understands when I was mucking around with some stuff in Pascal several months ago).
if you set foldmethod=indent in vim you can navigate to the top or bottom of the fold with [z and ]z, or check help fold-commands.
Hmm. Thanks. I'll have to check that out. I haven't done anything with folds in ages. Fortunately, I don't have to do anything with python right now though. The main reason that I used it before was so that I could have cross-platform scripts at a previous job when I couldn't use D (if it were for use by more than just me, I couldn't use D, because no one else in my group was doing anything with D and it wasn't part of our build system) - that and even if I had to write something Windows-specific, writing it in Python was worlds better than writing it in batch. Right now, I'm able to use D for work, so I'm much more likely to just write scripts in D. - Jonathan M Davis
Jan 28 2018
parent reply arturg <var.spool.mail700 gmail.com> writes:
On Sunday, 28 January 2018 at 17:51:19 UTC, Jonathan M Davis 
wrote:
 Hmm. Thanks. I'll have to check that out. I haven't done 
 anything with folds in ages.

 Fortunately, I don't have to do anything with python right now 
 though. The main reason that I used it before was so that I 
 could have cross-platform scripts at a previous job when I 
 couldn't use D (if it were for use by more than just me, I 
 couldn't use D, because no one else in my group was doing 
 anything with D and it wasn't part of our build system) - that 
 and even if I had to write something Windows-specific, writing 
 it in Python was worlds better than writing it in batch.

 Right now, I'm able to use D for work, so I'm much more likely 
 to just write scripts in D.

 - Jonathan M Davis
in C++ you have header files as an overview of a type in D and other languages you can use code folding when you dont use any plugins.
Jan 28 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 18:11:09 arturg via Digitalmars-d wrote:
 On Sunday, 28 January 2018 at 17:51:19 UTC, Jonathan M Davis

 wrote:
 Hmm. Thanks. I'll have to check that out. I haven't done
 anything with folds in ages.

 Fortunately, I don't have to do anything with python right now
 though. The main reason that I used it before was so that I
 could have cross-platform scripts at a previous job when I
 couldn't use D (if it were for use by more than just me, I
 couldn't use D, because no one else in my group was doing
 anything with D and it wasn't part of our build system) - that
 and even if I had to write something Windows-specific, writing
 it in Python was worlds better than writing it in batch.

 Right now, I'm able to use D for work, so I'm much more likely
 to just write scripts in D.
in C++ you have header files as an overview of a type in D and other languages you can use code folding when you dont use any plugins.
I've use folds before, but ultimately, I decided that I didn't like them. I just don't like having sections of a file being hidden. - Jonathan M Davis
Jan 28 2018
prev sibling parent reply Dave <kraxli77 gmail.com> writes:
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis 
wrote:
 The problem is Teoh that learning a language in Vim or a IDE 
 are two totally different things.
vim is a fantastic tool but it can be time consuming to configure. So I am wondering if some vim-D users would kindly share their vim setup for D and maybe even give some insights into their vim-D work-flow? Thx Dave
Apr 24 2018
parent Uknown <sireeshkodali1 gmail.com> writes:
On Tuesday, 24 April 2018 at 07:15:38 UTC, Dave wrote:
 On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis 
 wrote:
 The problem is Teoh that learning a language in Vim or a 
 IDE are two totally different things.
vim is a fantastic tool but it can be time consuming to configure. So I am wondering if some vim-D users would kindly share their vim setup for D and maybe even give some insights into their vim-D work-flow? Thx Dave
You can checkout [0], [1] which have some nice info on setting up various IDEs and text editors for D. vim in specific already had syntax highlighting support by default. Just do `syntax on`. You can enable other features like standard library highlighting, util snips, etc, by looking at [2]. [0]:https://wiki.dlang.org/Editors [1]:https://wiki.dlang.org/IDEs [2]:https://wiki.dlang.org/D_in_Vim
Apr 24 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 28, 2018 at 09:02:36AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
 I have yet to find an IDE where I didn't feel like I was playing with
 primitive tools in comparison to vim. And as such, it's that much weirder to
 me for someone want to use an IDE. But it _does_ take quite a lot to learn
 vim. Starting out with it was a lot like when I first switched to dvorak.
 For a while, I could barely type at all. And I suspect that it's that first
 encounter with vim or emacs where it feels like you have to fight them to
 even get what you can get out of notepad is why more folks don't use vim or
 emacs. But a lot of programmers do eventually end up with one or the other
 in spite of that.
[...] Yeah, I think the barrier to entry is probably a big deterrent for the casual learner. I think this is more so in vi clones like vim than in emacs, because of that modal thing. When I first started using vim, it almost drove me to tears in frustration. But nowadays, I find any text editing that *isn't* modal awkward and annoying to use. :-P There's something about being able to navigate freely without "accidentally" making an edit that just seems to make more sense to me. But I don't think any non-vi user would understand what I'm talking about.
 As far as learning a new language is concerned, though, IMO that has
 nothing to do with what IDE or editor you use or don't use.  The
 idea is to learn the underlying paradigms and principles in
 programming languages in general, which is standard curriculum in
 universities AFAIK, and once you understand that, picking up a new
 language is easy.
Learning a new language is always a bit of work, but once you understand the underlying concepts and have use a language or two, it's generally straightforward to learn a new language.
The thing is, the majority of languages out there today are imperative; that means once you know how an imperative language works, you're already halfway to learning *all* of those languages. The other half is just learning keywords and standard identifiers that map to standard imperative concepts. Even with non-imperative languages like Lisp or Haskell, once you've learned the concepts behind the functional paradigm, learning another functional language is easy. Of course, this depends on being able to see through the external trappings of a language and discern its underlying principles; otherwise you have to start from scratch with every new language. [...]
 Either way, I've seen a whole range of what programmers do and prefer in
 their code editors. The youngest programmers do tend to use the standard IDE
 for a language (in which case, many of them would initially feel a bit lost
 with something like D), but that's often just a question of them not having
 found something better yet. For many of them, even if they don't end up with
 vim or emacs, they'll end up with something like sublime or notepad++. And
 yes, some do stick with IDEs, but a lot don't. I think that part of that
 tends to depend on the programming language or OS that's being used.
I actually used to use Notepad++ or some related clone before I learned vim. But now, there's simply no comparison. The drive towards user- friendliness and general accessibility by MS and other IDE vendors is a double-edged sword; OT1H it's great that these nicely packaged software have made programming more accessible to a vast number of people who otherwise may not have gotten into it. But OTOH, it has also produced a kind of misconception that programming is "easy", and a sense of entitlement that everything must be handed to you on a silver platter. Unfortunately, the harsh reality is that programming is inherently hard, and if you want to write good code you'd better get ready to put in the effort to think (hard!) about your programming problem. Getting past the initial learning curve of syntax and library, that IDE's are purportedly good for, is only barely scratching the surface of it. [...]
 It is true though that most of the core developers around here favor
 editors like vim or emacs and would prefer to focus their efforts on
 the language itself or libraries rather than on plugins for IDEs and
 whatnot, which is part of why D's IDE support isn't as good as some
 folks would like - the other big component being the lack of a company
 paying for folks to work on IDE support. I think that in general,
 that's how you end up with IDEs with first class support for a
 language. Sometimes, volunteer work will get you there, but that
 doesn't seem to be how it usually comes about - not from what I've
 seen in other languages anyway.
But the thing is, this is not a proprietary language where people are paid to do the grunt work. It's unrealistic to expect that random volunteers in the internet would go out of their way to implement support for something they don't use themselves. *Somebody* among the IDE crowd has to step up to do the work of improving IDE support; otherwise no amount of complaints is going to change a thing.
 But there are a few folks like Rainer who put in a lot of time and
 effort on IDE-related support and tools.
[...] And I'm mighty glad we have people like him around! T -- My program has no bugs! Only undocumented features...
Jan 28 2018
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 27 Jan 2018 14:58:27 -0800
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:

 I use ctags with vim, and it's amazingly efficient: two keystrokes and
 I'm right at the right file in the right place on top of the definition
 of an identifier. Less than 1 second.  Yet when I work with my coworker,
 who uses a fancy GUI-based IDE, he has pull up the search function,
 re-type the identifer that the cursor is already sitting on, then wait
 for the thing to slowly churn through 50,000 source files looking for a
 pattern match, then reach for the mouse and drag the scrollbar down a
 long list of possible matches, then open the file, then navigate to the
 right place in the file. An order of magnitude slower.
His IDE doesn't seem all that fancy. All the ones I came across had "Jump to definition" (Visual Studio, IntelliJ, NetBeans, Eclipse, MonoDevelop, Turbo Delphi, Qt Creator, CoEdit). F3 in Mono-D Ctrl+Shift+Up in CoEdit In Mono-D when you type in the opening '(' of a function call, it would pop up the documentation and show you which argument you are currently at. The arrow keys can be used to pick another function overload with the current one displayed as e.g. 1/3 in the corner.
 As for renaming files, what has that got to do with Vim?  It's just
 ctrl-Z, `mv orig.d dest.d`. Maybe followed by `git add dest.d`. Two
 seconds max.  Again, being unable to work with the OS efficiently is not
 a sign of an inherent flaw of the OS, just the inexperience of the user.
In a well working IDE like Eclipse for Java, you'd click on the file, press F2 or whatever the key for a rename is, type the new name (without extension), press Enter and it would handle the file rename, git add and updating all references to the module/class in the loaded projects. Eat that editor user. :p I for one can't do Ctrl+Z, "mv orig.d dest.d" and "git add dest.d" in 2 seconds. I'm a slow typer. :( And that still doesn't update all my imports referring to orig.d.
 T
-- Marco
Apr 25 2018
prev sibling next sibling parent NX <nightmarex1337 hotmail.com> writes:
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:

 working plugins for the above mentioned editors but D is always 
 that frustrating problem child. And i can not blame the plugin 
 authors because the issues always seem to stem from the D 
 plugins ( dcd, dscanner, ... ).
I would like to point (again) that implementing proper and intelligent code completion for D is just ridiculously hard, and by that I mean *hard*. Seriously, one requires something as complex as the compiler itself. Oh and people actually did try to use compiler but guess what? Dmd doesn't do memory management of any kind (it was still the case last time I checked) it allocates and never frees, thus it's rather unfeasible to use dmd code for all those things. Also, the compiler is not fast enough for IDE usage anyway (ctfe, template heavy code...) so there is that.
 Maybe things work great in a few very specific editor but in my 
 personal experience, D its editor support is non stop 
 frustrating. And i suspect that this complaint is not new.
From experience point I can tell the easiest and smartest IDE (plugin) *was* Mono-D¹. I say was because it doesn't support latest MonoDevelop version² and not maintained these days so you need to somehow find and install MonoDevelop 5 (you can find it here²). What you need to do is basically go to add-in manager, install "D Language Binding" from gallery, go to settings and set "Import Paths". If the compiler directory is not in the PATH you need to configure those too but that's about it. It even lets you open dub.json files as projects and some other nice stuff you can read in wiki³ (there are some outdated information so beware). The reason it's no longer maintained is as you can guess: it was a one man's show. ¹ https://github.com/aBothe/Mono-D ² https://github.com/aBothe/Mono-D/issues/648 ³ https://wiki.dlang.org/Mono-D
Jan 27 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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).

 So, lets install Visual Studio Code:

 * Code-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 So lets try the next plugin:


 * Serve-D Plugin:
   - Syntax highlight *check*
   - After saving: DMD error suggestions in the code. *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 Frustration level increasing. Lets try the next one:


 * D-Language Plugin:
   - Syntax highlight *check*
   - Limited name suggestion ( VSC functionality not the plugin 
 ) only by forcing VSC (ctrl+space).
   - ... and nothing else...


 Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do 
 not properly work or some other issue.


 Then lets try IntelliJ Community Edition. After a long time 
 getting all the dependancies and compiling them... Dscanner - 
 DCD ( client and server ) - Dfix ...


 * D Language Plugin:
   - Syntax highlight *check*
   - Way too many items like writefln, import etc all being 
 marked as unknown. Clearly wrong.
   - ... and nothing else...
   - Socket error (std.socket.xxx) on closing IntelliJ


 Conclusion is that it feels like the whole D infrastructure is 
 very, very poorly supported.

 Other issues like delays that some of the D plugins seem to 
 introduce:

 * Like "loading ..." popups that do nothing but always show up 
 ( Visual Studio Code )
 * Like pressing "dot" expecting a response, waiting 2 seconds 
 and then finally something happening ( IntelliJ plugin ) but 
 simply dumping every possible name and variable ( zero 
 intelligent code support )

 I assume that this is again broken DCD or Dscanner.

 And no, no errors in the console of VSC or anything like that.

 Let me summarize my personal D editor experience in the last 1+ 
 year.

 * Attempts at getting D editor support going: 6 or 7.
 * Amount of times things worked out of the box. One! And this 
 was limited to about a few minutes and after that all 
 suggestions broke again.
 * Amount of times dscanner or dcd or other plugins broke 
 because of DMD newest version broke: 4
 * Tested on different machines: 4! They all have one thing in 
 common: Windows 10
 * Tested on different Windows installations: 3
 * Tested on different "version" of Windows 10: 3
 * Amount of times complaining to the plugin authors: Too many 
 to count.
 * Time spend on these tests / issues: Easily 50 hours or more.
 * Frustration level: Again, like each time before EXTREME!

 Please do not give me the company line that i need to report 
 issues. I did so many times. It is tiring playing guinea pig, 
 complaining and reporting, waiting for things to get fixed and 
 still seeing things break again or simply not working properly.



 working plugins for the above mentioned editors but D is always 
 that frustrating problem child. And i can not blame the plugin 
 authors because the issues always seem to stem from the D 
 plugins ( dcd, dscanner, ... ).

 Like dscanner changing its binary location between builds from 
 folder root to /bin folder, breaking the plugin authors there 
 system as it expected it in the folder root.

 Maybe things work great in a few very specific editor but in my 
 personal experience, D its editor support is non stop 
 frustrating. And i suspect that this complaint is not new.

 Clearly there is infrastructure in place for automated testing 
 the compiler but it feels like there is a total lack of 
 infrastructure for everything that surround it. Beyond maybe a 
 few editors that the core team uses?

 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.
You know you're not the first coming with this topic. I've developped a theory. You guys are looking for excuses to not get into D. If IDE were okay you would find something else. Did you know for example that with a decent D IDE you can press "F1" and get directly the html help: https://www.youtube.com/watch?v=9Ncf6n4yniI&list=PLzk8A0LUvEOV-OMdz09jfOahwnKoA2na_&index=1 ?
Jan 28 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 28 January 2018 at 08:40:35 UTC, Basile B. wrote:
 On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:

 You know you're not the first coming with this topic. I've 
 developped a theory. You guys are looking for excuses to not 
 get into D. If IDE were okay you would find something else.
That's the wrong mood to have with someone just reporting what's a fact: D Langland IDE quality is FAR lower than the major competitors out there. Full stop. /P
Jan 28 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 15:06:49 H. S. Teoh via Digitalmars-d wrote:
 On Sun, Jan 28, 2018 at 09:02:36AM -0700, Jonathan M Davis via
 It is true though that most of the core developers around here favor
 editors like vim or emacs and would prefer to focus their efforts on
 the language itself or libraries rather than on plugins for IDEs and
 whatnot, which is part of why D's IDE support isn't as good as some
 folks would like - the other big component being the lack of a company
 paying for folks to work on IDE support. I think that in general,
 that's how you end up with IDEs with first class support for a
 language. Sometimes, volunteer work will get you there, but that
 doesn't seem to be how it usually comes about - not from what I've
 seen in other languages anyway.
But the thing is, this is not a proprietary language where people are paid to do the grunt work. It's unrealistic to expect that random volunteers in the internet would go out of their way to implement support for something they don't use themselves. *Somebody* among the IDE crowd has to step up to do the work of improving IDE support; otherwise no amount of complaints is going to change a thing.
True. If something is going to happen, someone has to step up - probably multiple someones - and most of the folks who seem to be interested in putting the time in to develop D libraries or tools don't seem to be interested in IDE development. If more folks decide to put in the time and effort, we may eventually get to where some of these folks who want better IDE support want D's IDE support to be. But part of my point is that good IDE support seems to be one of those things that generally only happens when a company pays for it. That's not always the same company who develops the language (if there even is a company behind the language), but if no company pays for such development, the odds are much, much lower that it's ever going to happen. Either way, more folks need to put some time and/or money towards IDE development for D, or the folks who want first class IDE support for D are never going to have what they want. Personally, I don't really care, because I have no interest in such support. I have no problem if it gets implemented, and it probably is better for the D community if we have better IDE support, but it wouldn't improve my life any. If we're going to get improved tooling, I'd rather see more improvements to stuff like dub than better IDE support. So, I generally ignore the complaints about the lack of good IDE support. Either way, it's not something that I'm going to spend time on. I have too much on my TODO list already. - Jonathan M Davis
Jan 28 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 28, 2018 at 05:13:15PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
 On Sunday, January 28, 2018 15:06:49 H. S. Teoh via Digitalmars-d wrote:
[...]
 But the thing is, this is not a proprietary language where people
 are paid to do the grunt work.  It's unrealistic to expect that
 random volunteers in the internet would go out of their way to
 implement support for something they don't use themselves.
 *Somebody* among the IDE crowd has to step up to do the work of
 improving IDE support; otherwise no amount of complaints is going to
 change a thing.
True. If something is going to happen, someone has to step up - probably multiple someones - and most of the folks who seem to be interested in putting the time in to develop D libraries or tools don't seem to be interested in IDE development. If more folks decide to put in the time and effort, we may eventually get to where some of these folks who want better IDE support want D's IDE support to be.
Given the number of people routinely clamoring for better IDE support, it's disheartening how few among them are willing to step up to the plate to do the work for the benefit of the others. I don't know why that is... we don't seem to have the same problem for, say, vim support. Maybe it's because (much?) less effort is involved, so people feel it's less daunting to take it on. Or maybe the folks who use vim are simply more inclined to put in the effort to make things work, I don't know.
 But part of my point is that good IDE support seems to be one of those
 things that generally only happens when a company pays for it. That's
 not always the same company who develops the language (if there even
 is a company behind the language), but if no company pays for such
 development, the odds are much, much lower that it's ever going to
 happen.
Then maybe we should recruit, say, a team lead from the Visual Studio team or something, to learn D, then he'll be able to pull the right strings to get better IDE support implemented. :-P
 Either way, more folks need to put some time and/or money towards IDE
 development for D, or the folks who want first class IDE support for D
 are never going to have what they want.
Still, it's strange that given the number of people who demand first class IDE support, there are so few who are willing to contribute to improving it.
 Personally, I don't really care, because I have no interest in such
 support.  I have no problem if it gets implemented, and it probably is
 better for the D community if we have better IDE support, but it
 wouldn't improve my life any. If we're going to get improved tooling,
 I'd rather see more improvements to stuff like dub than better IDE
 support. So, I generally ignore the complaints about the lack of good
 IDE support. Either way, it's not something that I'm going to spend
 time on. I have too much on my TODO list already.
[...] It doesn't really concern me either, but neither do I want the indifference of the non-IDE folk to be misunderstood as active neglect. But people will see what they want to see, so meh, I guess. All I can say is, after coming to D, I did find some things not quite to my liking, so I fixed them myself and submitted PRs. And so did many others like me. And we're all better off for it. Now if only more from the IDE crowd would do the same, things might be different... T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Jan 28 2018
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 29 January 2018 at 00:18:40 UTC, H. S. Teoh wrote:
 Still, it's strange that given the number of people who demand 
 first class IDE support, there are so few who are willing to 
 contribute to improving it.
It's probably that they view programming languages as a tool to get things done. Investing a lot of time in writing an IDE or plugin is time that could instead be spent writing programs that are useful in some other language. That's why languages with better tooling usually have a lot of support from companies. The companies recognize that investing in the tools can help make some of their programmers more productive and it's worth the cost.
Jan 28 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 29, 2018 at 01:23:49AM +0000, jmh530 via Digitalmars-d wrote:
[...]
 It's probably that they view programming languages as a tool to get
 things done. Investing a lot of time in writing an IDE or plugin is
 time that could instead be spent writing programs that are useful in
 some other language.  That's why languages with better tooling usually
 have a lot of support from companies. The companies recognize that
 investing in the tools can help make some of their programmers more
 productive and it's worth the cost.
I wonder if the D foundation can help in this regard? Pay somebody to improve the tooling, etc.. T -- "If you're arguing, you're losing." -- Mike Thomas
Jan 29 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/01/2018 9:35 AM, H. S. Teoh wrote:
 On Mon, Jan 29, 2018 at 01:23:49AM +0000, jmh530 via Digitalmars-d wrote:
 [...]
 It's probably that they view programming languages as a tool to get
 things done. Investing a lot of time in writing an IDE or plugin is
 time that could instead be spent writing programs that are useful in
 some other language.  That's why languages with better tooling usually
 have a lot of support from companies. The companies recognize that
 investing in the tools can help make some of their programmers more
 productive and it's worth the cost.
I wonder if the D foundation can help in this regard? Pay somebody to improve the tooling, etc.. T
They are, dmd as a library :)
Jan 29 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 16:18:40 H. S. Teoh via Digitalmars-d wrote:
 On Sun, Jan 28, 2018 at 05:13:15PM -0700, Jonathan M Davis via 
Digitalmars-d wrote:
 Either way, more folks need to put some time and/or money towards IDE
 development for D, or the folks who want first class IDE support for D
 are never going to have what they want.
Still, it's strange that given the number of people who demand first class IDE support, there are so few who are willing to contribute to improving it.
I suspect that part of the problem is that if they really care that much about having an IDE, they don't get into D far enough to then put in the time to improving the situation.
 Personally, I don't really care, because I have no interest in such
 support.  I have no problem if it gets implemented, and it probably is
 better for the D community if we have better IDE support, but it
 wouldn't improve my life any. If we're going to get improved tooling,
 I'd rather see more improvements to stuff like dub than better IDE
 support. So, I generally ignore the complaints about the lack of good
 IDE support. Either way, it's not something that I'm going to spend
 time on. I have too much on my TODO list already.
[...] It doesn't really concern me either, but neither do I want the indifference of the non-IDE folk to be misunderstood as active neglect. But people will see what they want to see, so meh, I guess. All I can say is, after coming to D, I did find some things not quite to my liking, so I fixed them myself and submitted PRs. And so did many others like me. And we're all better off for it. Now if only more from the IDE crowd would do the same, things might be different...
That's really the only way that anything gets done around here. Someone decides that they want something fixed or implemented, so they put in the time to do it themselves, and everyone benefits. Almost nothing happens because of folks posting about how they want something done. The net result is that what gets done is heavily biased towards what the folks willing to put in the time and effort want done. - Jonathan M Davis
Jan 28 2018