On Tue, 23 Sep 2014 23:54:32 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This means if we have some level of C++ interop, we have a killer feature.
and if we have OCR in phobos we have a killer feature. hey, i know two users that will switch to D if D will have good OCR in standard library! yet i know noone who will switch to D if D will get good c++ interop. note that i have many friends who are programmers and almost none of them interested in OCR.

what i want to say is that c++ interop topic is overhyped. but lets just check it: start a little survey with one question: "how many people you know that will surely switch to D if it will get great c++ interop?" i for myself already know the results of such survey.

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.

On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
> 1. Constant rejection of improvements because "OMG breaking change!".
> Meanwhile, D has been breaking my code on practically every release
> for years. I don't get this, reject changes that are deliberately
> breaking changes which would make significant improvements, but allow
> breaking changes anyway because they are bug fixes? If the release
> breaks code, then accept that fact and make some real proper breaking
> changes that make D substantially better! It is my opinion that D
> adopters don't adopt D because it's perfect just how it is and they
> don't want it to improve with time, they adopt D *because they want it
> to improve with time*! That implies an acceptance (even a welcoming)
> of breaking changes.

What change in particular?


> 2. Tooling is still insufficient. I use Visual Studio, and while
> VisualD is good, it's not great. Like almost all tooling projects,
> there is only one contributor, and I think this trend presents huge
> friction to adoption. Tooling is always factored outside of the D
> community and their perceived realm of responsibility. I'd like to see
> tooling taken into the core community and issues/bugs treated just as
> seriously as issues in the compiler/language itself.
>
> 3. Debugging is barely ever considered important. I'd love to see a
> concerted focus on making the debug experience excellent. Iain had a
> go at GDB, I understand there is great improvement there. Sadly, we
> recently lost the developer of Mago (a Windows debugger). There's lots
> of work we could do here, and I think it's of gigantic impact.

There are 23 issues tagged with 'symdeb':

https://issues.dlang.org/buglist.cgi?keywords=symdeb&list_id=109316&resolution=---

If there are more untagged ones, please tag them.


> 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years
> later, I still can't pass an rvalue->ref (been discussed endlessly),
> create a ref local, and the separation from the type system makes it a
> nightmare in generic code. This was a nuisance for me on day-1, and
> has been grinding me down endlessly for years. It has now far eclipsed
> my grudges with the GC/RC, or literally anything else about the
> language on account of frequency of occurrence; almost daily.

I have to ask why all your code revolves about this one thing?

> seasoned c++ developer will not migrate to D for many reasons (or he
> already did that, but then he is not c++ developer anymore), and "c++
> interop" is not on the top of the list, not even near the top.

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...

If I had C++ interop _today_ I'd convert some of our unit testing utils for Google Test that we use at work to D. Today.

Atila

On Wednesday, 24 September 2014 at 07:41:48 UTC, ketmar via Digitalmars-d wrote:
> all three of them.

You forget that D is now actively used at Facebook, and better C++ interop would allow them to slowly phase out more and more C++ code. The more Facebook uses D, the more support it will provide. Not to mention the social capital that D would gain from the fact that it's heavily used and supported at Facebook. It's not even really a question of whether C++ support should be worked on or not, in my opinion.

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".

On Wed, 24 Sep 2014 07:59:40 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> You forget that D is now actively used at Facebook
no, i'm not. i just can't see why facebook priorities should be D priorities. facebook needs c++ interop? ok, they can hire alot of programmers to write this. *not* Walter and Andrei. and not dragging that into primary targets for D.

> not even really a question of whether C++ support should be worked on or not, in my opinion.
i'm not against c++ interop, i'm just against making it high-priority task. it's not something that we *must* have, it's just a "good-to-have feature", nothing more.

