et une erreur de type c’est assez courant pour qu’on la reconnaisse du premier coup d’œil, même avec peu d’expérience.
Si on sort des exemples bétas 1 + "two" et bien non les erreurs de type ne sont pas faciles à repérer à la lecture. Ces temps-cis je travaille sur un code NodeJS qui lit depuis une base de données. La BDD a des capacités de tri limitées et l'API que j'implémente doit aussi proposer du tri et de la réduction de données (un peu comme le group by de SQL pour faire vite). Dans le code existant, la lecture de la BDD produit un flot d'items, mais pour pouvoir profiter des capacités de tri de celle-ci, j'ai décidé de changer en un "flot de pages d'items peut-être triées" ce qui simplifie beaucoup la communication entre les modules de l'application. Un langage comme OCaml ou Haskell permet au compilateur de détecter automatiquement toutes les zones de code affectées par ce changement de type. JavaScript ou les langages typés dynamiquement en général n'apportent simplement aucune aide pour résoudre ce problème – qui est pourtant le pain quotidien du programmeur non?
Autre exemple plus béta, on ne reconnaît pas forcément du premier coup d'œil qu'il fallait écrire if("names" in params) plutôt que if(names in params) et le compilateur d'un langage typé statiquement détecte l'erreur instantanément. Dans mon application NodeJS avec du code asynchrone, je me retrouve avec une exception et une pile d'erreur inutilisable car toutes les fonctions référencées sont des callbacks d'une bibliothèque pour la programmation asynchrone et donc pas du code utilisateur.
Je n'ai donc aucun mal a percevoir l'intérêt du typage statique.
[^] # Re: Un peu déçu par Rust
Posté par Michaël (site web personnel) . En réponse au journal Un print(1 + "3a"), ça nous inspire comment ?. Évalué à 5. Dernière modification le 03 avril 2017 à 12:18.
Si on sort des exemples bétas
1 + "two"et bien non les erreurs de type ne sont pas faciles à repérer à la lecture. Ces temps-cis je travaille sur un code NodeJS qui lit depuis une base de données. La BDD a des capacités de tri limitées et l'API que j'implémente doit aussi proposer du tri et de la réduction de données (un peu comme legroup byde SQL pour faire vite). Dans le code existant, la lecture de la BDD produit un flot d'items, mais pour pouvoir profiter des capacités de tri de celle-ci, j'ai décidé de changer en un "flot de pages d'items peut-être triées" ce qui simplifie beaucoup la communication entre les modules de l'application. Un langage comme OCaml ou Haskell permet au compilateur de détecter automatiquement toutes les zones de code affectées par ce changement de type. JavaScript ou les langages typés dynamiquement en général n'apportent simplement aucune aide pour résoudre ce problème – qui est pourtant le pain quotidien du programmeur non?Autre exemple plus béta, on ne reconnaît pas forcément du premier coup d'œil qu'il fallait écrire
if("names" in params)plutôt queif(names in params)et le compilateur d'un langage typé statiquement détecte l'erreur instantanément. Dans mon application NodeJS avec du code asynchrone, je me retrouve avec une exception et une pile d'erreur inutilisable car toutes les fonctions référencées sont des callbacks d'une bibliothèque pour la programmation asynchrone et donc pas du code utilisateur.Je n'ai donc aucun mal a percevoir l'intérêt du typage statique.