Go Programming talk [OT]

[Andrei Alexandrescu]

On 06/07/2010 06:36 AM, Kagamin wrote:
> Andrei Alexandrescu Wrote:
>
>> I think an honest discussion - as I hope is the tone in TDPL -
>> serves the language and its users better than giving half of the
>> story.
>>
> An honest advertisement is an unusual thing. I saw none. You think,
> TDPL is the first one. There're many features in other languages no
> speak of costs, and every forgotten cost is a lie.

Agreed. Well, we'll see. I try to discuss costs, tradeoffs, and 
alternative approaches that were considered and rejected (and why) for 
all major features of D.

For example, few books give a balanced view of dynamic polymorphism; in 
some you'll find the nice parts, in others you'll find the not-so-nice 
parts. I tried to discuss both in TDPL:

====================
\dee's  reference  semantics approach  to  handling  class objects  is
similar  to  that  found  in many  object-oriented  languages.   Using
reference semantics and \idx{garbage collection} for class objects has
both positive and negative consequences, among which the following:

\begin{itemize*}
\item[+]\index{polymorphism}\emph{\textbf{Polymorphism.}}   The  level
   of indirection  brought by the consistent use  of references enables
   support for \idx{polymorphism}.  All  references have the same size,
   but related objects  can have different sizes even  though they have
   ostensibly  the same  type (through  the use  of  inheritance, which
   we'll  discuss  shortly).  Because  references  have  the same  size
   regardless of the  size of the object they refer  to, you can always
   substitute  references to  derived  objects for  references to  base
   objects.  Also, arrays of objects work properly even when the actual
   objects in the array have  different sizes.  If you've used C++, you
   sure   know   about   the   necessity   of   using   pointers   with
   \idx{polymorphism},  and  about  the  various  lethal  problems  you
   encounter when you forget to.
\item[+]\emph{\textbf{Safety.}}    Many   of   us   see   \idx{garbage
      collection}  as  just a  convenience  that  simplifies coding  by
   relieving the programmer  of managing memory.  Perhaps surprisingly,
   however,  there is  a very  strong connection  between  the infinite
   lifetime model (which  \idx{garbage collection} makes practical) and
   memory  safety.   Where  there's  infinite lifetime,  there  are  no
   dangling  references, that is,  references to  some object  that has
   gone out of existence and has had its memory reused for an unrelated
   object.  Note that  it would be just as safe  to use value semantics
   throughout (have  \cc{auto a2 =  a1;} duplicate the @A@  object that
   @a1@  refers to  and  have @a2@  refer  to the  copy).  That  setup,
   however, is hardly interesting  because it disallows creation of any
   referential  structure  (such  as  lists, trees,  graphs,  and  more
   generally shared resources).
\item[--]\emph{\textbf{Allocation  cost.}}   Generally, class  objects
   must reside in the \index{garbage collection}garbage-collected heap,
   which generally  is slower and eats  more memory than  memory on the
   stack.  The  margin has diminished quite  a bit lately  but is still
   nonzero.
\item[--]\emph{\textbf{Long-range  coupling.}}   The  main  risk  with
   using  references  is  undue  aliasing.  Using  reference  semantics
   throughout makes  it all too easy  to end up with  references to the
   same   object  residing   in   different---and  unexpected---places.
   In~Figure~\vref{fig:aliasing}, @a1@ and  @a2@ may be arbitrarily far
   from each  other as far as  the application logic  is concerned, and
   additionally there may be many other references hanging off the same
   object.   Interestingly, if  the referred  object is  immutable, the
   problem vanishes---as  long as nobody modifies the  object, there is
   no  coupling.  Difficulties  arise  when one  change  effected in  a
   certain context  affects surprisingly and dramatically  the state as
   seen  in  a different  part  of  the  application.  Another  way  to
   alleviate this  problem is explicit duplication, often  by calling a
   special  method  @clone@,  whenever  passing  objects  around.   The
   downside of  that technique  is that it  is based on  discipline and
   that  it  could  lead  to   inefficiency  if  several  parts  of  an
   application  decide to  conservatively  clone objects  ``just to  be
   sure.''
\end{itemize*}

Contrast reference semantics with  value semantics \`a~la @int at . Value
semantics has advantages, notably equational reasoning: you can always
substitute  equals  for equals  in  expressions  without altering  the
result.   (In contrast,  references that  use method  calls  to modify
underlying objects  do not  allow such reasoning.)   Speed is  also an
important advantage  of value semantics,  but if you want  the dynamic
generosity of \idx{polymorphism}, reference semantics is a must.  Some
languages tried to accommodate both,  which earned them the moniker of
``impure,'' in contrast to  pure object-oriented languages that foster
reference semantics  uniformly across all  types.  \dee is  impure and
up-front  about it.   You get  to choose  at design  time  whether you
use~OOP for  a particular  type, in which  case you  use \kidx{class};
otherwise, you go with @struct@ and forgo the particular~OOP amenities
that go hand in hand with reference semantics.
====================


Andrei