On Tuesday, September 4, 2018 5:56:54 AM MDT ShadoLight via Digitalmars-d wrote: > We work full-time for employers which, in my case, employs > thousands of engineers - and as a result engineering principles > are applied to everything - including tools. So all SW dev teams > here use standardized tooling/processes/coding standards/etc. - > you simply do not have a choice to use your own editor of choice.
[snip] > I really miss the appreciation of this fact in these incessant > 'use Vim/Emacs' answers to people's queries on IDE support is the > forum. This is not the reality for many people at work - this > article [1] describes the reason why businesses prefer IDE's > quite nicely. > > Most of my colleagues are not interested in hobby coding at home > - they consider their family life separate to their professional > lives - and that is perfectly OK. It is their choice. But it > makes it impossible for people like me to even try to push their > managers to "try D" if it does not fit into the > workflow/processes that are already followed. For me (like for > Manu [2]) this absolutely necessitates that it supports Visual > Studio integration _out_of_the_box_! > > When I read answers like yours and Jonathan's it always makes me > wonder: does D want to cater for the kind of businesses I > describe as well? If not, ok - that is a perfectly valid answer > and D can, as a consequence remain the slightly obscure language > it has been up to now - used by enthusiasts that are willing to > go the extra mile to get stuff done, and can hack around any > limitation. That is perfectly fine. [snip] > I know the "we use Vim/Emacs, why don't you pitch in and help on > VisualD if you want to use it" view is valid opinion, but it will > not bring the masses since it will never happen - the critical > mass is composed of devs that want to _use_ VS/eclipse/etc - not > _develop_ to enable them. Besides, they are not coding at home, > and there is very little incentive for said enterprises to assist > with this - they see it simply as a cost if D does not offer > sufficient benefit over C#/java/etc. So this is not going to > happen except as an effort inside the D community itself. Honestly, I don't understand why it would make any sense to require that all of the programmers use a particular code editor. Standardizing the build tools makes perfect sense (in fact, it would be crazy not to), and I've certainly worked at places that have required that a specific tool like visual studio or eclipse be used, because it's used for building, but they've never then disallowed using a tool like vim or emacs for code editing. And if an employer did, I'd almost certainly be looking for a new job (though finding a job that sucks less than your current one is frequently far from easy). I completely disagree that IDEs are a better tool (at least as long as you're willing to put in the time to actually learn a tool like vim or emacs), but I'm not against someone using an IDE if they want to. And even if I think that it's stupid for a company to say that you must use editor X or IDE Y (regardless of what that program may be), I do think that folks should choose whatever code editor / IDE works best for them. If a whole bunch of folks want to use VisualD, then great, more power to them. I certainly don't agree with their choice, but they're the ones writing their code, not me. I'm not looking to force vim or emacs on anyone any more than I want to be forced to write code in Visual Studio. And much as I think that IDEs are generally inferior, given how many folks insist on using them, I do think that it's good for D to have good IDE support, even if I don't want to ever use it. That being said, I'm not about to spend my time working on IDE support. While I want D to succeed, I don't spend my time on D doing things geared towards getting more people to use D. I spend my time on things that make D better as a language or which improve its libraries. That should then make it more desirable for folks to use D, and in some cases, it does get rid of obstacles that prevent folks from using D. So, I expect that that will help increase D's user base, but my entire focus is on making D better, not on trying to pave the way for others to use it - especially if it's an issue like you describe where an employer is really picky about the tools that programmers use simply to edit code. I honestly wouldn't expect a company like that to be interested in D anyway. So, I'm definitely not going to spend my free time on things aimed at making them happy, much as I sympathize with your situation. Personally, I'm only able to work in D now, because I work as a contractor. It was a lost cause to get D into any of my previous work places. They just weren't the kind of places where that was going to fly, regardless of the current state of D. Most companies and most programmers are not looking for a better programming language to use, and the reasons that they pick a particular language often has little to do with how good a language is. But ultimately, regardless of the reasons why someone might want to use an IDE, if the current state of IDEs for D is not where it needs to be for them to use D with an IDE, and the amount of effort currently being put into improving IDEs for D is not going to get those IDEs to that point soon, then someone who actually cares about the issue is going to need to either pitch in or donate so that someone else can be paid to work on it; otherwise IDE support isn't going to improve enough. Regardless of the perceived value in IDE support, there are just too many other things that need doing for most of us to want to put our free time into working on an issue that isn't going to benefit us. And while a number of us do do at least some work on D-related stuff that we don't care about aside from wanting to improve the D ecosystem for others, when the vast majority of the time being put in is on a volunteer basis, the reality of the matter is that most of the effort is going to go towards things that those contributing care about and not what the community at large might care about or what folks who may join the community might care about. That's just how it goes with open source and is part of why it can be critical for individuals or companies to donate money towards improving aspects of a project that no one wants to work on. And that's part of why it can be a big deal for there to be a big company backing a project. While it can be frustrating for someone to be told that they need to either pitch in or donate to get something that they want done, if it's something that isn't a priority for those who are spending their free time to do the work, it's often the cold the reality that that thing isn't going to get done any time soon. - Jonathan M Davis
