Typage Statique et Dynamique

Après avoir dompté le chaos avec la POO et allégé nos lignes avec les lambdas,
un autre débat éternel est resté sur la table : faut-il typer ou pas ?

Tout commence dans les années 70 avec des langages comme C et Pascal qui imposent un typage statique.
T’es obligé de définir le type de chaque variable (int, float, char…), sinon ton code ne compile même pas.

Avantage ? Le compilateur te gueule dessus avant même que tu puisses lancer ton programme.
Résultat : moins d’erreurs à l’exécution et un code plus prévisible.
Parfait pour les systèmes critiques où la moindre erreur peut coûter cher.

Mais voilà, ça peut vite devenir lourd.
T’as envie de tester un truc vite fait ?
Faut déjà déclarer trois types avant d’écrire ta première ligne de logique.

C’est là que débarquent des langages comme Python, JavaScript ou Ruby avec un typage dynamique.
Ici, pas besoin de te prendre la tête :
tu déclares ta variable et le langage devine le type tout seul.
Rapide, flexible, parfait pour les protos et le scripting.

Mais cette flexibilité a un prix :

• T’oublies que user peut être null et BAM, t’as un TypeError en prod.
• Tu fais des modifs rapides sans tests, et tu te retrouves avec des bugs planqués dans des coins improbables.

Du coup, on a cherché à mixer les deux mondes.
TypeScript (pour JavaScript) ou MyPy (pour Python) sont arrivés pour ajouter du typage statique optionnel.
Tu peux continuer à coder à la cool, mais avec la possibilité de typer quand ça devient critique. Le meilleur des deux mondes.

Aujourd’hui ?

• Les projets rapides et flexibles aiment encore le typage dynamique.
• Les gros projets d’équipe (surtout en prod) préfèrent un typage statique pour éviter les surprises.

➡️ Et toi, t’es plutôt team “ça compile pas, ça plante pas” ou “on verra bien à l’exécution” ?
Partage ton camp en commentaire, que la guerre des types commence !