On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
Digitalmars-d wrote:
> On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> There was a recent video[1] by Jonathan Blow about what he would want in a
>> programming language designed specifically for game development. Go, Rust,
>> and D were mentioned and his reason for not wanting to use D is is that it
>> is "too much like C++" although he does not really go into it much and it
>> was a very small part of the video it still brings up some questions.
>>
>> What I am curious is what are the worst parts of D? What sort of things
>> would be done differently if we could start over or if we were designing a
>> D3? I am not asking to try and bash D but because it is helpful to know
>> what's bad as well as good.
>>
>> I will start off...
>> GC by default is a big sore point that everyone brings up
>> "is" expressions are pretty wonky
>> Libraries could definitely be split up better
>>
>> What do you think are the worst parts of D?
>>
>> [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
>
> Personally, after years of use, my focus on things that really annoy
> me has shifted away from problems with the language, and firmly
> towards basic practicality and productivity concerns.
> I'm for addressing things that bother the hell out of me every single
> day. I should by all reason be more productive in D, but after 6 years
> of experience, I find I definitely remain less productive, thanks
> mostly to tooling and infrastructure.
>
> 1. Constant rejection of improvements because "OMG breaking change!".
> Meanwhile, D has been breaking my code on practically every release
> for years. I don't get this, reject changes that are deliberately
> breaking changes which would make significant improvements, but allow
> breaking changes anyway because they are bug fixes? If the release
> breaks code, then accept that fact and make some real proper breaking
> changes that make D substantially better! It is my opinion that D
> adopters don't adopt D because it's perfect just how it is and they
> don't want it to improve with time, they adopt D *because they want it
> to improve with time*! That implies an acceptance (even a welcoming)
> of breaking changes.
>
> 2. Tooling is still insufficient. I use Visual Studio, and while
> VisualD is good, it's not great. Like almost all tooling projects,
> there is only one contributor, and I think this trend presents huge
> friction to adoption. Tooling is always factored outside of the D
> community and their perceived realm of responsibility. I'd like to see
> tooling taken into the core community and issues/bugs treated just as
> seriously as issues in the compiler/language itself.
>
> 3. Debugging is barely ever considered important. I'd love to see a
> concerted focus on making the debug experience excellent. Iain had a
> go at GDB, I understand there is great improvement there. Sadly, we
> recently lost the developer of Mago (a Windows debugger). There's lots
> of work we could do here, and I think it's of gigantic impact.
>
> 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years
> later, I still can't pass an rvalue->ref (been discussed endlessly),
> create a ref local, and the separation from the type system makes it a
> nightmare in generic code. This was a nuisance for me on day-1, and
> has been grinding me down endlessly for years. It has now far eclipsed
> my grudges with the GC/RC, or literally anything else about the
> language on account of frequency of occurrence; almost daily.


i couldn't agree more. i would like to add, that coming from D1's
clean and nice syntax - D2 becomes a syntactic monster, that is
highly irritating and hard to get used to. its littered with @
like a scripting language. that really sucks!

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.
>
> so-called "enterprise" will not choose D for many reasons, and "c++
> interop" is on the bottom of the list.
>
> seasoned c++ developer will not migrate to D for many reasons (or he
> already did that, but then he is not c++ developer anymore), and "c++
> interop" is not on the top of the list, not even near the top.
>
> all that gory efforts aimed to "c++ interop" will bring three and a
> half more users. there will be NO massive migration due to "better c++
> interop". yet this feature is on the top of the list now. i'm sad.
>
> seems that i (we?) have no choice except to wait until people will get
> enough of c++ games and will became focused on D again. porting and
> merging CDGC is much better target which help people already using D,
> but... but imaginary "future adopters" seems to be the highest
> priority. too bad that they will never arrive.

With the current move of having of more support for native code
as part of the standard toolchains for Java (SubstrateVM,
Sumatra, Valhalla, Panama) and .NET compilers (MDIL, .NET Native,
RyuJIT all using the Visual C++ backend).

The beloved enterprise has lots of reasons to stay with the
current tooling when seeking performance.

--
Paulo

On Wednesday, 24 September 2014 at 06:54:38 UTC, Walter Bright wrote:
> On 9/23/2014 11:20 PM, Jacob Carlborg wrote:
>> On 24/09/14 07:37, Walter Bright wrote:
>>> So help out!
>> You always say we should help out instead of complaining.
>
> That's right. Complaining does nothing.
>
>
>> But where are all the users that want C++ support. Let them implement it instead and lets us focus on
>> actual D users we have now.
>
> I was there at the C++ revolution (and it was a revolution) almost at the beginning. And in fact, a reasonable case could be made that I caused the success of C++ by providing an inexpensive C++ compiler on the most popular (by far) platform at the right moment.
>
> What sold C++ was you could "ease" on into it because it would compile your existing C code.
>
> Later on, other C++ compilers came out. I'd talk to my sales staff at Zortech, asking them how they sold Zortech C++. What was the line that sold the customer. They told me "Zortech C++ is the only C++ compiler that can generate 16 bit Windows code. End of story. Sold!"
>
> I.e. none of the features of ZTC++ mattered, except one killer feature that nobody else had, and that nobody else even had a story for.
>
> Now, consider interfacing with existing C++ code. Which top 10 Tiobe languages can?
>
> C: no
> Java: no
> Objective C: sort of http://philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects
> C++: yes
> C#: no
> Basic: no
> PHP: no
> Python: no
> Javascript: no
> Transact-SQL: no
>
> and:
>
> Go: no
> Rust: no
>
> The ones marked "no" have no plan, no story, no nothing.
>
> This means if we have some level of C++ interop, we have a killer feature. If users have a "must have" C++ library, they can hook up to it. Can they use other languages? Nope. They have to wrap it with a C interface, or give up. Wrapping with a C interface tends to fall apart when any C++ templates are involved.
>
> C++ libraries are currently a language "lock in" to C++. There are no options.
>
> I've often heard from people that they'd like to try D, but it's pointless because they are not going to rewrite their C++ libraries.
>
> Case in point: last fall Adam Wilson started on Aurora, a C++ Cinder clone. I had thought he could simply wrap to the C++ library. No way. It was just unworkable, and Cinder was too big to rewrite. Aurora was abandoned. If we could have interfaced to it, things would have been much different.
>
> This story is not unusual.
>
>
> That said, C++ interop is never going to be easy for users. We're just trying to make it possible for a savvy and determined user. And he'll have to be flexible on both the C++ side and the D side.

C#: half-yes, when on Windows and C++ is exposed via COM or WinRT.

In any case I agree with you.

C++ got successful thanks to your work and other vendors that were bundling it with their C compilers.

If C++ was a separate product that companies had to buy extra on top of their C compilers, it would have failed.

--
Paulo