On Thursday, 17 October 2019 at 20:51:35 UTC, welkam wrote:
> That message you linked reads like it was written by me.

You both assume too much then...

Ad hominem, slander and hostility does not build good communities.  You get what you seed.  That's the source of the negativity you complained about. Right there... Right here.

On Thursday, 17 October 2019 at 21:24:27 UTC, bachmeier wrote:
> You can debate about Perl and Php's support, but they were uniquely-positioned languages as the WWW took off. That was kind of a big deal.

Perl was actually big before WWW.
Used for scripting purposes by sys admins.
Lisp was big before WWW.
And more...

But you also had commercial languages by small developers before Open Source became the norm, which also are examples of "no corporate" languages. Although proprietary. That is difficult today, though.


> These days it's hard to give someone a compelling reason to adopt any particular language. There are so many good alternatives no matter what you want to do.

That is true.  But my point is that people do not necessarily adopt languages, they adopt frameworks for some specific task which imply a language (so an indirection).

On Thursday, 17 October 2019 at 21:24:27 UTC, bachmeier wrote:
> On Thursday, 17 October 2019 at 20:01:37 UTC, Ola Fosheim Grøstad wrote:
>
>> Perl, Python, Php, and many smaller languages have built a strong following without corporate backing so, no.
>
> If you exclude a small company named Google, the part about Python is kind of correct.
And CERN

On Thursday, 17 October 2019 at 21:25:04 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 17 October 2019 at 20:51:35 UTC, welkam wrote:
>> That message you linked reads like it was written by me.
>
> You both assume too much then...
>
> Ad hominem, slander and hostility does not build good communities.  You get what you seed.  That's the source of the negativity you complained about. Right there... Right here.

From: https://scottbarrykaufman.com/wp-content/uploads/2014/02/trolls-just-want-to-have-fun.pdf

Let me quote the conclusions:
  "it might be said that online trolls are prototypical everyday sadist"

