wallet/docs/duck_typing.md

---
title: Duck Typing
...
Assume naming system based on Zooko’s triangle. At what point should
human readable names with mutable and context dependent meanings be nailed
down as globally unique identifiers?

The most flexible, most convenient, most powerful, most general, and thus
most prone to disaster form of run time typing is duck typing, wherein the
human readable name gets translated on the fly in the run time context,
and the run time context is whatever is on the end users machine. 

The optimal, most powerful, most powerful, most convenient typing that is
safe is duck typing that defaults to *compile time* translation of
human readable type identifiers into globally unique type identifiers,
translating using the environment present on the end user’s machine.

The generality of run time duck typing is dangerous when you expect your
program to run on someone else’s machine.

In fact it is dangerous even on your own machine.  Python executing duck
typed code produces surprising and strange results. C++ refuses to compile it
without endless incomprehensible boilerplate.  Haskel, on the other hand, for
all its faults, just simply does as you thought you were telling it to do.

Python’s duck typing causes endless install grief. Once a complex program
moves away from its home environment, endless install problems arise,
because the objects returned are not exactly the objects expected.
Successive versions of the API return objects that look less and less like
the previous versions.

This, of course, is exactly the problem that COM and its successor NET
quite successfully solved, but the solution relies on compilation. The
compiled code running on a newer API is guaranteed to receive the sort of
objects that the compile time API would have given it or fail cleanly, even
though the api and the compiled code were compiled by different people on
different and dissimilar machines.

Sometimes you want run time typing for flexibility, some times you don’t.

If your program is going to be used in foreign environment, you usually
want types identified by human readable names, which can stand for many
things, translated into types identified into globally unique identifiers
by the translation environment on your machine, the machine on which you
are debugging the code, rather than the end user’s machine. Duck typing is
optimal when developing code that will only run on your own machine in
your own environment.

Source code, therefore, should come with libraries mapping human readable names
to the globally unique type names on which that source code was tested and
depends.

The greatest flexibility is to have choice as to when local names will be
bound to globally unique identifiers, compile time, or run time. To avoid
install hell, should default to compile time, except where run time duck
typing is explicitly invoked..

Forty nine times out of fifty the compiler can type objects better than
you can, and ninety nine times out of a hundred the run time can type
objects better than you can, and with vastly less effort, but it is that
one time out of fifty, and the one time out of a hundred, that bites you.

Haskel has by far the best duck typing system, producing predictable,
expected, and intended results, without rigidity or incomprhensible boiler
plate, unlike C++ metacode.  The programmer expresses his intention in a
programmer intuitive way, and Haskel correctly divines his intent, translates
into rigid compile time types as appropriate to the situation, or produces a
relevant type error.

The C++11 `auto` type and `decltype` are sort of
compile time duck typing, steps in that direction. `Decltype`
is duck typing inside the elaborate C++ straitjacket.  If `auto`
references a `decltype`, that is pretty close to duck
typing.  Real duck typing is doubtless a lot better, but it is
a good step.

However the C++11 `auto` and `decltype` 
require you to explicitly write polymorphism into your code using the
convoluted complex template formalism and inheritance, whereas Python is
casually polymorphic by default – and thus apt to produce wildly unexpected results.

But even when you are not in fact supporting polymorphism, `auto`,
`decltype` and the C\# `var` find the correct types
better than you do, avoiding unintended type conversions, which are a huge
source of C++ bugs.  So it is better to use auto and decltype
wherever possible,whenever you do not want to explicitly force type
conversion, wherever the exact type is not all that important to you.

Sometimes you really do care that this thing is a uint, it has got to be
a uint, we are taking advantage of the fact that it is a uint, and if we
turned it into a ulong or a short, or whatever, then the mechanism would
break.   But usually, particularly with the more complex types,
the precise type is irrelevant noise and a useless distraction.  You
generally want to know what is being done, not how it is being done.
Further, if you explicitly specify how it is being done, you are likely to
get it wrong, resulting in mysterious and disastrous type conversions.