Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre.
C'est mon point : il est bien plus frustrant de perdre quelque chose que l'on a que de ne pas l'avoir.
Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide).
MyFnc() ne cast pas, elle n'a pas besoin de typage nominal. Il faut juste que l'objet qu'on lui passe en paramètre se comporte comme elle l'attends. En go il va falloir que tu explicite cet attendu dans une interface. Quand c'est simple et limité pas de problème quand ça devient plus complexe ça devient plus pratique de réutiliser l'interface initial mais tu a perdu l'intérêt de ton typage dynamique.
J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique
Ce n'est pas mon point. Mon point c'est que le champs où dans les langages statiquement typés (globalement), on se place dans un contexte où l'on pète les informations de types (interface{} en go, Object en java, void* en C et C++,...) on se trouve dans un cadre où le langage que tu as choisi perds une partie de ses fonctionnalités et tu entre pas forcément clairement dans un paradigme différent. C'est un cas où on fait bien plus d'erreur car on ne manipule plus le langage de la même façon où on a l'habitude.
Il n'y a pas de manichéisme là dedans. Une approche différente, que je suis entrain de faire d'ailleurs c'est les intégrations de langage. Si tu met du groovy dans du java, du lua dans du C++ ou du C++ dans du python, tu aussi un changement de paradigme, mais il est bien plus évident à appréhender.
[^] # Re: Go est lent, Rust est rouillé !
Posté par barmic 🦦 . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 3.
C'est mon point : il est bien plus frustrant de perdre quelque chose que l'on a que de ne pas l'avoir.
Et bien non. Si je prends ce code là :
MyFnc()ne cast pas, elle n'a pas besoin de typage nominal. Il faut juste que l'objet qu'on lui passe en paramètre se comporte comme elle l'attends. En go il va falloir que tu explicite cet attendu dans une interface. Quand c'est simple et limité pas de problème quand ça devient plus complexe ça devient plus pratique de réutiliser l'interface initial mais tu a perdu l'intérêt de ton typage dynamique.Ce n'est pas mon point. Mon point c'est que le champs où dans les langages statiquement typés (globalement), on se place dans un contexte où l'on pète les informations de types (interface{} en go, Object en java, void* en C et C++,...) on se trouve dans un cadre où le langage que tu as choisi perds une partie de ses fonctionnalités et tu entre pas forcément clairement dans un paradigme différent. C'est un cas où on fait bien plus d'erreur car on ne manipule plus le langage de la même façon où on a l'habitude.
Il n'y a pas de manichéisme là dedans. Une approche différente, que je suis entrain de faire d'ailleurs c'est les intégrations de langage. Si tu met du groovy dans du java, du lua dans du C++ ou du C++ dans du python, tu aussi un changement de paradigme, mais il est bien plus évident à appréhender.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll