https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

I'm sharing this specifically so we can have an unproductive flamewar about whether breaking changes in D are sometimes worth it or if they are holding D back from mass adoption :).

On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>
> I'm sharing this specifically so we can have an unproductive flamewar about whether breaking changes in D are sometimes worth it or if they are holding D back from mass adoption :).

How about a productive design oriented working group instead of a flame war?

I totally side with Walter when he says that drip-drip-drip changes are taxing on people who does not work full time with a language, but have serious intents with being involved.

I also totally understand his fear of alienating the existing user base by changing the language in ways that makes the existing user base change their personal programming idioms (whether they are sound and clean or the opposite).

However, rhe transition to D for DMD provides:

- Opportunity to rethink compiler internals.

- Opportunity to refactor the compiler so that you can get better tooling/automatic transcompiling from D2 to a hypthetical D3 if need be.

And therefore also an opportunity to rethink the language semantics.

If you want to rethink language semantics you should start with tabula rasa (assume no existing langauge). Then come up with the hypothetical ideal high level design for the kind of programming D is meant for. When you have that, you have much better chance to redesign the existing language with an upgrade path to something consistent.

Semantic drip-drip-drip metamorphosis is generally not very good for an axiomatic system (which programming language internals have to be).

If it was up to me I'd focus on 5 areas:

- stronger typing / behavioural typing

- memory model

- see if it is possible to redesign and implement the templating system with something that is close to Datalog to get  more streamlined metaprogramming

- high level IR for whole program optimization with partial evaluation

- identifying a sub langauge that can be used for building a small SIMD oriented backend for innnerloops (generating different variants SSE2/SSE3/AVX/AVX2 based on cpu info).

On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>
> I'm sharing this specifically so we can have an unproductive flamewar about whether breaking changes in D are sometimes worth it or if they are holding D back from mass adoption :).

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.

Compare D to Go,
https://golang.org/cmd/go/

Go comes with a package manager, a linter, a static analysis tool, a formatter. Does D have these in some form? Sure. But you have to go hunting for them, and they're OK at best.

And really, the only thing to blame for this is dmd. Go provides a Go parser and tokenizer right in their standard library - just one of the benefits of their compiler being written in Go.

A lot of D's issues come back to: dmd is long in the tooth. Things D used to tout(faster compiler times) aren't really there anymore. My _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling. Due to how modules are compiled, it's _slower_ to do separate object compilation like in C++, so it's impossible to even get a gain from parallel compilation.

Then you have LDC and GDC which generally lag behind dmd by a version or two(usually moreso for GDC,) fragmenting the libraries heavily because many new D versions fix tons of bugs. Due to dmd's license, it can't even be redistributed on Linux, BSD, etc. So now you have compilers for major Linux distros that are lagging versions behind. And really, the packages aren't well maintained anyways - LDC got blacklisted from Ubuntu for being unmaintained.

If there's anything to learn from Go's success, it's that you don't need a good language design to be successful. If you want D to be successful, submit some PRs to SDC. If you want D to stay unpopular, keep moving towards Haskell with braces.

On 7 May 2015 at 14:16, d user via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
>>
>> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>>
>> I'm sharing this specifically so we can have an unproductive flamewar about whether breaking changes in D are sometimes worth it or if they are holding D back from mass adoption :).
>
>
> 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.
>
> Compare D to Go,
> https://golang.org/cmd/go/
>
> Go comes with a package manager, a linter, a static analysis tool, a formatter. Does D have these in some form? Sure. But you have to go hunting for them, and they're OK at best.
>
> And really, the only thing to blame for this is dmd. Go provides a Go parser and tokenizer right in their standard library - just one of the benefits of their compiler being written in Go.
>
> A lot of D's issues come back to: dmd is long in the tooth. Things D used to tout(faster compiler times) aren't really there anymore. My _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling. Due to how modules are compiled, it's _slower_ to do separate object compilation like in C++, so it's impossible to even get a gain from parallel compilation.
>
> Then you have LDC and GDC which generally lag behind dmd by a version or two(usually moreso for GDC,) fragmenting the libraries heavily because many

*Ahem* don't make such wild claims without backing with recent and relevant evidence.


> new D versions fix tons of bugs. Due to dmd's license, it can't even be redistributed on Linux, BSD, etc. So now you have compilers for major Linux distros that are lagging versions behind. And really, the packages aren't well maintained anyways - LDC got blacklisted from Ubuntu for being unmaintained.

There's a difference between blacklisted and dropped.  In any case, it has a new maintainer and is back in now...

On Thursday, 7 May 2015 at 12:16:18 UTC, d user wrote:
> If there's anything to learn from Go's success, it's that you don't need a good language design to be successful. If you want D to be successful, submit some PRs to SDC. If you want D to stay unpopular, keep moving towards Haskell with braces.

I think Go's "success" comes from:

1. C++14 is too complicated to make sense for many commercial projects.

2. Java et al are heavy weight and makes little sense for small-and-easy-to-deploy projects.

3. Go is designed around a single concurrency idiom with theoretical backing, which makes running a pilot with it motivating.

4. Corporate backing.

5. It takes a stance on aesthetics and is therefore not too difficult to master.


I'd like to see someone make a list of programming languages that are consistently growing (I think popularity is the wrong metric, it can take decades). I bet they either:

1. focus on a particular sense of aesthetics

2. are tied to a framework

3. are domain specific

