On Monday, 3 September 2018 at 18:52:45 UTC, Laurent Tréguier wrote:
> On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:
>> it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk."
>
> Well it comes with the Boost license that says: `THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND`

You know exactly what I mean, don't you?

On 09/03/2018 02:55 PM, Joakim wrote:
> On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
>> But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves
> 
> Why is that? I've never used an IDE much, but I wonder why you don't and what your impressions are of why many other core D users don't either.

I used to use them all the time, but it got too frustratingly difficult to find ones that didn't take forever to start up, and didn't lag like crazy while trying to get my work done.

Plus, I've done so much development on so many platforms that (even if only at the time) didn't have much in the way of either IDE or debugger support (or good support for *my* current IDE and required me to use *their* IDE), that I just learned how to be productive with basic editor + file manager + command line. With those, I can do pretty much anything I need for just about any platform/language.

Whenever I've relied on an IDE, I was constantly dealing with bad support for X in language Z, no support for Y when deving for platform W, trying to do Q was a big series of steps that could NOT be easily automated, etc...It was an endless mess, and trying to add support for XYZ was always a major project in an of itself. And there was ALWAYS something new I needed support for, but couldn't get and didn't have the time to build. It was a series of prisons. Weening myself off IDEs freed me.

I'll tell you, it's REALLY nice being able to get my work done, *improve* my workflow as I see fit(!!), in just about any language I need, for just about any target platform I need, without ever having to whine about "I can't use your tech unless you build better integration with this one particular IDE!" (Sound similar to anything often heard around here? ;))

Plus, plain old non-IDE editors have come a LONG, long way in the last 20 years. (For example, syntax highlighting used to be something you mainly just got with the IDEs. Not anymore!)

On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:

>
> I think this sort of misunderstanding is the source of a lot of friction on this forum. Some users think (or in my case: thought) that D will be a sound and stable language one day, a language they can use for loads of stuff, while the leadership prefers to keep it at a stage where they can test ideas to see what works and what doesn't, wait let me rephrase this, where the user can test other people's ideas with every new release.

D is not a petri dish for testing ideas. It's not an experiment. It's a serious language. Walter, Andrei, and everyone involved in maintaining and developing it want to see it succeed. They aren't just treading water, wasting everyone's time. And I know you keep hearing this, but I'll say it anyway: most of the development is based on volunteer work, and trying to get volunteers to do anything they don't want to do is like asking them to voluntarily have their teeth pulled when they don't need to.

Walter has said that people come to him and ask what they should work on. He provides them with a list of priority tasks. Then they go off and work on something else. That's the nature of unsponsored open-source development and has been the biggest challenge for D for years.

I have high hopes that some of this can be turned around by raising more money and I have long-term plans to try and facilitate that over the coming months. With more money, we can get people to work on targeted tasks even when they have no vested interest in it. We can pull in full-time coders, maybe get someone to oversee PR reviews so they don't stay open so long, fund development of broader ecosystem projects.

There isn't anyone involved in the core D development who isn't aware of the broader issues in the community or the ecosystem, and they are working to bring improvements. I have been around this community since 2003. From my perspective, it has been one continuous march of progress. Sometimes slow, sometimes fast, but always moving, always getting better. And right now there are more people involved than ever in moving it forward.

Unfortunately, there are also more demands on more fronts than ever. There are longtime users who become increasingly frustrated when the issues that matter to them still aren't resolved, newcomers who have no context of all the progress that has been made and instead hold D in comparison to Rust, Go, and other languages that have stronger backing and more manpower. That's perfectly legitimate.

And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/

So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth.

On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote:
> On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
>> Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code:
>>
>> https://forum.dlang.org/post/rmqvglgccmgoajmhynog@forum.dlang.org
>>
>> So, if you want stuff like that to get worked on, then donate or pitch in.
>>
>> The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related.
>>
>> - Jonathan M Davis
>
> The complaints I have is exactly why I'm myself maintaining plugins for VSCode, Atom, and others soon. Don't worry, I still think D is worth putting some time and effort into and I know actions generally get more things done than words.
> I also know that tons of stuff is yet to be done in regards to the actual compilers and such.
>
> It just baffles me a bit to see the state of D in this department, when languages like Go or Rust (hooray for yet another comparison to Go and Rust) are a lot younger, but already have what looks like very good tooling.
> Then again they do have major industry players backing them though...

