www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Interview with InformIT part 2/3

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.informit.com/articles/article.aspx?p=1622265

Andrei
Aug 18 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/18/2010 05:13 AM, Andrei Alexandrescu wrote:

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

 Andrei


Now on reddit:

http://www.reddit.com/r/programming/comments/d2j8n/d_programming_language_interview_with_andrei/

Thanks davebrk!


Andrei
Aug 18 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
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.

Among all the comments written by axilmar, I agree that D tuples are not in
good shape at all. There are two of them, one is limited (no way to return
them) and auto-flattening, the other has no compiler support despite some
syntax sugar helps a lot here.

Regarding this you have written in Reddit:

Even moving classes should be fine with precautions, as moving garbage
collectors have shown.<


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

Bye,
bearophile
Aug 18 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 18 2010
next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
	-- Carla Lucarella (10/2008 contando de su viaje a México)
Aug 18 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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".

Besides, any scheme where you have to manually mark pinnable objects is doomed 
to have disastrously subtle and hard-to-find bugs.
Aug 18 2010
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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?
Aug 19 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 19 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
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?
Aug 19 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Aug 18 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 18 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
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
Aug 19 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, August 18, 2010 09:59:27 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.


Every language has those who like it and those who don't. And everyone who uses 
a language has their own reasons for liking it or disliking. In many ways, D is 


attract 
people from both camps, but there are going to be people from both camps who 
aren't going to like it, if nothing else because it goes too far towards the 
other end of the spectrum for them. And when you like one language and are well 
aware of its pros and cons and then go and look at another language, it's very 
easy to see things that don't match what you like about the language that you 
know, and without really working with it, you're not really going to be well 
enough of all of its pros and cons to really decide whether those differences
are 
worth it. I'm both a C++ and Java programmer, and I love D. In many ways, it's 
exactly what I'm looking for in a language, which is why I'm so excited about 
it, but there are plenty of things in D which can be very annoying - like the 
lack of struct default constructors (or as you mentioned, the state of tuples).

Ultimately, the folks who are most likely to be interested in D are those who 
aren't entirely happy with the language that they're using and find D's feature 
set to be an attractive alternative - that and the folks who are forced to use 
it because that's what's being used on the project that they're working on, but 
that's likely fairly rare at this point.

In any case, I'm certain that there are a lot of C++ programmers who will love
D 
and a lot who will hate it.

- Jonathan M Davis
Aug 18 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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



 Aug 18 2010



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


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



 Aug 18 2010



prev sibling  parent  ponce <contact g1a2m3es4f5r6om7m8ars.fr>  writes:


 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.



 Aug 19 2010



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Wed, 18 Aug 2010 13:13:25 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


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


Thanks, that was an interesting read.

It's possible that I'm missing something, but I think that C++'s default  
constructors + reference-type structs/classes allow a pattern which isn't  
easily translatable to D. For example, in C++...

class A { /* a class with a default constructor */ };

struct B { A a; /* ... */ };

struct C { B b; /* ... */ };

Now, instantiating C will invoke A's constructors. In order for this to  
work, the compiler automatically generates hidden constructors for B and  
C. However, D doesn't have default constructors for structs (and,  
according to TDPL, never will)? D does seem to generate hidden postblit  
constructors and destructors, though.

If I had to port a C++ project to D which made heavy use of this pattern,  
what would be the best way to do it? The only ways I see is either  
rewriting the code to use classes (which means writing constructors with  
explicit instantiation, more dereferences and heap usage leading to worse  
performance...), or implementing and calling pseudo-constructors in both B  
and C, and (most importantly) all places which "instantiate" C. Did I miss  
anything?

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net



 Aug 18 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 08/18/2010 06:46 AM, Vladimir Panteleev wrote:

 On Wed, 18 Aug 2010 13:13:25 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


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


 Thanks, that was an interesting read.

 It's possible that I'm missing something, but I think that C++'s default
 constructors + reference-type structs/classes allow a pattern which
 isn't easily translatable to D. For example, in C++...

 class A { /* a class with a default constructor */ };

 struct B { A a; /* ... */ };

 struct C { B b; /* ... */ };

 Now, instantiating C will invoke A's constructors. In order for this to
 work, the compiler automatically generates hidden constructors for B and
 C. However, D doesn't have default constructors for structs (and,
 according to TDPL, never will)? D does seem to generate hidden postblit
 constructors and destructors, though.


