En fait on parle pas de la même chose je pense : pour moi (et flan apparemment), on parle d'un cas d'utilisation où tu programmes une application où il y a par exemple une méthode/fonction appelée avec des arguments venant d'une source non contrôlée, genre un utilisateur : dans ce genre de cas, le paradigme mis en avant par Erlang ne sert à rien.
Toi tu parles d'une situation (théorique à mon gout) où comme un acteur envoi à une autre des arguments incorrects, il fait planter l'autre, mais l'autre et relancé et le premier acteur "apprend" (d'une façon ou d'une autre) de son erreur et ne recommence pas, ou on "change" le code de l'acteur qui a planté et ça recommence pas.
Mais bon, c'est bien joli dans la théorie, mais dans la pratique, toute la difficulté va être cet "apprentissage" dont je parle (et j'inclue là dedans un apprentissage simple tout comme un apprentissage complexe, je ne suis pas en train de parler d'IA hein) ou encore de gérer le fait que ce qui a déjà craché ne peut pas être oublié (parce que si c'est ta déclaration d'impôts qui a crashée, tu vas pas trop aimer que le worker qui devait la prendre en compte ait été redémarré et que, dans le pire des cas elle soit zappée, et dans le meilleur des cas tu doivent la refaire :)
Alors c'est sûr que la question de l’interprétation des paramètres devient secondaire dans ce cadre, mais c'est une autre discussion et tu peux pas juste dire : easy on va changer le paradigme et faire restarter les méthodes/fonctions qui crashent ou easy on va changer le code qui crash at runtime.
[^] # Re: Bonne nouvelle
Posté par Victor . En réponse au journal Indication de type pour Python. Évalué à 5.
En fait on parle pas de la même chose je pense : pour moi (et flan apparemment), on parle d'un cas d'utilisation où tu programmes une application où il y a par exemple une méthode/fonction appelée avec des arguments venant d'une source non contrôlée, genre un utilisateur : dans ce genre de cas, le paradigme mis en avant par Erlang ne sert à rien.
Toi tu parles d'une situation (théorique à mon gout) où comme un acteur envoi à une autre des arguments incorrects, il fait planter l'autre, mais l'autre et relancé et le premier acteur "apprend" (d'une façon ou d'une autre) de son erreur et ne recommence pas, ou on "change" le code de l'acteur qui a planté et ça recommence pas.
Mais bon, c'est bien joli dans la théorie, mais dans la pratique, toute la difficulté va être cet "apprentissage" dont je parle (et j'inclue là dedans un apprentissage simple tout comme un apprentissage complexe, je ne suis pas en train de parler d'IA hein) ou encore de gérer le fait que ce qui a déjà craché ne peut pas être oublié (parce que si c'est ta déclaration d'impôts qui a crashée, tu vas pas trop aimer que le worker qui devait la prendre en compte ait été redémarré et que, dans le pire des cas elle soit zappée, et dans le meilleur des cas tu doivent la refaire :)
Alors c'est sûr que la question de l’interprétation des paramètres devient secondaire dans ce cadre, mais c'est une autre discussion et tu peux pas juste dire : easy on va changer le paradigme et faire restarter les méthodes/fonctions qui crashent ou easy on va changer le code qui crash at runtime.