And there is a non-zero amount of sadists (probably ill-defined but research shown it's a psychological trait). Some of them will engage in trolling behaviour.

I hope the reader now see it's hopeless to have no moderation and hope for the best, since goodwill alone doesn't prevent some people from enjoying distress in others.

Good communities are built on the Internet with exclusion (moderation, internet point, banning, etc...)

As evidenced by Reddit, HN, StackOverflow, lobste.rs having all of that and maintaining a good level of civility. Not banning people is the surest way to have an unwelcoming community.

On Thu, Oct 17, 2019 at 09:58:14PM +0000, Guillaume Piolat via Digitalmars-d wrote: [...]
> From: https://scottbarrykaufman.com/wp-content/uploads/2014/02/trolls-just-want-to-have-fun.pdf
[...]
> I hope the reader now see it's hopeless to have no moderation and hope for the best, since goodwill alone doesn't prevent some people from enjoying distress in others.
[...]

Wow, it took >15 years for "official" research to recognize this fact?

Since around Y2K I've recognized the futility of engaging in online debates, especially with certain personalities that exhibit certain traits. They have be variously described as trolls, sadists, -- I call them griefers.  Basically, their whole goal is to cause grief for the sake of causing grief: they actually have no personal investment in whatever topics they engage in heated debates about; their only goal is to keep bringing up controversial issues to provoke other participants' reactions and derail or distract from any productive discussions that might be taking place. They will often latch on to what, on the surface, appears to be very valid and legitimate issues, and use that to rouse the rabble.  Some of them are very good at it, and it's not so easy to tell their real motives at first. But eventually, their real motives will become clear.

Once that happens, the only winning move is to not play, because the more you engage them, the more they're emboldened to keep doing what they're doing, to the detriment of everyone and everything else.

Most communities will have at least 1 person that continually falls for their devices (cf: https://xkcd.com/386/), thus perpetuating their goals. But you know what's funny?  On the (very) rare occasions that all participants are able to refrain from engaging with them, these sociopathic types will pack up and leave, instantly "forgetting" overnight the oh-so-important issues that they were apparently oh-so-very-passionate about, thereby revealing that in reality, said issues were nothing more than convenient bait with which to arm their hooks.

After encountering more than a few of these personalities, the truth will gradually dawn on you of that great old adage: "don't feed the trolls". The more you play this game, the more you will lose.


> Good communities are built on the Internet with exclusion (moderation, internet point, banning, etc...)
> 
> As evidenced by Reddit, HN, StackOverflow, lobste.rs having all of that and maintaining a good level of civility. Not banning people is the surest way to have an unwelcoming community.

Ah, I must be old and jaded then. I have much less confidence in banning and moderation that you apparently have. The problem with moderation is that the griefers will adapt and find ever new ways of being compliant to the letter but violating the spirit, gaming the system to their own ends. Consequently, the finger on the trigger will inevitably become heavier and heavier, and ultimately it will result in a sterile (and puerile) community that can no longer generate fresh new ideas, because anything that goes against the accepted norm will be knee-jerk rejected as "trollish".

You can't win on the internet. Either you have an open community, where griefer types will inevitably show up, or you have a closed community that grows stale and old (and practically dead as far as innovation is concerned). There is no third choice.


T

-- 
Дерево держится корнями, а человек - друзьями.

On Thursday, 17 October 2019 at 13:16:07 UTC, Petar Kirov [ZombineDev] wrote:
> The last line of work appears to be in the clang-9 branch: https://github.com/Syniurge/Calypso/commits/clang-9
>
> W.r.t to C++ interop there are 5 areas of development:
> 1. During the past 3 years there have been a ton of fixes to extern (C++) (and to a lesser extent extern (C), which was already close to rock-solid) and nowadays it should be pretty usable (namespaces, classes and templates work in many cases). You can directly call much of D from C++ and vice versa. Obviously there are many D and C++ specific language features that are not yet/can't be supported, but we're pretty further along than what we had a couple of years ago. Having all 3 major compilers (first DMD, then LDC and now GDC) be written half in D and half in C++ is a testament to that. (Actually now DMD is D-only now, but it was in C++ + D mode for enough time to force many of the developers at the time to at least make the subset of extern (C++) that it used fully working.)
>
> 2. During the past year some parts of STL had bindings written to them and tested for Linux, Mac and Windows (which is surprisingly difficult, due to difference in C++ compilers and STL implementations): https://github.com/dlang/druntime/tree/master/src/core/stdcpp
>
> 3. Having tools like dstep and dpp support C++. As far as I know both tools support only C header files, but at least for dpp, Atila has listed C++ as a major planned feature. Work in area 1. makes 3. now possible. The work of one of GSOC students made a huge impact for dstep, so it's likely that a similar tactic for dpp would also help.
>
> 4. Automatic C/C++ header generation for D code. There has been solid progress, but we're probably a couple of months before having the work finally merged upstream.
>
> 5. Making import C++ automagically work has been the holy grail for many. The author of Calypso has had the unfortunate task of having to single-handedly work on not only implementation, but also solving many language-level challenges like template instantiation, overloading and many more. Adding insult to injury, the most efficient way to interface with libClang is with C++ and for they don't guarantee a stable API, and even break it very often, and D's frontend is likely worse then that (at minimum it switched from being C++ only, to D only during the time Calypso was developed.).
> I think the best way forward is to get it merged in LDC as soon as possible - that way at least the burden of supporting new D frontend and LLVM/clang backend versions could be shared by other contributors.

Thank you for the detailed progress report. However, I'm afraid that this doesn't answer the one central question that a potential user would have: which version do I use and where/how do I get it?

Calypso has been mentioned as a possible path to get easy C++ interop here several times. But the current appearance of the github project does not instill any confidence in people who don't feel especially adventurous.

I'm amazed at the determination that it takes to create something as complex as Calypso. I'd very much like it to succeed.

Semi-OT, I would also like to see the automatic C++ header generation integrated into DMD/LDC/GDC. This would complement C++-to-D interop nicely. There's a pull request for this feature on github that is slowly getting stale. I don't know if it's merely being ignored or whether there are remaining issues with it.

On Thursday, 17 October 2019 at 21:58:14 UTC, Guillaume Piolat wrote:
>
> I hope the reader now see it's hopeless to have no moderation and hope for the best, since goodwill alone doesn't prevent some people from enjoying distress in others.
>
> Good communities are built on the Internet with exclusion (moderation, internet point, banning, etc...)
>

This forum (which is technically not forum, more a mailing list) have quite little problems with trolls. Few people even find this place.

The problem this forum is that the discussion often derails into off topic (which even this post is). Many threads seems to derail into some kind of despair and whining over the state of D. This is of course not very productive and might be a reason that D development is going slowly. People who are doing are not trolls but perhaps more dejected people. You are allowed to be dissatisfied and dejected but threads must stay on topic.

BTW I would be happy if you would upgrade the D forum to something more modern. With a modern forum you will also get better functionality for moderating the forum.

On 10/17/19 11:48 PM, aliak wrote:
> On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:
>> On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:
>>
>>>>
>>>> Also by design, unless you want something like Rust's traits or Haskell's typeclasses. But none of this is OOP.
>>>
>>> Being by design, doesn't mean it's correct.
>>>
>>> I'm starting to understand Chris.
>>
>> Private to the module *is* correct in D.
>>
>> http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
> 
> That's debatable: https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md

You complain that `doAmazingStuff` can access private members of class A if this function and this class are placed together in one module and continue complain that if you put that class in its own module then `doAmazingStuff` now cannot access private members of A and isn't a "first class" citizen of class A. Could you explain you position clearly?

On Thursday, 17 October 2019 at 23:56:20 UTC, Gregor Mückl wrote:
> On Thursday, 17 October 2019 at 13:16:07 UTC, Petar Kirov [ZombineDev] wrote:
>> The last line of work appears to be in the clang-9 branch: https://github.com/Syniurge/Calypso/commits/clang-9
>>
>> W.r.t to C++ interop there are 5 areas of development:
>> 1. During the past 3 years there have been a ton of fixes to extern (C++) (and to a lesser extent extern (C), which was already close to rock-solid) and nowadays it should be pretty usable (namespaces, classes and templates work in many cases). You can directly call much of D from C++ and vice versa. Obviously there are many D and C++ specific language features that are not yet/can't be supported, but we're pretty further along than what we had a couple of years ago. Having all 3 major compilers (first DMD, then LDC and now GDC) be written half in D and half in C++ is a testament to that. (Actually now DMD is D-only now, but it was in C++ + D mode for enough time to force many of the developers at the time to at least make the subset of extern (C++) that it used fully working.)
>>
>> 2. During the past year some parts of STL had bindings written to them and tested for Linux, Mac and Windows (which is surprisingly difficult, due to difference in C++ compilers and STL implementations): https://github.com/dlang/druntime/tree/master/src/core/stdcpp
>>
>> 3. Having tools like dstep and dpp support C++. As far as I know both tools support only C header files, but at least for dpp, Atila has listed C++ as a major planned feature. Work in area 1. makes 3. now possible. The work of one of GSOC students made a huge impact for dstep, so it's likely that a similar tactic for dpp would also help.
>>
>> 4. Automatic C/C++ header generation for D code. There has been solid progress, but we're probably a couple of months before having the work finally merged upstream.
>>
>> 5. Making import C++ automagically work has been the holy grail for many. The author of Calypso has had the unfortunate task of having to single-handedly work on not only implementation, but also solving many language-level challenges like template instantiation, overloading and many more. Adding insult to injury, the most efficient way to interface with libClang is with C++ and for they don't guarantee a stable API, and even break it very often, and D's frontend is likely worse then that (at minimum it switched from being C++ only, to D only during the time Calypso was developed.).
>> I think the best way forward is to get it merged in LDC as soon as possible - that way at least the burden of supporting new D frontend and LLVM/clang backend versions could be shared by other contributors.
>
> Thank you for the detailed progress report. However, I'm afraid that this doesn't answer the one central question that a potential user would have: which version do I use and where/how do I get it?
>
> Calypso has been mentioned as a possible path to get easy C++ interop here several times. But the current appearance of the github project does not instill any confidence in people who don't feel especially adventurous.

I don't think that anybody has ever advertised Calypso as anything remotely production ready. Like any proof-concept/alpha software, it should be used only by people coming the mindset that they *will* hit many bugs and they're here to test the project, report the bugs and help its development. If you're not one of those people you should either wait for the project to become ready, or if it's important enough for you to help in some other way.

>
> I'm amazed at the determination that it takes to create something as complex as Calypso. I'd very much like it to succeed.

Yes, I am also extremely impressed by the skills and determination of the author, and I think that his approach is the only that can offer the best user experience, but I think it would be more healthy if people don't come with wrong expectations.

> Semi-OT, I would also like to see the automatic C++ header generation integrated into DMD/LDC/GDC. This would complement C++-to-D interop nicely. There's a pull request for this feature on github that is slowly getting stale. I don't know if it's merely being ignored or whether there are remaining issues with it.

That's point 4. on my list. When it will be ready it would be part of all 3 compilers. As far as I know there's more work to be done and when the author has free time he will need to push forward before we can have his PR merged.

On Thu, 2019-10-17 at 20:23 +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2019-10-17 18:46, Russel Winder wrote:
> 
> >  From what I can see both Cargo and Dub fail on updating generated source
> > files. An example: I generate a D module for Fontconfig library using
> > DStep,
> > but it seems SCons is the only tool of Dub, Cargo, Meson, etc. that easily
> > copes with this build precursor. But I may be missing something.
> Perhaps the `extraDependencyFiles` [1] field can help?
> 
> [1] https://dlang.org/changelog/2.085.0.html#extraDependencyFiles-attribute-added

Jacob,

Thanks I'll take a look at that.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk