On Wednesday, 24 September 2014 at 08:04:18 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 24 Sep 2014 07:56:58 +0000
> Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> This isn't true. I'm a C++ developer who migrated to D. I'm still (also) a C++ developer. And a D developer. And a Python developer. And...
> so you aren't migrated. using D for some throwaway utils and so on is
> not "migrating". "migrating" is "most of codebase in D".

Most of us cannot afford to be a "Technology X" developer.

Every project, every client is a complete new world.

--
Paulo

On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 23 Sep 2014 21:59:53 -0700
> Brad Roberts via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> I understand quite thoroughly why c++ support is a big win
> i believe it's not.
>

Every C++ shop I've been has one or several C++ codebase that just can't just be rewritten while the customers patiently wait.

To thrive in the enterprise D must wait for a greenfield project with zero pre-existing source files (ie. rare), be a small project, or be able to interact with the legacy codebase.

I think Andrei accurately identified C++ interop as the top-goal.

On Wednesday, 24 September 2014 at 07:41:48 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 23 Sep 2014 23:24:21 -0700
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> > I completely agree. Lets focus on the D users we actually have, not
>> > some imaginary C++ users that will come running as soon as there is
>> > enough C++ support.
>> Those are very real. I know this for a fact. -- Andrei
> all three of them.

I don't understand how it isn't obvious how important C++ interop would be in getting new users to switch. I especially don't understand it since it's been mentioned several times so far how important C interop was for C++'s adoption.

I write unit tests at work for C code in C++. Because I can. To this day, C++ is getting used because it's C-compatible.

Atila

On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
wrote:
> On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
>> On 24/09/14 06:31, Walter Bright wrote:
>>
>>> But it is a bit unreasonable to expect
>>> large project maintainers to rebuild and check for bugs every day. It's
>>> why we have a beta test program.
>>
>> The solution is to make it automatic.
>
>
> There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.

It doesn't exist because no one has created it yet :)

> Heck, the dmd release package build scripts break every single release cycle.

Digger succeeds in building all D versions in the last few years.
It doesn't build a complete package like the packaging scripts,
but the process of just building the compiler and standard
library is fairly stable.

On Wed, 24 Sep 2014 09:15:27 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Most of us cannot afford to be a "Technology X" developer. Every project, every client is a complete new world.
yeah. and so there is *no* *reason* to stress c++ interop, heh. 'cause "client dictates language" anyway. i like it.

On Wednesday, 24 September 2014 at 04:36:33 UTC, Walter Bright wrote:
> On 9/23/2014 9:08 PM, Vladimir Panteleev wrote:
>> On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote:
>>> This is completely unworkable.
>>
>> Mister, please stop hurting the pool straw man.
>>
>> Let me quote the relevant part:
>>
>>>>> They don't necessarily need to be blocking, just a notice "hey, your PR
>>>>> broke this and that project" would surely be helpful to detect the breakages
>>>>> early on.
>>
>> I think that aside from the technical limitations, that's completely reasonable,
>> and does not put any undue obligation on anyone.
>
> Who is going to maintain the autotester version of these projects?
>
> What I'd like to see is the autotester regularly build release packages out of HEAD. Then, large project maintainers can create their own scripts to download the latest compiler and attempt to build their project.

We've been talking about this since last year's DConf. I don't know if it's ever going to happen, but now there is Digger, which solves most of the same problem.

Nevertheless, this is not enough. It must be automatic - it must verify the state of things daily, without human intervention. It's unreasonable (borderline absurd, even) to expect that every large project maintainer to manually verify if their project still works every day.

It doesn't need to run on the same hardware as the autotester. It can run on the project maintainers' servers or home computers. But it must be easy to set up, and it should notify both the project owners and the pull request authors.

On Wed, 24 Sep 2014 09:28:25 +0000
ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> To thrive in the enterprise D must wait for a greenfield project with zero pre-existing source files (ie. rare), be a small project, or be able to interact with the legacy codebase.
> 
> I think Andrei accurately identified C++ interop as the top-goal.
no sane management (and insane too, even more) will resist to adding new language to codebase without really strong arguments. especially not hyped language. managers knows about java, they heard about c++ and they don't care what that "D" is. no c++ interop can change this.

so: c++ interop will help D adoption in enterprise == false. this thing alone moves c++ interop to the bottom of the list.

On Wed, 24 Sep 2014 09:33:30 +0000
Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I don't understand how it isn't obvious how important C++ interop would be in getting new users to switch.
'cause it's not.

> I especially don't understand it since it's been mentioned several times so far how important C interop was for C++'s adoption.
you are wrong. C++ is *almost* compatible with C *on* *the* *source* *code* *level*. D is not and will not. this is two completely unrelated things.

it doesn't matter how hard D will try to interop with C++, D will never be able to compile C++ code. yet C++ *is* able to compile C code. do you see any difference here?

On Wed, 24 Sep 2014 08:53:50 +0000
user via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> its littered with @
> like a scripting language. that really sucks!
do you like the fact that you can't have variable named "body"? do you want to have more such forbidden names?

On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
> On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
> wrote:
>> On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
>>> On 24/09/14 06:31, Walter Bright wrote:
>>>
>>>> But it is a bit unreasonable to expect
>>>> large project maintainers to rebuild and check for bugs every day. It's
>>>> why we have a beta test program.
>>>
>>> The solution is to make it automatic.
>>
>>
>> There's no such thing as automatic testing of someone's moving target large
>> project with another moving compiler target.
>
> It doesn't exist because no one has created it yet :)

I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on.


>> Heck, the dmd release package build scripts break every single release cycle.
>
> Digger succeeds in building all D versions in the last few years.
> It doesn't build a complete package like the packaging scripts,
> but the process of just building the compiler and standard
> library is fairly stable.

Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.)