On Tuesday, 22 September 2020 at 10:30:38 UTC, IGotD- wrote:
> Pony is another language that allows objects cross referencing but just like the Microsoft research language they have something called "regions" in which the objects are allowed to cross reference.

Yes, certainly. If an actor is no longer live then all isolated (non-shared memory) objects could be released in one go, like just freeing up the entire pool if that actor did all the local allocations from a single local pool. (I believe Pony to have global garbage collection though.)

So the challenge is coming up with protocols that allow library metaprogramming code to communicate to the static analysis what actually is going on. And some very specific requirements that makes behaviour undefined if the protocols are broken has to be established by the language spec in very clear terms.

I am not sure how this can be done in detail, but it probably is a research topic that is active (or overlap with current PL research). So one probably should aim low, or at least very focused on known issues, like establishing a protocol that allow swift-like reference counting with optimization, or arena-like allocators where you can just dump the entire arena-pool if all objects allocated from that pool have no destructors that have side-effects outside the pool.

Just as an example: a set of graphs where each graph has a separate pool and the compiler can prove that all nodes in a graph is only comping from that graph-local pool. Then destroying that graph should not have to involve destructing nodes in the graph if they don't have side-effects outside the graph.

Coming up with a protocol to give the compiler those facts in the best way is a significant challenge and it should also be possible for the library author to aid the static analysis so that the static analysis become more efficient (keep the search more limited).

Lots of challenges here, and application authors should ideally not have to deal with this in the main "business" logic of the program. Hopefully it can be contained in libraries.

On Tuesday, 22 September 2020 at 10:30:38 UTC, IGotD- wrote:
> On Tuesday, 22 September 2020 at 10:00:46 UTC, Ola Fosheim Grøstad wrote:
>>
>> I believe Microsoft has a research language where ownership is tied to a group of objects.
[...]
> Pony is another language that allows objects cross referencing but just like the Microsoft research language they have something called "regions" in which the objects are allowed to cross reference.


I guess looking at Verona could be useful, they also reference Cyclone, Pony and Rust:

https://github.com/microsoft/verona/blob/master/docs/faq.md

On Monday, 21 September 2020 at 09:29:21 UTC, Tomcruisesmart wrote:
> Hi,
> I'm looking for healthy conversation.
> What are the prominent downsides of the D programming language?

The compiler error messages are sometimes cryptic
The compilers sometimes crash
You spend more time to start using APIs intended for C++
It doesn't compile to machine code as fast as JavaScript

On Monday, 21 September 2020 at 09:29:21 UTC, Tomcruisesmart wrote:
> Hi,
> I'm looking for healthy conversation.
> What are the prominent downsides of the D programming language?

- templates, meaning a lot of code is generated only at compile time, meaning D will never have the IDE support and refactoring support as languages such as Java/C# have. Also bad error messages when things go wrong.

- multiple personality disorder memory management - one day D is a GC language, then it's actually going away from GC towards ref counting, then it's actually towards a borrow checker, hard to keep up and the ecosystem suffers

- many features interact with each other in weird ways. Just look at any recent language improvement DIP, those are always postponed because the code in some obscure scenario breaks

On 9/23/20 9:53 AM, FeepingCreature wrote:

> Is ... is this a bot??

I flagged the post. I unfortunately have to flag yours too, because it included the advertisement link.

-Steve

On Monday, 21 September 2020 at 10:42:55 UTC, Walter Bright wrote:
> On 9/21/2020 2:35 AM, Ruby The Roobster wrote:
>> One downside is that classes can't inherit from multiple classes.
>
> That's a feature, not a downside. I'm not joking.

As you admitted some time earlier, the other mechanisms such as sub-typing, mixin has effectively introduced multiple inheritance into D already.

> Multiple inheritance is a horrible abstraction, all it does is confuse people.

Well, if it's designed or implemented poorly in the language.


https://forum.dlang.org/post/iajvjzaskzwlhcuztiiz@forum.dlang.org

I think this deserved to be more widely known:

The diamond problem is a *solved* problem by Eiffel language, which won the 2006 ACM Software System Award:

https://en.wikipedia.org/wiki/ACM_Software_System_Award

And I showed the concrete example here:

https://forum.dlang.org/thread/obqthozmxwzhvrafothw@forum.dlang.org

On Monday, 28 September 2020 at 18:12:16 UTC, mw wrote:
>  [snip]
>
> Well, if it's designed or implemented poorly in the language.
>
>
> https://forum.dlang.org/post/iajvjzaskzwlhcuztiiz@forum.dlang.org
>
> I think this deserved to be more widely known:
>
> The diamond problem is a *solved* problem by Eiffel language, which won the 2006 ACM Software System Award:
>
> https://en.wikipedia.org/wiki/ACM_Software_System_Award
>
> And I showed the concrete example here:
>
> https://forum.dlang.org/thread/obqthozmxwzhvrafothw@forum.dlang.org

I remember that thread. It was interesting.

On Mon, Sep 28, 2020 at 06:12:16PM +0000, mw via Digitalmars-d wrote:
> On Monday, 21 September 2020 at 10:42:55 UTC, Walter Bright wrote:
> > On 9/21/2020 2:35 AM, Ruby The Roobster wrote:
> > > One downside is that classes can't inherit from multiple classes.
> > 
> > That's a feature, not a downside. I'm not joking.
> 
> As you admitted some time earlier, the other mechanisms such as sub-typing, mixin has effectively introduced multiple inheritance into D already.