Why is Go's IDE support baffling?  It was a necessity to achieve Google's commercial aims, I should think.

"
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
 – Rob Pike

I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too!  Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context.

I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages.  The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it.  So far anyway but as adoption grows maybe that will change.

On Monday, 3 September 2018 at 19:31:58 UTC, Jonathan M Davis wrote:

> Because they can't hold a candle to vim. As far as text editing goes, there simply is no comparison.



All these arguments, especially the above, makes me sad.

May be this is the nature of open source that volunteers will work only on things that they like and may not always be aligned with all the users needs.

D was born almost two decades ago when IDEs and tools that make user experience smooth as defined by current standards didn't exist that freely. Major competition then was c++ and Java.

D was a breath of fresh air. It was as fast as c++ and as clean as Java. No wonder many people loved D.

Nowadays the programming language landscape is much different. With Go, Rust, etc the competition is not only catching up but even surpassing D in popularity. I wonder why. I sometimes feel D is still stuck in the previous era.

At least in my experience this smoothness factor has a heavy weight. I abandoned Java wonderful ecosystem for D's native and fast compilation and fast startup. I wrote D programs in notepad++ etc. I endured lack of so many wonderful features of a mature IDE like eclipse or netbeans.

Now after 20ish years still a mature and smooth ecosystem is no where in sight. D did find some success with expert programs,  good for them, but I couldnt take it any more.

Funnily, I went back to Java. The improvements in java language, JVM and hardware in general lessened the pain of java very much. It was amazing how much easy and smooth experience matters to increase the productivity.

I still keep an eye on D, the ecosystem seems to be getting better although at glacial pace. Everytime I read a comment like above, this comes to my mind

https://imgs.xkcd.com/comics/supported_features.png

On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote:
> On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote:
>> Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot.

I didn't give a you don't need an IDE speech, and I didn't say a smooth experience was a bad thing.

But in my experience a strong reality orientation leads to good things coming out of life and telling the universe it should be something different from what it is is a recipe for misery and suffering, and why would you do that to yourself?

So if you want the world to be different, come up with a plan.  It could be I am going to donate X dollars a month to the Foundation to fund IDE development, or if could be figuring out how you can help with the work in whatever way.  But just grumbling - I really think that mistakes the nature of the situation, and not to mention human psychology.  You can accomplish things with a vision that's thought through and inspires others.  Negativity is part of being creative but not if you stop there.


> Its the same issue why Linux as a Desktop has been stuck with almost no growth. Its easy to break things ( nvidia graphical driver *lol* ), too much is so focused on the Cli that people who do have a issue and are not system users quick run into a flooding swamp.
>
> Too much resources split among too many distributions, graphical desktops etc. Choice is good but too much choice means projects are starved for resources, comparability are issues, bugs are even more present, ...

Chrome books and Android seem to be doing okay.  I run Linux on the desktop and have done full-time since 2014.  Maybe you're right that it's not for everyone at this point.  And so ?  There just wasn't a path for people to put effort into making it utterly easy for non technical people beyond a certain point.  Does that mean Linux or Linux on the desktop has failed?  I don't think so.  It's just not for everyone.
It's interesting to see Microsoft making it possible to run Linux on Windows - turns out a minority audience can be an important audience.

> A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it.

What resources do you think go into GDC?  I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages.

> Its just so frustrating that a lot of people here do not understand. Most programmers are not open-source developers, they are not coding gods, they are simply people who want things to good smooth. Install compiler, install good supported graphical IDE ( and no, VIM does not count! ), read up some simple documentation and off we go... We are not looking to be bug testers, core code implementer's, etc...

Sure, and probably most people would be better off at this point using a language that makes getting started easy.  One doesn't need to appeal to most people to succeed.  That's just a pragmatic statement of the obvious.  In time it will change but j don't see how recognising your observation could rationally lead anyone to do something differently from what they would have done before.

To change the world you need a goal and a first cut at a plan for getting there. Whether the goal is entirely realistic is much less important than having a plan to begin.  And I speak from experience here having at certain points not much more than that.


> Selfish, ... sure ... but this is how D gain more people. The more people work with your language, the more potential people you have that slowly are interested in helping out.

