The idea of writing a program without explicit type information is certainly not new. In fact, it predates object-oriented programming and the notion of objects by a long time. Consider this C program (no C++ here) as an example:

int less(const void* a, const int* b) {
    return *(const int*)a - *(const int*)b;
}
int main() {
    int a[10] = { 1, 10, 2, 9, 3, 8, 4, 7, 5, 0 };
    qsort(a, sizeof(int), 10, less);
}

Now remember the function declaration for qsort from the standard C library:

void qsort(void *base, size_t nmemb, size_t size,
    int (*compar)(const void *, const void *));

Note that, while we are using it to sort an array of integers, the qsort function itself does not have any explicit types—it uses void* to pass in the array to be sorted. Similarly, the comparison function takes two void* pointers and has no explicit type information in its declaration. Of course, at some point, we need to know how to compare the real types. In our C program, the pointers that could, in theory, point to anything, are reinterpreted as pointers to integers. This action, which reverses the abstraction, is known as reification.

In C, restoring concrete types is entirely the responsibility of the programmer—our less() comparison function does, in fact, only compare integers, but it is impossible to deduce so from the interface. Neither it is possible to validate, at runtime, that the correct types are used throughout the program, and it is certainly not possible for the program to automatically select the right comparison operation for the actual type at runtime.

In object-oriented languages, we can lift some of these restrictions, but at a price.