Yes, and we're already regretting it.  As it turns out, alias this (one of the ways to do multiple inheritance in D) has quite a few nasty corner cases that cannot be (easily) reconciled, and now we're starting to discourage its use.  How to resolve identifier lookups when there are conflicts, etc..  There's always a way to rationalize your way out of it; but at the end of the day, it leads to confusing, hard-to-remember, arbitrary rules that have counterintuitive corner cases.


> > Multiple inheritance is a horrible abstraction, all it does is confuse people.
> 
> Well, if it's designed or implemented poorly in the language.

If you have a *workable* idea of how to do it *in D*, we'd love to hear it.  I'm not holding my breath, though.

Don't get me wrong; I love alias this and use it a lot myself. But over the years, I'm gradually beginning to see where it leads to problems. It's useful as a quick hack or shunt to bridge two subsystems that are kinda but not quite compatible, or to shoehorn implicit conversions into a user-defined type, but in the long term, it leads to code smells. (Implicit conversions are another of those things that sounds like a good idea, is convenient to use, but in the long term leads to poor maintainability.)


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

On Monday, 28 September 2020 at 18:42:36 UTC, H. S. Teoh wrote:
> On Mon, Sep 28, 2020 at 06:12:16PM +0000, mw via Digitalmars-d wrote:
>> On Monday, 21 September 2020 at 10:42:55 UTC, Walter Bright wrote:
>> > On 9/21/2020 2:35 AM, Ruby The Roobster wrote:
>> > > One downside is that classes can't inherit from multiple classes.
>> > 
>> > That's a feature, not a downside. I'm not joking.
>> 
>> As you admitted some time earlier, the other mechanisms such as sub-typing, mixin has effectively introduced multiple inheritance into D already.
>
> Yes, and we're already regretting it.  As it turns out, alias this (one of the ways to do multiple inheritance in D) has quite a few nasty corner cases that cannot be (easily) reconciled, and now we're starting to discourage its use.  How to resolve identifier lookups when there are conflicts, etc..  There's always a way to rationalize your way out of it; but at the end of the day, it leads to confusing, hard-to-remember, arbitrary rules that have counterintuitive corner cases.

I'd say the main reason we may be "regretting" `alias this` (though I wouldn't go as far as say "regretting") is that it wasn't designed systematically enough (with consideration of it's interaction with other features) and also at time the language was very free floating (some parts of the language were still being changed and tweaked quite often).

I suggest you re-read the old posts from the DIP66 thread. I think principled solutions to quite a few of the issues with multiple alias this were found.

>
>> > Multiple inheritance is a horrible abstraction, all it does is confuse people.
>> 
>> Well, if it's designed or implemented poorly in the language.
>
> If you have a *workable* idea of how to do it *in D*, we'd love to hear it.  I'm not holding my breath, though.
>
> Don't get me wrong; I love alias this and use it a lot myself. But over the years, I'm gradually beginning to see where it leads to problems. It's useful as a quick hack or shunt to bridge two subsystems that are kinda but not quite compatible, or to shoehorn implicit conversions into a user-defined type, but in the long term, it leads to code smells. (Implicit conversions are another of those things that sounds like a good idea, is convenient to use, but in the long term leads to poor maintainability.)
>
>
> T

I don't have experience with multiple inheritance in Eiffel, but it would be shame that in a language with `static if`, `mixin template`s, `static foreach`, etc. we can't figure out a way to make it work.

I think one extravagant, but definetely workable solution would be create a template DSL (ofc it could also be string mixin-based) in D to prototype a multiple
inheritance system (with e.g. the Eiffel features `rename`, `export`, `undefine`, `redefine` / `override`, and `select`). Being just a prototype, it should be acceptable to go with custom functions like `isSubTypeOf`, `asBaseType`, etc., instead of using the built-in language syntax and semantics. (Sort of like https://code.dlang.org/packages/openmethods adds multiple dispatch.)

On Monday, 21 September 2020 at 09:29:21 UTC, Tomcruisesmart wrote:
> Hi,
> I'm looking for healthy conversation.
> What are the prominent downsides of the D programming language?

As a not D experienced developer (I use rdmd, small game projects and I tried to use as REST service instead play/scala or node/javascript)

Not directly related with DLang but with Development tools:

* Intelligence / autocomplete lack: The use of meta-programming makes it very difficult and really represents a barrier for its incorporation in productive mainstream development (it's funny: we have GC, not good for system/video game developers, but then it makes autocomplete impossible, not good for web services mainstream developers ).

* Inspecting vars while debugging: Why it is so difficult to inspect not trivial vars?. I'm using dlangide, simple and very powerful, but it is hell to inspect variables (especially objects): I have to be defining local variables and assigning object properties to them in order to see their values ​​in the debugger.

* The "auto" Swiss knife:  Yes, I know, "auto" is a powerful tool, but DLang libraries tends to force you to use auto because metaprogramming... it is really difficult to a newcomers to understand the Type returned by a template... and templates are everywhere.

i.e.:  If you read about Tasks (https://dlang.org/phobos/std_parallelism.html), for me is not obvious how to define an empty array of tasks.

Imagine I have a "4 in a line" game and I want to evaluate with a thread each column of the game (a minimax algorithm)

> ??? tasks = [];
> for( int ixTask=0; ix<COLUMNS; ixTask++){
>   tasks ~= task!evalColumn(board.clone(), columns[ixTask], maxRecursion - 1);
>   tasks[ixTask].executeInNewThread();
> }
> ...

What do you have to place instead "???"