On 10/9/15 4:47 AM, bitwise wrote:
> On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
>> On 10/8/15 5:59 PM, bitwise wrote:
>>> With DIP74, the ref counting is hard coded into the type itself.
>>
>> I think that should be the case. -- Andrei
>
> Can you comment on the status of the next vision document?

The H1 vision document has had some effectiveness albeit limited. I'll discuss outlook with Walter during our road trip, and plan to update it when we get back. -- Andrei

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote:
> On 10/9/15 4:47 AM, bitwise wrote:
>> On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
>>> On 10/8/15 5:59 PM, bitwise wrote:
>>>> With DIP74, the ref counting is hard coded into the type itself.
>>>
>>> I think that should be the case. -- Andrei
>>
>> Can you comment on the status of the next vision document?
>
> The H1 vision document has had some effectiveness albeit limited. I'll discuss outlook with Walter during our road trip, and plan to update it when we get back. -- Andrei

Awesome, thanks!

    Bit

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote:
> On 10/9/15 4:47 AM, bitwise wrote:
>> On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
>>> On 10/8/15 5:59 PM, bitwise wrote:
>>>> With DIP74, the ref counting is hard coded into the type itself.
>>>
>>> I think that should be the case. -- Andrei
>>
>> Can you comment on the status of the next vision document?
>
> The H1 vision document has had some effectiveness albeit limited. I'll discuss outlook with Walter during our road trip, and plan to update it when we get back. -- Andrei

The vision document mentioned finalizing shared so that it's "done" IIRC. Is there anything still being done about this?

On 10/8/2015 11:56 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 18:19:51 UTC, Jim Hewes wrote:
>
> Yes, there are libraries, but for it to be pleasant I think language
> support is needed. I've linked to this video before, but it is quite
> entertaining if you haven't seen it yet:
>
> https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask
>

Yeah, I watched that after I saw your other post with the link. Thanks. One early question that I have (that someone else also asked in a comment below the video) is about design and the granularity of actors. What sorts of things do you define as an actor? How big does an entity need to be before you should make it an actor?

>
> Carl Hewitt stresses the difference from other concurrency models that
> use non-determinism by pointing out that a key quality with actor based
> systems is indeterminism. (i.e. that things may simply evaporate without
> notice).
>

Another thing I noted was when he said once you get to 1000 cores the programmer knows nothing about the environment. So rather than figure out new ways to manage these things like locks and threads, it makes sense to get to a more abstract level where you don't even deal with it at all anymore.

>
> I don't know much about C++ actor frame works, but if you only want to
> play with actors then you could give pony-lang.org a spin. Not sure if
> they really focus on indeterminism, though.
>

Thanks! I'll give it a look. It's probably good for playing around with to get a feel for it.

On Friday, 9 October 2015 at 20:16:42 UTC, Jim Hewes wrote:
> Yeah, I watched that after I saw your other post with the link. Thanks. One early question that I have (that someone else also asked in a comment below the video) is about design and the granularity of actors. What sorts of things do you define as an actor? How big does an entity need to be before you should make it an actor?

Well, I think Hewitt wants actors to be a foundational concept, but then again this is his baby so he might take it all the way, just to explore the territory? I've browsed his paper on ActorScript, which unfortunately doesn't look like a very user-friendly language IMO, but he apparently thinks that an Actor could cover just a single expression if you want to. I also think he is playing with a different type of logic that covers uncertainty.

https://hal.archives-ouvertes.fr/hal-01147821/document

But... maybe it is more reasonable to use larger units that represent something in the system we try to model? (Connection, Account, and so on?)

> Another thing I noted was when he said once you get to 1000 cores the programmer knows nothing about the environment. So rather than figure out new ways to manage these things like locks and threads, it makes sense to get to a more abstract level where you don't even deal with it at all anymore.

Yes, just have actors and very efficient message passing and remove all notions of cores and threads. I think this is where Pony is heading too.

