On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc wrote:
> On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer wrote:
>> On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote:
>>> https://www.quora.com/Why-hasnt-D-started-to-replace-C++
>>>
>>> Andrei
>>
>>
> [...]
> But really who is selling D to anyone? We are very far from that stage right now.  Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope.  People who had earned the authority to decide became aware of the language end decided to use it.  And they did so because for them it solved their particular problems better then anything else they could think of.
> [...]

This would be relevant if Microsoft actually followed up on that, but
it was an one shot prototype, done by one of their employees.

Nothing followed up from there.

Instead what happened was UWP, C++/CX extensions and now with the effort lead by
Kenny Kerr, C++/WinRT implemented in C++17.

On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc wrote:
> But really who is selling D to anyone? We are very far from that stage right now.  Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope.  People who had earned the authority to decide became aware of the language end decided to use it.  And they did so because for them it solved their particular problems better then anything else they could think of.

The question one needs to ask is more: how long ago have those developers decided to use D and why is the technology not more widespread in those companies.

If D solved the issues in those companies, you expect to see a increased switch to a language.

And yet most of those companies use D in one project and it stays in that one project. That means other developers do not switch, management has no task to introduce it elsewhere and the project is more or less supported by the developer that pushed for the technology.

On Thursday, 8 February 2018 at 15:56:16 UTC, Martin Tschierschke wrote:
> You will get 9 packages listed. Which should I take?
> If you click on everyone, you will realize, that some of them are forks of other.
> And the version number of mysql-native at the top, just recently increased so strong, that it makes a different.
> The minimum additional information which should be listed - I think - is the number of downloads and GitHub stars.
>
> I know that there is work behind the scene to find some kind of weighted sort, this would be cool, but just displaying the GitHub voting might help a lot.

The answer to that is simply pick: null.

Two depend on vibe.d core. Several others have not been updated. As you stated several are forks. And not a single one is a official D supported package.

For basic technology as database's: Mysql, PostgreSQL, Sqlite, Firebird, MongoDB you expect this to be under the standard library for D, with official support.

The reason why scripting languages do good in user adaptation is simply because they offer all the necessary dependencies as official libraries.

Any language that depends on 3th party developers to provide this support can never have a standardized structure and forces people into making choices they may regret. Add also a total lack of quality control.

Extra fun: etc.c.sqlite3

On Friday, 9 February 2018 at 13:08:25 UTC, Bo wrote:
> On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc wrote:
>> But really who is selling D to anyone? We are very far from that stage right now.  Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope.  People who had earned the authority to decide became aware of the language end decided to use it.  And they did so because for them it solved their particular problems better then anything else they could think of.
>
> The question one needs to ask is more: how long ago have those developers decided to use D and why is the technology not more widespread in those companies.
>
> If D solved the issues in those companies, you expect to see a increased switch to a language.

That conclusion relies on the assumption that programmers / managers / tech leads / CTOs choose programming languages based on technical merits alone. While there are certainly people who do that, in my experience they are in a small minority.

There's inertia, tribalism, sunk cost fallacy, fear of the unknown, fear of change, lack of wanting to invest time in a new technology, "if it ain't broke don't fix it" (touted many a time by people who either ignore security exploits or justify it saying it's not the language's fault but bad programmers), popularity, herd mentality, ...

Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.

Atila

>
> And yet most of those companies use D in one project and it stays in that one project. That means other developers do not switch, management has no task to introduce it elsewhere and the project is more or less supported by the developer that pushed for the technology.

On Friday, February 09, 2018 14:01:02 Atila Neves via Digitalmars-d wrote:
> Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.

The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse.

- Jonathan M Davis

On Friday, 9 February 2018 at 14:49:27 UTC, Jonathan M Davis wrote:
> On Friday, February 09, 2018 14:01:02 Atila Neves via Digitalmars-d wrote:
>> Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.
>
> The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse.
>
> - Jonathan M Davis

That's... new. Cognitive dissonance never ceases to amaze me.

Atila

On Friday, 9 February 2018 at 14:01:02 UTC, Atila Neves wrote:
> Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.
>
> Atila

You should have tried to convince them to do TDD. ;)

On Friday, 9 February 2018 at 13:21:09 UTC, Bo wrote:
> For basic technology as database's: Mysql, PostgreSQL, Sqlite, Firebird, MongoDB you expect this to be under the standard library for D, with official support.
>
> The reason why scripting languages do good in user adaptation is simply because they offer all the necessary dependencies as official libraries.
>
> Any language that depends on 3th party developers to provide this support can never have a standardized structure and forces people into making choices they may regret. Add also a total lack of quality control.

Does C++ have such support in its standard library?

On Friday, 9 February 2018 at 14:49:27 UTC, Jonathan M Davis wrote:
> On Friday, February 09, 2018 14:01:02 Atila Neves via Digitalmars-d wrote:
>> Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.
>
> The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse.
>
> - Jonathan M Davis

Actually, it can make lazy programmers write worse code if they write code to satisfy the tests instead of writing code according to the spec...

On 2/9/2018 6:01 AM, Atila Neves wrote:
> Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.

Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests.

D's unit testing system didn't even need to be very good. It just had to be *easy*. And that changed everything.