Dicebot on leaving D: It is anarchy driven development in all its glory.

Manu turkeyman at gmail.com
Sun Aug 26 23:39:32 UTC 2018


On Sun, 26 Aug 2018 at 14:00, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 8/26/2018 12:34 PM, Manu wrote:
> > I work at a company with a thousand engineers, all VS users, D could
> > find home there if some rough edges were polished, but they
> > *absolutely must be polished* before it would be taken seriously.
> > It is consistently expressed that poor VS integration is an absolute
> > non-starter.
>
> I will tiresomely ask again, do you have a list of each and every aspect of the
> poor integration?

Tooling specifically?

Just to be clear, when I say "poor VS integration is an absolute
non-starter", I'm not necessarily saying that's where we are... I'm
just saying that's a fact.
Where I think we are today is at MVP, which is a hard fought victory in itself.
I think we've reached the point with VS integration that people won't
question it and reject it on the spot... but we have entered a place
where people feel that it's lacking quality compared to the tooling
they're used to.

Debug experience is worlds better than it's been, by contrast it's
very usable today, and you'll notice I haven't been complaining about
it... but it's still imperfect.
You should try using VisualD to debug DMD some time. You'll quickly
discover edge cases trying to evaluate all the relevant state while
stepping around. C++ RTTI is a problem (can't identify derived type in
debugger), globals are a problem, TLS is a problem.
The minor edge cases emerge frequently enough that they convey a sense
of immaturity. I'll start taking note everything I encounter a minor
debugging issue.

One specific issue I frequently encounter is with scope closure. I'd
really like to see the line of the closing '}' being emit as the line
where all destructors are called. The workflow in C++ for example:
    - Place breakpoint on the line of the closing '}' for a scope.
    - Debugger stops at that line prior to execution of scope closing
destructors, you can use step-in and enter the destructors that are
scheduled to call at the end of scope.
    - It's very awkward to break and step through destruction paths
without being able to place such breakpoints at end-of-scope.
    - Developers expect this, and are surprised when it "doesn't work".
I added a bugzilla for this issue 6 or 7 years ago... but I can't find it.

We could really use robust tools to produce a matching C++ .h file
from the extern symbols in a D module, and likewise a .di file from a
C/C++ header.
This category of tooling has many existing instances, it's
overwhelming. As far as I can tell, they're all experimental, or
broken, or designed only to target a specific application (DMD), etc.
I think it would be an advantage if there were *one* tool, that works,
in both directions, which is advertised, recommended, and maintained
by the core group.
I've evaluated them all before at various points in time, but the
landscape keeps shifting. Someone, please give me a prominent
hyperlink to the solution that *works*, and instructions. I don't have
energy to re-do comprehensive evaluations on this front, I'm spent.
Agree on one, make it the official one, and then track bugs against it
in bugzilla?

FWIW, my recent flurry of extern(C++) related PR's on DMD are only
made possible by the current state of the VS tooling. There is no way
I would have taken the time to do that work if the VS tooling wasn't
where it is. Those PR's are a direct result of VS tooling reaching
relative maturity; they would not have happened if the VS project
didn't just load and the debugger just worked.
The bar for tooling is very high, and we VS developers are quite
precious, and soft ;)

VisualD:
  Installer needs to be signed alongside DMD installer.
  Autocomplete/Intellisense is very unreliable. I don't think it has
clear visibility through enough meta constructs. Today's solutions
appear ad-hoc, I suspect they could receive a lot more assistance from
DMD.
  Go-to definition must _always_ work.
  Syntax highlighting only performs a fraction of what VisualAssist