I disagree.  At this point the way for D to appeal to more people is to increase its appeal just a bit more to those who are already on the cusp of using D or would be if they had looked into it and to those who  use D already in some way but could use it more. The way for D to appeal to more people is not to address the complaints of those who spend more time writing on the forum grumbling but don't use it much, because in my experience you do much better appealing to the people who are your best customers than to those who tell you if only you could do X there would be huge demand.  I think that has been Walter's experience too.

Like I say, the advantage of being the underdog is that you don't need to appeal to everyone to continue to grow.

> But when D puts the carrot in front of the cart instead of the mule. Then do not be so surprised that a lot of people find D extreme frustrating and have a love-hate relationship with it.

Sure.  That's not surprising.  It's surprising that people think by complaining rather than taking action they will achieve much of a change in the world.  But with human nature it has always been thus, I suppose.

On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote:
> > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
> >> Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code:
> >>
> >> https://forum.dlang.org/post/rmqvglgccmgoajmhynog@forum.dlang.org
> >>
> >> So, if you want stuff like that to get worked on, then donate or pitch in.
> >>
> >> The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related.
> >>
> >> - Jonathan M Davis
> >
> > The complaints I have is exactly why I'm myself maintaining
> > plugins for VSCode, Atom, and others soon. Don't worry, I still
> > think D is worth putting some time and effort into and I know
> > actions generally get more things done than words.
> > I also know that tons of stuff is yet to be done in regards to
> > the actual compilers and such.
> >
> > It just baffles me a bit to see the state of D in this
> > department, when languages like Go or Rust (hooray for yet
> > another comparison to Go and Rust) are a lot younger, but
> > already have what looks like very good tooling.
> > Then again they do have major industry players backing them
> > though...
>
> Why is Go's IDE support baffling?  It was a necessity to achieve Google's commercial aims, I should think.
>
> "
> The key point here is our programmers are Googlers, they’re not
> researchers. They’re typically, fairly young, fresh out of
> school, probably learned Java, maybe learned C or C++, probably
> learned Python. They’re not capable of understanding a brilliant
> language but we want to use them to build good software. So, the
> language that we give them has to be easy for them to understand
> and easy to adopt."
>   – Rob Pike
>
> I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context.
>
> I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages.  The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it.  So far anyway but as adoption grows maybe that will change.

It's been a key hurdle for as long as I've been around here.
I've been saying for 10 years that no company I've ever worked at can
take D seriously without industry standard IDE support.
My feeling is that we have recently reached MVP status... that's a
huge step, 10 years in the making ;)
I think it's now at a point where more people *wouldn't* reject it on
contact than those who would. But we need to go much further to make
developers genuinely comfortable, and thereby go out of their way to
prefer using D than C++ and pitch as such to their managers.
Among all developers I've demo-ed or introduced recently, I can say
for certain that developer enthusiasm is driven by their perception of
the tooling in the order of 10x more than the language.

On Tuesday, 4 September 2018 at 02:24:25 UTC, Manu wrote:
> On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote:
>> > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
>> >> Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code:
>> >>
>> >> https://forum.dlang.org/post/rmqvglgccmgoajmhynog@forum.dlang.org
>> >>
>> >> So, if you want stuff like that to get worked on, then donate or pitch in.
>> >>
>> >> The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related.
>> >>
>> >> - Jonathan M Davis
>> >
>> > The complaints I have is exactly why I'm myself maintaining
>> > plugins for VSCode, Atom, and others soon. Don't worry, I still
>> > think D is worth putting some time and effort into and I know
>> > actions generally get more things done than words.
>> > I also know that tons of stuff is yet to be done in regards to
>> > the actual compilers and such.
>> >
>> > It just baffles me a bit to see the state of D in this
>> > department, when languages like Go or Rust (hooray for yet
>> > another comparison to Go and Rust) are a lot younger, but
>> > already have what looks like very good tooling.
>> > Then again they do have major industry players backing them
>> > though...
>>
>> Why is Go's IDE support baffling?  It was a necessity to achieve Google's commercial aims, I should think.
>>
>> "
>> The key point here is our programmers are Googlers, they’re not
>> researchers. They’re typically, fairly young, fresh out of
>> school, probably learned Java, maybe learned C or C++, probably
>> learned Python. They’re not capable of understanding a brilliant
>> language but we want to use them to build good software. So, the
>> language that we give them has to be easy for them to understand
>> and easy to adopt."
>>   – Rob Pike
>>
>> I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context.
>>
>> I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages.  The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it.  So far anyway but as adoption grows maybe that will change.
>
> It's been a key hurdle for as long as I've been around here.
> I've been saying for 10 years that no company I've ever worked at can
> take D seriously without industry standard IDE support.
> My feeling is that we have recently reached MVP status... that's a
> huge step, 10 years in the making ;)
> I think it's now at a point where more people *wouldn't* reject it on
> contact than those who would. But we need to go much further to make
> developers genuinely comfortable, and thereby go out of their way to
> prefer using D than C++ and pitch as such to their managers.
> Among all developers I've demo-ed or introduced recently, I can say
> for certain that developer enthusiasm is driven by their perception of
> the tooling in the order of 10x more than the language.

