Ceci dit, on peut tout à fait imaginer un typage qui serait simplement optionnel. C'est d'ailleurs le cas en Objective-C, qui permet de faire du typage statique ou du typage dynamique, au choix.
De la même façon, les méthodes que j'évoquerais devraient être optionnelles, l'idée étant de permettre d'optimiser uniquement les quelques morceaux de code qui peuvent être critiques.
D'ailleurs, c'est un truc que j'aime bien avec Python : on a différents niveaux d'optimisations :
- fichiers codés en pur Python,
- utilisation de Pypy (VM Python avec du JIT) avec du Python pur,
- libs spécialisées (genre numpy : types de données optimisés avec pas mal de fonctions sur les matrices),
- ctypes dans un code Python pour utiliser des structures C ou des fonctions C (dans un .dll ou un .so),
- cython : code Python pur avec des annotations (dont le typage) optionnelles, transformé en C puis compilé de façon transparente à la première exécution (ou sur demande),
- utilisation d'extensions Python codées en C / CUDA / OpenCL / MPI.
Du coup, on peut utiliser un langage souple mais lent pour les parties qui n'ont pas besoin d'être optimisées et qui sont faciles à relire (genre la lecture des arguments, etc.), puis un langage plus contraint pour les parties plus sensibles, tout en conservant un ensemble assez cohérent.