J'ai l'impression que par lisible tu veux dire "rapide à lire".
Non, je veux dire que je peux aussi facilement retrouver l'information qui m'intéresse comme le nom de la variable de l'élément itéré. Cette information n'est pas masquée par le bruit de l'imposant nom du type.
Par lisible, j’entends compréhensible, et ceci ne l'est pas, car si la définition de "conteneur" est 40 lignes plus haut ou si c'est lui même un "auto" machin, le code n'est PAS compréhensible. Même pas en rêve avec tes technos dites "modernes" et les bonnes pratiques de mamie.
Et pourtant en pratique cela fonctionne très bien. Déjà quand tu évites d'avoir des fonctions de 20 kilomètres de long et que tu as un environnement de travail efficace, ça pose de suite moins de problèmes théoriques. Je rappelle qu'en programmation une bonne pratique est d'avoir des portions de codes réutilisables, réduites (des fonctions donc courtes) au maximum ce qui implique peu de variables dans le même scope. Cela allège grandement ta charge de travail pour ta mémoire
Enfin c'est amusant, moi je m'en suis servi, comme d'autres, dans des projets conséquents sans soucis et toi tu juges apparemment sans t'en être servi dans un langage avec un typage fort. Je te propose de tester en pratique avant d'émettre des de telles positions.
Car bon, inférence de types = JavaScript = merde, on a vu mieux comme argumentation. Je ne suis pas fan du JavaScript, mais ses défauts ne sont pas liés à son inférence de type (ou disons que son inférence de types gêne car il est faiblement typé).
Je ne dis pas que le compilateur va se tromper, c'est le programmeur qui ne peux pas s'y retrouver (à moins que ta "bonne pratique" c'est frde nommer les variables/les paramètres en incluant le type.
Un bon nommage peut largement induire aussi le type de l'objet. Tu te doutes que "i" dans une boucle est un entier, que "it" dans le même cas est un itérateur, que "name" est une chaîne de caractères. Cela aide à la compréhension et évite de devoir se préoccuper du type exact.
Car bon, même avec le type explicite à la déclaration, si tu es à 40 lignes plus bas et que tu as un doute, tu dois revenir en arrière pour vérifier. Ce n'est pas mieux.
c'est casse gueule au possible et complètement inutile (et c'est pas parce que Rust le fait que c'est bien).
Dixit le gars qui n'a jamais expérimenté tout cela au quotidien. Amusant.
Sinon l'inférence de types est également nécessaire pour exploiter les lambdas anonymes. Mais là encore, je sens que c'est une fonctionnalité sans intérêt pour toi.
(notons au passage que les gros projets Javascript migrent vers Cleartype pour justement avoir du code "lisible" et plus robuste que la loterie à base de "let" et "var")
Tu comprendras quand que le soucis du JavaScript n'est pas l'inférence de types en lui même ?
Le soucis de JavaScript est d'être faiblement typé, avec inférence de types et une faible rigueur de comportements. C'est ce cocktail qui est explosif. Cela tombe bien, beaucoup de langages modernes ont l'inférence de types pour ses avantages, mais ont un typage fort et un comportement rigoureux pour éviter ses effets de bord. Preuve qu'on peut avoir tout cela en même temps sans soucis.
Car ce cocktail, c'est lui qui fait que ta fonction attend un paramètre d'un certain type, que finalement tu lui envoies une valeur d'un autre type et qu'une conversion implicite absurde est appliquée. Le tout au runtime histoire que cela se détecte qu'en vol. C'est vraiment cette combinaison qui rend la maintenance d'un code JavaScript délicat.
Avec l'inférence de types et un typage fort, cela n'arrive pas. Tu n'as pas le type explicité partout, mais en cas de conflit le compilateur te prévient et tu résous cela en corrigeant le bogue ou en créant une conversion explicite du type A vers B si cela a un sens. Donc en cas de refactorisation tu es gagnant, tu peux changer le type d'une variable (passer de int à long, améliorer le nom de ta classe) sans devoir tout ressaisir (il y aura un peu de travail évidemment mais moins). Et tu allèges considérablement le code d'informations qui sont essentiellement redondantes ce qui rend le code plus aéré et donc lisible.
[^] # Re: Inférence de types
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de JDK 10. Évalué à 10. Dernière modification le 10 novembre 2018 à 01:15.
Non, je veux dire que je peux aussi facilement retrouver l'information qui m'intéresse comme le nom de la variable de l'élément itéré. Cette information n'est pas masquée par le bruit de l'imposant nom du type.
Et pourtant en pratique cela fonctionne très bien. Déjà quand tu évites d'avoir des fonctions de 20 kilomètres de long et que tu as un environnement de travail efficace, ça pose de suite moins de problèmes théoriques. Je rappelle qu'en programmation une bonne pratique est d'avoir des portions de codes réutilisables, réduites (des fonctions donc courtes) au maximum ce qui implique peu de variables dans le même scope. Cela allège grandement ta charge de travail pour ta mémoire
Enfin c'est amusant, moi je m'en suis servi, comme d'autres, dans des projets conséquents sans soucis et toi tu juges apparemment sans t'en être servi dans un langage avec un typage fort. Je te propose de tester en pratique avant d'émettre des de telles positions.
Car bon, inférence de types = JavaScript = merde, on a vu mieux comme argumentation. Je ne suis pas fan du JavaScript, mais ses défauts ne sont pas liés à son inférence de type (ou disons que son inférence de types gêne car il est faiblement typé).
Un bon nommage peut largement induire aussi le type de l'objet. Tu te doutes que "i" dans une boucle est un entier, que "it" dans le même cas est un itérateur, que "name" est une chaîne de caractères. Cela aide à la compréhension et évite de devoir se préoccuper du type exact.
Car bon, même avec le type explicite à la déclaration, si tu es à 40 lignes plus bas et que tu as un doute, tu dois revenir en arrière pour vérifier. Ce n'est pas mieux.
Dixit le gars qui n'a jamais expérimenté tout cela au quotidien. Amusant.
Sinon l'inférence de types est également nécessaire pour exploiter les lambdas anonymes. Mais là encore, je sens que c'est une fonctionnalité sans intérêt pour toi.
Tu comprendras quand que le soucis du JavaScript n'est pas l'inférence de types en lui même ?
Le soucis de JavaScript est d'être faiblement typé, avec inférence de types et une faible rigueur de comportements. C'est ce cocktail qui est explosif. Cela tombe bien, beaucoup de langages modernes ont l'inférence de types pour ses avantages, mais ont un typage fort et un comportement rigoureux pour éviter ses effets de bord. Preuve qu'on peut avoir tout cela en même temps sans soucis.
Car ce cocktail, c'est lui qui fait que ta fonction attend un paramètre d'un certain type, que finalement tu lui envoies une valeur d'un autre type et qu'une conversion implicite absurde est appliquée. Le tout au runtime histoire que cela se détecte qu'en vol. C'est vraiment cette combinaison qui rend la maintenance d'un code JavaScript délicat.
Avec l'inférence de types et un typage fort, cela n'arrive pas. Tu n'as pas le type explicité partout, mais en cas de conflit le compilateur te prévient et tu résous cela en corrigeant le bogue ou en créant une conversion explicite du type A vers B si cela a un sens. Donc en cas de refactorisation tu es gagnant, tu peux changer le type d'une variable (passer de int à long, améliorer le nom de ta classe) sans devoir tout ressaisir (il y aura un peu de travail évidemment mais moins). Et tu allèges considérablement le code d'informations qui sont essentiellement redondantes ce qui rend le code plus aéré et donc lisible.