That's only because you insist on working for companies where people use IDEs and think the ones that don't must be in boring industries :)

Kidding aside, would you care to enumerate what capabilities are missing that would tip the balance for such people were they to be there?

And then would you care to estimate the degree of work involved in implementing them.  For decent and motivated people, how many man years ?

Knowing the full scope of a problem is sometimes one step towards solving it.

And how would you rate the importance of  tooling Vs finishing C++ integration
?

On 9/3/2018 7:19 PM, Laeeth Isharc wrote:
> The way for D to appeal to more people is not to address the complaints of those who spend more time writing on the forum grumbling but don't use it much, because in my experience you do much better appealing to the people who are your best customers than to those who tell you if only you could do X there would be huge demand.  I think that has been Walter's experience too.

I've bin in this business a long time. Fun anecdotes:

---

I was out jogging with a colleague in the 1990's one day. He said what the world really needs, and what he really needed, was a Java implementation that generated native code. It would set the world on fire!

I told him I wrote one, he could get it today from Symantec. He never said another word on the subject. It turns out nobody wanted a native Java compiler.

---

Back in the old Datalight days in the 1980s, a big customer said they couldn't use Datalight C because it didn't have Feature X. If only it had X, they'd place a Big Order. So I implemented X, and excitedly showed it to them and asked for the Big Order. They hemmed and hawed, then said what they really needed was Feature Y!

After that, I was a lot less credulous of dangling promises of a Big Order. I'd often say sure, and ask for an advance on the order, which worked well at filtering out the chain-jerking.

---

Related to me by a friend: X told me that what he really wanted in a C++ compiler was compile speed. It was the most important feature. He went on and on about it. I laughed and said that compile speed was at the bottom of his list. He looked perplexed, and asked how could I say that? I told him that he was using Cfront, a translator, with Microsoft C as the backend, a combination that compiled 4 times slower than Zortech C++, and didn't have critical (for DOS) features like near/far pointers. What he really regarded as the most important feature was being a name brand.

---

Henry Ford said that his market research suggested that people wanted a faster horse.

---

Trying to figure out where we should allocate our scarce resources is probably the most difficult task I face. I know it looks easy, but it is all too easy to wind up with a faster horse when everyone else developed a car.

