Zeph (./14) :
Simplifier l'écriture. Mais je trouve que c'est une très mauvaise raison : un programme n'étant souvent pas écrit autant de fois qu'il n'est lu (sauf projet strictement perso, et encore), c'est la facilité de *lecture* qu'il vaudrait mieux privilégier. Je ne sais pas combien parmi vous ont déjà travaillé à plusieurs sur un gros projet dans un langage dynamique, mais c'est vraiment la misère. Le seul moyen de ne pas se paumer complètement est de s'imposer des conventions hyper strictes (par exemple détailler les entrées et sorties en commentaire de chaque méthode), ce qui revient grosso modo à ce que force naturellement à faire un langage statiquement typé (sauf que comme le compilateur/interpréteur ne peut rien vérifier, c'est sujet aux inévitables erreurs humaines).

Je suis entièrement d'accord sur le fait que la relecture et surtout la navigation facile dans de code est 100 fois plus important que la facilité d'écriture.

Et je trouve d'ailleurs que la facilité d'écriture de l'inférence de type est quand même très faible. Un "var i;" ne ne parait pas plus simple à écrire qu'un "int i;"

nitro (./15) :
Je trouve au contraire que moins il y a de types, plus le code est lisible (je préfère lire du JavaScript plutôt que du Java, pourtant la syntaxe est similaire), mais c'est peut-être une question d'habitude. Ca rend aussi le refactoring beaucoup plus rapide, pas besoin de modifier toutes les variables quand tu décides finalement que int64_t c'était mieux que int32_t.

C'est sans doute en effet une question d'habitude car pour moi, c'est tout l'inverse.
Quant au refactoring, c'est vrai que c'est un avantage auquel je n'avait pas pensé, mais au final, l'utilité me parait limitée, et je préfère vérifier manuellement qu'il n'y a pas d'effet de bord dans ces cas là.