On 08/18/2010 11:59 AM, bearophile wrote:
> Andrei Alexandrescu:
>> http://www.reddit.com/r/programming/comments/d2j8n/d_programming_language_interview_with_andrei/
>
>>
> I will need time to digest this interesting second part of your
> interview, you say many complex things.
>
> In the meantime that Reddit thread is one of the worst I've seen on
> that usually interesting site. Some C++ programmers seem to hate D a
> lot. Each new programming language is built on different values.
> Maybe D2 is not targeted to most of the experienced C++ programmers.
> Maybe D2 is more fit for other kinds of programmers, after all. I
> don't know.

I'm not seeing much hatred in that thread, and in fact overall the reception of D on reddit has improved enormously since e.g. six months ago.

There are of course those exhausting bullet points, which look like reverse engineering of an argument starting from conclusion. That's fine, and it seems like not many fell for it.


Andrei

Andrei Alexandrescu Wrote:

> http://www.informit.com/articles/article.aspx?p=1622265
> 
> Andrei

I see you've mentioned the library function move() in the interview. I might have found an issue with move(), unless I missunderstood how it works. See my post here:

http://news.gmane.org/gmane.comp.lang.d.general/cutoff=35852

Can't wait for part 3! :)

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:i4h3hf$31eh$1@digitalmars.com...
>
> In the meantime that Reddit thread is one of the worst I've seen on that usually interesting site.

That seemed to mainly just be that one guy (the one that kept making a bunch of absurd and self-contradictory statements).

Walter Bright:

> There is no need for a pin attribute, the gc can determine if a class needs pinning or not.

The same is probably true for pure functions too, the compiler can determine what functions are pure and what are not pure.

But the purpose of a @pinned is that:
1) The default becomes unpinned. This is good for the GC, because moving memory around is good to compact the heap, etc.
2) The programmer states hir/her/his purpose, this is documentation, but it's an alive documentation because as with pure the compiler is able to determine if the attribute is used wrongly, and give a compile time error in such case.

Bye,
bearophile

bearophile wrote:
> Walter Bright:
> 
>> There is no need for a pin attribute, the gc can determine if a class needs
>>  pinning or not.
> 
> The same is probably true for pure functions too, the compiler can determine
> what functions are pure and what are not pure.
> 
> But the purpose of a @pinned is that: 1) The default becomes unpinned. This
> is good for the GC, because moving memory around is good to compact the heap,
> etc. 2) The programmer states hir/her/his purpose, this is documentation, but
> it's an alive documentation because as with pure the compiler is able to
> determine if the attribute is used wrongly, and give a compile time error in
> such case.

The other problem with a pinned/notpinned object is the object itself cannot control who or how someone is pointing to it.

> In the meantime that Reddit thread is one of the worst I've seen on that usually interesting site. Some C++ programmers seem to hate D a lot.

In my experience, convincing someone who have personally  invested a lot in C++ is _hard_. People who care about big teams are not convinced at all by language features, and need to be told more about the safety concerns, gettting less bugs, improved productivity.

Walter Bright, el 18 de agosto a las 12:25 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 18 de agosto a las 10:08 me escribiste:
> >>bearophile wrote:
> >>>Currently in the D2 GC there is no notion of pinned/unpinned class instances, but eventually an attribute as @pinned may be added to D3, plus its related semantics. It adds complexity to the language and it needs to interact with the GC, so it will get useful as the D GC becomes more modern (with different zones for newly allocated objects, etc).
> >>There is no need for a pin attribute, the gc can determine if a class needs pinning or not.
> >
> >As long as the precise heap scanning patch is applied (and much better
> >if we can manage to scan the static data precisely too). Otherwise you
> >simply just can't move stuff around because you don't know what is
> >a pointer and what is not (thus you can't update pointer that point to
> >moved stuff).
> 
> Hence the objects with ambiguous references to them get automatically pinned by the gc. I've implemented such a gc before, it works fine. It's called a "mostly copying collector".

Even when you say is true, the GC can automatically determine if something should be pinned when *EVERYTHING* is pinned, it's not very useful :)

> Besides, any scheme where you have to manually mark pinnable objects is doomed to have disastrously subtle and hard-to-find bugs.

I'm not arguing in favor of manual pinning, I completely agree is a bad
idea. I'm just saying that, as things are, in D you can't implement
a moving collector, because *ALL* the memory is pinned because if fully
conservative.

With the precise heap scanning patch for DMD the GC can automatically pin memory, because it has enough information to differentiate between real pointers and words which types are not really known, so a block can be moved *only* if is only pointed to by real pointers, otherwise is pinned because we can't update the words with unknown type if we moved that block.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, out there in the cold
Getting lonely, getting old
Can you feel me?

Walter Bright, el 18 de agosto a las 15:31 me escribiste:
> bearophile wrote:
> >Walter Bright:
> >
> >>There is no need for a pin attribute, the gc can determine if a class needs
> >> pinning or not.
> >
> >The same is probably true for pure functions too, the compiler can determine what functions are pure and what are not pure.
> >
> >But the purpose of a @pinned is that: 1) The default becomes unpinned. This is good for the GC, because moving memory around is good to compact the heap, etc. 2) The programmer states hir/her/his purpose, this is documentation, but it's an alive documentation because as with pure the compiler is able to determine if the attribute is used wrongly, and give a compile time error in such case.
> 
> The other problem with a pinned/notpinned object is the object itself cannot control who or how someone is pointing to it.

Exactly, manually pinning is really completely unpractical, the analogy between pure and pinned makes very little sense.

I can see some very very weird use case where you want to arbitrarily mark some block pinned, but I think manual unpinning is just to dangerous to be useful. And for the former, you can easily force pinning by having a pointer to it in a portion of memory that is scanned conservatively.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y2K
<Aztech_> hmm, nothing major has happend, what an anticlimax
<CaPS> yeah
<CaPS> really sucks
<CaPS> I expected for Australia to sink into the sea or something
<CaPS> but nnoooooooo

Leandro Lucarella wrote:
> With the precise heap scanning patch for DMD the GC can automatically
> pin memory, because it has enough information to differentiate between
> real pointers and words which types are not really known, so a block can
> be moved *only* if is only pointed to by real pointers, otherwise is
> pinned because we can't update the words with unknown type if we moved
> that block.


I know. That's how a mostly copying collector works.

Walter Bright, el 19 de agosto a las 13:08 me escribiste:
> Leandro Lucarella wrote:
> >With the precise heap scanning patch for DMD the GC can automatically pin memory, because it has enough information to differentiate between real pointers and words which types are not really known, so a block can be moved *only* if is only pointed to by real pointers, otherwise is pinned because we can't update the words with unknown type if we moved that block.
> 
> I know. That's how a mostly copying collector works.

If you know, I guess you agree on the utility of the patch and the impossibility of implementing a mostly moving collector in D, so I hope you apply the patch eventually =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, standing in the road
always doing what you're told,
Can you help me?