does. Colleagues that have been experimenting with D consistently
complain that they feel colour blind.
  Find-all-references locate all symbol references in a project
  Refactoring tools (rename symbol throughout project, etc)
  Suggest and cleanup spurious imports (like C# tooling)

Rainer has done amazing work; he's tirelessly helpful, but it feels
unfair to dump this whole load onto him.
I'm not sure who or how to make these things a priority for development.

A robust 'intellisense' solution (MS nomenclature) in the form of a
library would help everyone.
It should support:
  * Comprehensive syntax highlighting which is *correct*, not just best-guess
  * Auto-complete; when I press '.' what are all valid identifiers,
and no spurious entries that aren't. Current tooling misses heaps of
stuff, and also tends to pollute the list with a lot of junk.
  * Go-to definition (ie, locate symbol) must reliably work
  * Refactor tools; eg, rename identifier throughout code
  * Suggest imports when calling functions that aren't in scope
  * Cleanup spurious imports

People learn to lean on their tooling very heavily, and they'll feel a
strong sense of loss. This puts a further burden on 'D the language'
to be _that much better_ to compensate for any such sense of loss in
tooling.
The last few experiences I list are imperfect in C++, D can
theoretically (and should) do a much better job, since scoping and
language structure is better, and there's no text includes and macros.
One great opportunity for my current project is that we're asking C#
programmers to use C++. They *hate* C++ even more than C++
programmers.
This is actually a really interesting opportunity to show them how
they can write native code and not have to hate C++... but C# sets the
bar for tooling very high.
If we were able to respond with similarly quality tooling, we'd have a
horde of C# programmers insisting we prefer D to C++ ;)


There's more things than that though.. I'll dump a list of things that
are on the front of my mind recently.

Language:
  There's the namespace thing and the ref DIP. Please just add support
for a non-scoped string namespace beside the existing solution. We
know I can't reason this with you... just... please do it for all of
us that actually use it. I'll buy you a beer.
  Andrei's copy-ctor, and the move-ctor DIP would be super-welcome
conclusions. Copy-construction is a problem. There's a set of
languages issues in this space that Andrei knows well, and they're
very important.
  I'm finding that 'const' is a practical problem. I don't know what to do.
    - Conventional wisdom; "don't use const in D", doesn't work when
interacting with C++, which uses const successfully and aggressively.
    - I use a head-const hack, which is a shim that wraps pointers and
forcefully casts-away const (technically undefined behaviour; in
practice, it works)
    - C++ people lose their mind when they see this. It would be
possible to pacify them with demonstration that D's const is superior,
but I don't know how to produce that evidence.
    - I used to buy into D's const philosophy, but I've come to
conclude that C++ got it right. Radical solutions should not be off
the table...
  ARC? What ever happened to the opAddRef/opDecRef proposal? Was it
rejected? Is it canned, or is it just back on the bench? (GC is
absolutely off the table for my project, I have no influence on this)

On DMD:
  My project is 100% DLL based. DLL's must work flawlessly.
  For STL interaction (which I'm concluding now):
    - This ABI crash is blocking me:
https://issues.dlang.org/show_bug.cgi?id=19179
    - We need a version to detect which CRT was selected at compile
time so we can emit matching data structures in our code.
    - MS .obj files have _ITERATOR_DEBUG_LEVEL definition emit to the
object file. I think we need a pragma to emit such tokens to the
object. I would make the STL modules emit the _ITERATOR_DEBUG_LEVEL as
the code was generated using said pragma.
    - https://issues.dlang.org/show_bug.cgi?id=18999
  For this project, I would ban GC, perhaps attempt using -betterC. I
have little practical experience here... but reports are often
unhappy. I'll find out I guess.
  This issue: https://issues.dlang.org/show_bug.cgi?id=18896

  Less important:
    This emerged again recently: https://issues.dlang.org/show_bug.cgi?id=18906
    Workarounds for this are problematic:
https://issues.dlang.org/show_bug.cgi?id=18845
    I wasn't able to conclude some mangling issues during my recent
effort, they interacted awkwardly with the build/test scripts, and
DMC:
      * https://issues.dlang.org/show_bug.cgi?id=18997
      * https://issues.dlang.org/show_bug.cgi?id=18958

I don't think this is exhaustive... but they're at close reach.


More information about the Digitalmars-d mailing list