Very few languages ship with extensive tooling from the start. Tooling gives a boost, but as you can see with Dart, that is not sufficient. And Dart is arguably a better language than Go with strong domain specific advantages...

On 5/7/15 5:16 AM, d user wrote:
> On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
>> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>>
>> I'm sharing this specifically so we can have an unproductive flamewar
>> about whether breaking changes in D are sometimes worth it or if they
>> are holding D back from mass adoption :).
>
> 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.
>
> Compare D to Go,
> https://golang.org/cmd/go/
>
> Go comes with a package manager, a linter, a static analysis tool, a
> formatter. Does D have these in some form? Sure. But you have to go
> hunting for them, and they're OK at best.
>
> And really, the only thing to blame for this is dmd. Go provides a Go
> parser and tokenizer right in their standard library - just one of the
> benefits of their compiler being written in Go.
>
> A lot of D's issues come back to: dmd is long in the tooth. Things D
> used to tout(faster compiler times) aren't really there anymore. My
> _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling.
> Due to how modules are compiled, it's _slower_ to do separate object
> compilation like in C++, so it's impossible to even get a gain from
> parallel compilation.
>
> Then you have LDC and GDC which generally lag behind dmd by a version or
> two(usually moreso for GDC,) fragmenting the libraries heavily because
> many new D versions fix tons of bugs. Due to dmd's license, it can't
> even be redistributed on Linux, BSD, etc. So now you have compilers for
> major Linux distros that are lagging versions behind. And really, the
> packages aren't well maintained anyways - LDC got blacklisted from
> Ubuntu for being unmaintained.
>
> If there's anything to learn from Go's success, it's that you don't need
> a good language design to be successful. If you want D to be successful,
> submit some PRs to SDC. If you want D to stay unpopular, keep moving
> towards Haskell with braces.

Agreed except for one point - compilation speed. I've very carefully measured on comparable projects. Go is marginally faster to compile than dmd, but dmd is faster than Rust. C++ can't hold a candle to either without a large specialized build farm and a team to babysit it. -- Andrei

On 5/7/15 7:41 AM, Andrei Alexandrescu wrote:
> On 5/7/15 5:16 AM, d user wrote:
>> On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
>>> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>>>
>>> I'm sharing this specifically so we can have an unproductive flamewar
>>> about whether breaking changes in D are sometimes worth it or if they
>>> are holding D back from mass adoption :).
>>
>> 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.
>>
>> Compare D to Go,
>> https://golang.org/cmd/go/
>>
>> Go comes with a package manager, a linter, a static analysis tool, a
>> formatter. Does D have these in some form? Sure. But you have to go
>> hunting for them, and they're OK at best.
>>
>> And really, the only thing to blame for this is dmd. Go provides a Go
>> parser and tokenizer right in their standard library - just one of the
>> benefits of their compiler being written in Go.
>>
>> A lot of D's issues come back to: dmd is long in the tooth. Things D
>> used to tout(faster compiler times) aren't really there anymore. My
>> _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling.
>> Due to how modules are compiled, it's _slower_ to do separate object
>> compilation like in C++, so it's impossible to even get a gain from
>> parallel compilation.
>>
>> Then you have LDC and GDC which generally lag behind dmd by a version or
>> two(usually moreso for GDC,) fragmenting the libraries heavily because
>> many new D versions fix tons of bugs. Due to dmd's license, it can't
>> even be redistributed on Linux, BSD, etc. So now you have compilers for
>> major Linux distros that are lagging versions behind. And really, the
>> packages aren't well maintained anyways - LDC got blacklisted from
>> Ubuntu for being unmaintained.
>>
>> If there's anything to learn from Go's success, it's that you don't need
>> a good language design to be successful. If you want D to be successful,
>> submit some PRs to SDC. If you want D to stay unpopular, keep moving
>> towards Haskell with braces.
>
> Agreed except for one point - compilation speed. I've very carefully
> measured on comparable projects. Go is marginally faster to compile than
> dmd, but dmd is faster than Rust. C++ can't hold a candle to either
> without a large specialized build farm and a team to babysit it. -- Andrei

Ah, and the bleak outlook of LDC and GDC. -- Andrei

On Thu, 07 May 2015 12:16:17 +0000, d user wrote:

> If you want D to stay unpopular, keep moving
> towards Haskell with braces.

i'll go with "Haskell with braces".

On 2015-05-06 20:26, Brad Anderson wrote:
> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>
> I'm sharing this specifically so we can have an unproductive flamewar
> about whether breaking changes in D are sometimes worth it or if they
> are holding D back from mass adoption :).

I would say that the difference with the MS C++ compiler compared to D is that there's already an existing C++ standard that MS is expected to follow. Most of the breaking changes seem to be related to make MS's implementation of C++ more compatible with the C++ standard.

Compared to D where not real standard exists. There's a least three separate things trying to define what D is. The D spec on dlang.org, the compiler (DMD) and TDPL. In most cases when there's a disagreement the compiler wins.

-- 
/Jacob Carlborg

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
2. documentation generation
3. coverage analysis
4. profiler
5. and as of last week, a memory usage profiler

I know many feel that these features can be improved, sure. But the first three have knocked the ball out of the park, and number four is a solid hit. And frankly, if I had to choose between 1..5 and package manager, static analysis tool, linter, and formatter, I'd choose the former.

That said, I hope to integrate dfmt in with the main distribution soon. And we are going to switch dmd front end to D in the near future.

But let's not forget the meat and potatoes on our plate while looking at our neighbor's salad dressing.