Breaking changes in Visual C++ 2015

[deadalnix via Digitalmars-d]

Sometime, one got to be harsh, but the truth is that D have many 
mostly implemented features, often falling short in some cases or 
working in a way that make no sense.

On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:
> On 5/7/2015 5:16 AM, d user wrote:
>> the truth is, one of the biggest things holding D back from 
>> mass adoption is the
>> complete lack of tooling compared to  basically every other 
>> mainstream language.
>
> D has some excellent tools that are generally nonstandard, 
> klunky or nonexistent in other languages:
>
> 1. unit testing

The way D runs tests before running the app does not make any 
sense. The way you can't run them for a module without a main 
makes no sense. The way you end runnign all kind of test with the 
ones you are interested in makes no sense.

Yes D has easy syntax to make unitests. Meaning it is a great 
language in that regard.

But it has horrible tooling that can be regarded at best as a 
glorified hack that is mostly useless at scale.

> 2. documentation generation

The fact this is backed into the language the way it is mostly 
show a lack of separation of concerns. That is a side effect of 
the fact the frontend is completely monolithic.

You don't need to bake that into the language when the compiler 
can feed symbol information to 3rd party tools.

> 3. coverage analysis

I'm not sure how Go and Rust stand on that one, but all 
mainstream languages have descent code coverage, with the added 
bonus that this is very well integrated with the rest of the 
tooling (tolling which is non existent in D). I would not put 
this has a string point of D. Not bad either, but definitively 
what you'd expect from any serious language.

Last but not least, things like:
if (foo && bar) ...;

Contains 2 branches. The output we have to not provide data about 
this, which makes the coverage infos lacking in some regard.

In java for instance, I could run tests (and not the whole 
program with test at startup) and get all the coverage infos 
directly in my editor with colors and stuff, include things like 
short circuit for boolean operators, which we don't have. We are 
miles (kilometers damn it !) away from this level of support.

> 4. profiler

Same things, this is a standard tool nowaday for any language 
worth considering. In fact, even if we had no specific support in 
D for it, C/C++ tooling could probably do it for us to some 
extent.

> 5. and as of last week, a memory usage profiler
>

Good memory allocator like tcmalloc and/or jemalloc have detailed 
output. And if we go back to java, you can even observe things in 
a graphic way in real time concurrently to the application 
running ! Once again, we are not even remotely close to anything 
like this.