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.
>
>
> I can download Go, C#, C, C++, Delphi, Rust and get proper 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

?

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

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

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.

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

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.

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

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

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

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