There was a kind of interesting presentation by Andreas Olofsson from Adapteva on an Erlang conference I saw on youtube where he talks a bit about a 1000 core CPU he is designing (manufacturing is probably a different matter). Each core has 64KiB of local memory, that's what is called a "scratchpad" which replace traditional caching so you can get fast memory closer to the core.

https://www.youtube.com/watch?v=WGXPFPKQC2o

> Thanks! I'll give it a look. It's probably good for playing around with to get a feel for it.

I think the Pony feature set is kind of interesting, they are trying to be innovative. Pony is probably not usable for anything serious at this stage, but they appear to have proved the type system to be sound formally so it is interesting to look at, I think. What they try to do makes sense.

On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote:
> Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types.

If it doesn't make sense for reference types to be value types, then your suggestion to use structs (value types) to implement reference types doesn't make sense either.

On Monday, 12 October 2015 at 07:39:30 UTC, Kagamin wrote:
> On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote:
>> Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types.
>
> If it doesn't make sense for reference types to be value types, then your suggestion to use structs (value types) to implement reference types doesn't make sense either.

My point is that without a level of indirection, polymorphism isn't involved. For polymorphism, you have a pointer or a reference of a base type, and it points/refers to an object of a derived type which then implements some of the functionality differently from the base. If you have a value type, there is no polymorphism, because there is no indirection. You're dealing with the exact type that the variable is. With a value type, all inheritance does is provide a way to reuse code (and not even a very good way to reuse code, since you can only derive from one type at a time). Inheritance's primary benefit is with polymorphism. Given that, it makes a lot of sense to use inheritance with objects on the heap and a lot less sense to use it for objects on the stack.

You can stick value types on the heap and pass around pointers or references to them, but then you're not dealing with polymorphism. You're just providing a way to have multiple pieces of code point operate on the same object, whereas passing it around on the stack means copying it. In some cases, ref would do the job just as well. But I wasn't really trying to say anything about whether value types made sense on the heap or anything like that. My point was entirely about polymorphism not applying to anything without using a pointer or reference.

- Jonathan M Davis

On Monday, 12 October 2015 at 07:39:30 UTC, Kagamin wrote:
> On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote:
>> Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types.
>
> If it doesn't make sense for reference types to be value types, then your suggestion to use structs (value types) to implement reference types doesn't make sense either.

It does make sense. You have the value type that do the reference counting, and a reference type that is reference counted.

That is good separation of concerns.

On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote:
> I've programmed extensively in C++ with smart pointers, and in my experience, circular references are rarely a problem. There are some cases where it's obvious that you have one (e.g. where one object owns another and they need to talk to each other), in which case you either use a normal pointer or a weak reference, depending on which makes more sense. And in the cases that you don't catch, you find them in testing, figure out what should be a weak reference to get rid of the circular dependency, you fix it, and you move on. It really isn't a big deal in general, though I suppose that there could be certain ways of designing programs where it would be more problematic.

That's all understandable. What's not understandable is when one insists that a necessity to figure out ownership for every non-resource object in C++ is superior to D.

On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote:
> On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote:
>> I've programmed extensively in C++ with smart pointers, and in my experience, circular references are rarely a problem. There are some cases where it's obvious that you have one (e.g. where one object owns another and they need to talk to each other), in which case you either use a normal pointer or a weak reference, depending on which makes more sense. And in the cases that you don't catch, you find them in testing, figure out what should be a weak reference to get rid of the circular dependency, you fix it, and you move on. It really isn't a big deal in general, though I suppose that there could be certain ways of designing programs where it would be more problematic.
>
> That's all understandable. What's not understandable is when one insists that a necessity to figure out ownership for every non-resource object in C++ is superior to D.

If you don't want to care about ownership, then use a GC. The only other memory management model that I can think of where you don't have to care about ownership is when everything is a value type on the stack, so there's nothing to own.

There are pros and cons to using a GC, and there are pros and cons to use reference counting everything on the heap. I don't think that either is objectively superior. It all depends on what you're trying to do and what your requirements are.

- Jonathan M Davis