On Mon, 3 Sep 2018 at 19:35, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 4 September 2018 at 02:24:25 UTC, Manu wrote:
> > On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote:
> >> > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
> >> >> Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code:
> >> >>
> >> >> https://forum.dlang.org/post/rmqvglgccmgoajmhynog@forum.dlang.org
> >> >>
> >> >> So, if you want stuff like that to get worked on, then donate or pitch in.
> >> >>
> >> >> The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related.
> >> >>
> >> >> - Jonathan M Davis
> >> >
> >> > The complaints I have is exactly why I'm myself maintaining
> >> > plugins for VSCode, Atom, and others soon. Don't worry, I
> >> > still
> >> > think D is worth putting some time and effort into and I know
> >> > actions generally get more things done than words.
> >> > I also know that tons of stuff is yet to be done in regards
> >> > to
> >> > the actual compilers and such.
> >> >
> >> > It just baffles me a bit to see the state of D in this
> >> > department, when languages like Go or Rust (hooray for yet
> >> > another comparison to Go and Rust) are a lot younger, but
> >> > already have what looks like very good tooling.
> >> > Then again they do have major industry players backing them
> >> > though...
> >>
> >> Why is Go's IDE support baffling?  It was a necessity to achieve Google's commercial aims, I should think.
> >>
> >> "
> >> The key point here is our programmers are Googlers, they’re not
> >> researchers. They’re typically, fairly young, fresh out of
> >> school, probably learned Java, maybe learned C or C++, probably
> >> learned Python. They’re not capable of understanding a
> >> brilliant
> >> language but we want to use them to build good software. So,
> >> the
> >> language that we give them has to be easy for them to
> >> understand
> >> and easy to adopt."
> >>   – Rob Pike
> >>
> >> I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context.
> >>
> >> I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages.  The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it.  So far anyway but as adoption grows maybe that will change.
> >
> > It's been a key hurdle for as long as I've been around here.
> > I've been saying for 10 years that no company I've ever worked
> > at can
> > take D seriously without industry standard IDE support.
> > My feeling is that we have recently reached MVP status...
> > that's a
> > huge step, 10 years in the making ;)
> > I think it's now at a point where more people *wouldn't* reject
> > it on
> > contact than those who would. But we need to go much further to
> > make
> > developers genuinely comfortable, and thereby go out of their
> > way to
> > prefer using D than C++ and pitch as such to their managers.
> > Among all developers I've demo-ed or introduced recently, I can
> > say
> > for certain that developer enthusiasm is driven by their
> > perception of
> > the tooling in the order of 10x more than the language.
>
> That's only because you insist on working for companies where people use IDEs and think the ones that don't must be in boring industries :)
>
> Kidding aside, would you care to enumerate what capabilities are missing that would tip the balance for such people were they to be there?
>
> And then would you care to estimate the degree of work involved in implementing them.  For decent and motivated people, how many man years ?
>
> Knowing the full scope of a problem is sometimes one step towards solving it.
>
> And how would you rate the importance of  tooling Vs finishing
> C++ integration
> ?

I'm working to move the bar on C++ integration, and Atila, yourself,
etc also seem to have active work on that front... so I'm fairly
confident at this stage that that's on course towards where it needs
to be.
There's a couple of hard problems though that are significant DMD developments.

- Cross-language class hierarchies require that extern(C++) construction semantics mimic C++, which I think is reasonable. There's been plenty of discussion, stakeholders mostly know what to do, but it's a significant job.

I can't estimate work involved in IDE tooling, I have no experience in
that area; it's all C# and MS integration API's.
Rainer's probably the only person who can comment with authority.

For VisualD, which is the only environment that really matters to my
industry, I'd suggest an expected feature set would look something
like (in no particular order):
- Auto-complete suggestions should be fast and accurate. (Currently,
suggestions tend to be incomplete, and there also seems to be a lot of
junk in the suggestion list that shouldn't be there)
  * Auto-complete is the _primary_ method of discovering API's that
they don't often interact with. They will use the suggestion data to
quickly learn the API and move on with their task without a break in
productivity.
  * Most corp code is not documented, has none or poor comments,
expert might be in another office (or gone). Auto-complete suggestions
save heaps of time breaking flow and trawling through foreign code.
- Additional support for plugging in cross-compilers (Android, consoles).
- Features that a typical C# developer expects, ie, refactoring tools:
  * Rename symbols throughout code.
  * Suggest import module when calling a function or using a type
that's not in scope.
  * Cleanup imports; remove imports with no references.
  * Etc... (ask any C# developer which are their favourite features;
they are the things they will miss)
- Goto definition must *always* work.
- Syntax colouring that's comprehensive and *accurate*; semantically
correct. (VS actually sets a low-bar on this, practically everyone
uses Visual Assist for syntax highlighting, we should aim for that)
- Performance feels clunky at times. It shouldn't feel sluggish at any
time if it wants to inspire confidence.

A lot of these issues lean on general problems with the semantic analysis; it seems that it has trouble with certain constructs and then just stops or gives up. So as soon as code gets complex, or there's some meta creating some indirection to symbols, it's possible that the things stop working (goto definition, correct colouring, auto-complete)

My work right now presents a very interesting opportunity; we're
telling C# programmers they have to write C++, which they particularly
hate. I think we could be appealing to C# programmers by contrast;
there's lambdas, delegates, GC, etc.
But... those guy have, and expect, arguably the very best IDE tooling
experience of any language that exists. D could nail it though, all
the great features of C# tooling map to D just fine.
If we gave them their tooling, I reckon they'd give us their loyalty :P