Le besoin d'un typage statique au sein d'un projet

Bonjour !

Je me permet d’écrire un petit post histoire d’avoir votre avis concernant une question que je me pose de plus en plus …

Je me demande pourquoi tant de gens pensent que le typage fort statique est important au sein d’un projet, par exemple, je vois beaucoup de gens faire du Typescript alors que s’il faisait directement du Javascript cela reviendrait "au même", je m’explique, pour des projets comme un serveur web, un bot discord, un CLI : Je ne vois pas vraiment la nécessité d’avoir des types par contre sur des jeux vidéo par exemple là je comprend un peu même si je trouve pas que ça soit une obligation

Pourriez-vous me donner votre ressentis ?

je m’explique, pour des projets comme un serveur web, un bot discord, un CLI : Je ne vois pas vraiment la nécessité d’avoir des types

C’est parce qu’ils sont de très petite taille (un script en gros) donc le besoin ne se fait pas aussi sentir (je n’inclurai pas une CLI par contre dans la liste, puisque ça peut aller du trivial au très compliqué). Pour des projets dépassants le seul état de « petit script », le typage statique fait gagner du temps et de la robustesse en te faisant tout de suite savoir au moment de la compilation si tu as fais une erreur quelque part, plutôt que d’attendre que ton programme plante lamentablement.

Le typage apporte plusieurs avantages.

Tout d’abord, cela aide à comprendre le code. Quand tu lis une fonction avec des arguments sans un type associé, tu ne sais pas vraiment la structure de données qui est derrière. Donc tu dois lire le code qui l’appelle ou le contenu de la fonction pour espérer comprendre.

Alors oui, cela se corrige avec une bonne doc, mais maintenir une doc pour informer sur le typage c’est fastidieux et il faut être sûr qu’elle soit à jour.

Ensuite, le compilateur peut vérifier si tu codes correctement. Que tu appelles la fonction avec un paramètre qui utilise la structure de données attendue. Ce qui est particulièrement utile pour refactoriser son code.

Là encore, avec des tests tu peux contourner le problème, mais cela implique une couverture de code à 100% (difficile à obtenir) et c’est un processus lent (mon compilateur va plus vite pour compiler le fichier modifié que d’exécuter la batterie de tests).

Du coup tu réduis le risque que ton programme plante à l’exécution car le type est mauvais, tu le sais avant de l’exécuter. Tu as plus de garanties et c’est confortable.

En tout cas dans de grands projets, le typage statique apporte un gain important de lisibilité et de garantie de fonctionnement ce qui est appréciable. Sur un code jetable ou de prototypage, ne pas se préoccuper du type peut être intéressant pour gagner du temps.

Malheureusement, la recherche scientifique n’a pas permis de trancher la question, comme le montre cette revue (en anglais) des articles se penchant sur la question : https://danluu.com/empirical-pl/. C’est bien de voir les intérêts des types, mais on oublie trop souvent de parler des inconvénients.

@gasche si tu as ton article Pourquoi attacher tant d’importance au typage sous le coude …

Je serai aussi intéressé si tu avais un bon article @gashe !

Cet article ?

Je ne sais pas si ça peut t’aider mais j’avais créé ce sujet pour discuter du typage dans les dernières versions de PHP.

Je serais curieux de savoir la part des erreurs de typage dans un langage comme le Javascript, parce que j’ai l’impression d’en faire très rarement. Le javascript n’a que quelques types : number, string, object (un array est un object), function. Toutes les variables que tu vas rencontrer seront forcement un de ces types, c’est quand même génial ! Et il faut y aller pour avoir des erreurs de typage.

La conversation se fait très facilement contrairement au langage comme C++ et C. Je me suis trouvé plusieurs fois en C/C++ à ne pas savoir comment convertir un type de variable vers un autre format alors que l’interface était similaire.

Par contre, en js quand tu commences à faire des math avancés c’est une catastrophe. Notamment avec l’absence de Vector.

Pour ce qui est du typage de Typescript, ça semble être intéressant et en fonction des goûts et des outils que tu vas utiliser ? Par contre je sais que souvent les développeurs TS râlent sur les githubs des modules NPM en JS parce qu’ils n’ont pas les déclarations typescripts, et ne semble pas vouloir le faire eux même.

TS, ce n’est pas que du Typage en plus. TS intégre implements et la possibilité d'extend plusieurs class ! La gestion des classes est beaucoup plus avancé que le JS. Les class du JS c’est du bricolage et toutes les fonctionnalités ne sont pas encore toutes intégrés dans les navigateurs… Si tu veux utiliser des class et outils nécessitant un webpack, TS semble judicieux.

