On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
> 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, ... ).

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

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

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

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

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.

> 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

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.

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.

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 debugging. Or we can take it a level higher, and go into Java/C# 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 really have a chance with Java/C# IDEs and probably never will. 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.

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!"

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.

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