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.
