D IDE

[Jonathan M Davis]

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