Don't forget that non-default constructors are fair game though. I agree 
that for this idiom it would be nice to have the default constructor 
guarantee execution of certain initializations.


 If I had to port a C++ project to D which made heavy use of this
 pattern, what would be the best way to do it? The only ways I see is
 either rewriting the code to use classes (which means writing
 constructors with explicit instantiation, more dereferences and heap
 usage leading to worse performance...), or implementing and calling
 pseudo-constructors in both B and C, and (most importantly) all places
 which "instantiate" C. Did I miss anything?


One simple technique I use is to write and use factory functions. They 
are particularly handy when C is also a template struct.


Andrei



 Aug 18 2010



prev sibling next sibling parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-08-18 06:13:25 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


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


Quoting:
"""
The most difficult scenario here is a class that has a struct as a 
member. If the struct has a destructor, it will be run 
non-deterministically—or possibly not at all.
"""

Or cause a race condition:
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Aug 18 2010



prev sibling next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


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! :)



 Aug 18 2010



prev sibling  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Walter Bright:

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


The type system may tell apart three kinds of pointers/references:
1) hand-managed pointers, to GC memory or C heap memory;
2) GC-managed pointers to pinned memory;
3) GC-managed pointers to unpinned memory.

But this is a long story, I have already discussed this topic a bit, there are
problems with pointers on the stack:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=108544

I am not yet able to design a thing so complex alone, so sorry for the noise
:-) I need to learn more and improve, first.

Bye,
bearophile



 Aug 18 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


bearophile wrote:

 Walter Bright:

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


 
 The type system may tell apart three kinds of pointers/references: 1)
 hand-managed pointers, to GC memory or C heap memory; 2) GC-managed pointers
 to pinned memory; 3) GC-managed pointers to unpinned memory.
 
 But this is a long story, I have already discussed this topic a bit, there
 are problems with pointers on the stack: 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=108544
 
 
 I am not yet able to design a thing so complex alone, so sorry for the noise
 :-) I need to learn more and improve, first.


Microsoft's managed C++ on .net comes with multiple pointer types - managed and 
unmanaged pointers - as far as I know, this was a technical success yet a 
massive failure with users.

I have plenty of experience with multiple pointer types coming from my 16 bit 
compiler work. I prefer to run screaming from that path.



 Aug 18 2010



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Walter Bright:

 Microsoft's managed C++ on .net comes with multiple pointer types - managed
and 
 unmanaged pointers - as far as I know, this was a technical success yet a 
 massive failure with users.


How do you define failure? Maybe for D2 multiple pointer types are a failure as
you say, but in my opinion "managed C++" is not a language, it's not designed

and C++ (and C, etc). I know people that use managed C++ professionally, no one
of them likes to use it, but it seems they will keep using it. So I don't think
managed C++ is a failure.

Bye,
bearophile



 Aug 18 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


bearophile wrote:

 Walter Bright:

 Microsoft's managed C++ on .net comes with multiple pointer types - managed
 and unmanaged pointers - as far as I know, this was a technical success yet
 a massive failure with users.


 
 How do you define failure?


Nobody wanted to use it.



 Maybe for D2 multiple pointer types are a failure
 as you say, but in my opinion "managed C++" is not a language,


It meets every definition of one.



 it's not designed to write complete programs,


Yes, it is. It was intended to be a big deal. It fell way short of that with
users.



 it's designed to build bridges between

 professionally, no one of them likes to use it, but it seems they will keep
 using it. So I don't think managed C++ is a failure.


Please revisit the "no one of them likes to use it".

Being forced to use something doesn't make that thing a success.



 Aug 18 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i4hvjh$91i$1 digitalmars.com...

 Being forced to use something doesn't make that thing a success.


Unfortunately, I can think of a lot of counterexamples (any monopoly or 
oligopoly, for instance). But I agree in spirit :)



 Aug 18 2010