D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Manu]

On Mon, 3 Sep 2018 at 19:35, Laeeth Isharc via Digitalmars-d
<digitalmars-d at 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 at 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