Dans un langage fort, si tu utilises deux librairy différentes, tu peux te retrouver avec 2 formats différents pour une chaîne de caractère ou une liste d’éléments. Et ne pas savoir comment convertir l’élément. En typage faible, tu n’a jamais de soucis à savoir comment convertir une variable. Je me suis trouvé plusieurs fois en C/C++ à ne pas savoir comment convertir un type de variable vers un autre format, en langage faible, on n’a pas ce genre de soucis.

L’histoire avec les chaînes de caractères n’a pas vraiment de rapport avec typage faible et fort. Et tu mélanges typage faible/fort/statique/dynamique en pagaille. Dans le sujet cité par @Helmasaur, deux commentaires https://zestedesavoir.com/forums/sujet/12861/le-typage-fort/#p207367 et https://zestedesavoir.com/forums/sujet/12861/le-typage-fort/#p207376 résument très bien les avantages/inconvénients.

Je suis à peu près d’accord sur rien de ce qu'@A-312 a dit. ^^"

Tu confonds typage fort et typage statique. JavaScript, C et C++ ont un typage faible. JavaScript a un typage dynamique alors que le C et le C++ ont un typage statique.

En C, non ça n’arrive jamais, aucune bibliothèque proposera autre chose que char* pour une chaîne de caractères. En C++, c’est presque pareille, ça sera toujours un string ou char* pour une bibliothèque C. Des gros framework vont te proposer une surcharge mais c’est seulement au sein de ce framework. Et puisque c’est une surcharge il existe un constructeur depuis string ou const char*.

En typage dynamique tu ne sais jamais quel est vraiment le type des arguments d’une fonction. La documentation automatique ça devient impossible donc avoir de la doc, c’est pas une évidence.

Ok, non c’est vrai que le typage statique est généralement utilisé pour faire des maths.

Les classes de JavaScript, ce n’est pas du bricolage. C’est son modèle de classes et il est consistant. C’est pas celui du C++ mais il fonctionne bien.

Ok, non c’est vrai que le typage statique est généralement utilisé pour faire des maths.

Je nuancerai avec deux choses :

• Python est de plus en plus utilisé en math, et a un typage dynamique. C’est une surcouche, mais c’est quand même lui qui est utilisé par le programmeur.
• Je suppute très fort que les maths sont faites (dans les bibliothèques du tréfonds) dans des langages avec typage statique car la plupart des langages à typage dynamique ont de mauvaises performances¹. Ce n’est pas pour le typage en soi, mais pour d’autres raisons.

C’est un débat (types statiques ou non ?) qui semble sans fin. On n’a pas de façon fiable et objective de régler la question une fois pour toute (en gros : c’est trop difficile et coûteux d’essayer de faire une expérience grandeur nature sur du code existant, entre autres parce qu’il existe plein d’autres différences que le typage qui jouent dans ces comparaisons de langages), donc pour l’instant on s’en tient à des idées un peu anecdotiques.

Par exemple, moi anecdotiquement je trouve beaucoup plus pénible de faire un refactoring sur un projet non typé (… par exemple le code de ZdS, qui à l’époque où j’ai regardé en aurait eu l’usage) que dans un projet typé. Les types me guident en me disant quelles sont les parties à mettre à jour quand je change l’API d’une partie du code. Sans les types il faut se reposer sur les tests, mais dans mon expérience personnelle c’est beaucoup plus fragile en pratique.

Il y a aussi des aspects de langages de programmation qui sont plus faciles à faire sans typage (par exemple la réflexion, la mise à jour de code à chaud, etc.); à chacun de voir ce qui est important dans les projets qu’il ou elle utilise. En pratique les choix de langages sont souvent pris pour plein de raisons combinées, majoritairement sociales (ce langage est plus utilisé dans ma communauté, donc il a plus de documents d’aide et de bibliothèques pour m’aider), avant le typage et les autres raisons techniques.

Une remarque quand même: depuis plus d’une dizaine d’année, tous les utilisateurs industriels à grande échelle de langage non typé (Python, Ruby, Javascript, etc.) ont investi des millions d’euros par an pour soit migrer une partie de leur infrastructure vers un langage typé (PHP->Hack pour Facebook, etc.), soit développer des variantes typées de leur langage (Typescript, les outils de typage pour Python, Sorbet pour Ruby chez Stripe, etc.). Ça semble suggérer que les acteurs industriels pensent que typage est effectivement utile pour gérer la maintenance de gros projets, assez pour y investir des efforts considérables. (Après leur idée sur le sujet est peut-être fausse, peut-être qu’une récriture en Smalltalk de tous leurs outils apporterait des bénéfices de productivité comparables ou supérieurs.)