Ma réponse précédente, un peu provocatrice, faisait référence aux langages traditionnels.
* En Haskell, les variables se rapproche plus de constantes Java/C++ dans la mesure ou elle ne peuvent pas muter, un "a += 2" n'a aucun sens.
* Le terme 'objet' est très large, là encore je faisais référence aux classes à la Java/C++ qui définisse un état interne et une série d'opérations liées à ces données. C'est surtout la notion d'identité qui s'oppose à celle de valeur.
* Concernant les effets de bords, la garantit de transparence référentielle pour le fonctions pures est un avantage. Évidemment il est possible de dégénérer vers le passage systématique de tout l'état du système via une "state monade" ;)
* Pour la généricité, elle est au coeur du système de type. Mais c'est vrai qu'il faudra toujours un effort supplémentaire pour généraliser du code.
[^] # Re: Mouais...
Posté par Ummon . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 2.
* En Haskell, les variables se rapproche plus de constantes Java/C++ dans la mesure ou elle ne peuvent pas muter, un "a += 2" n'a aucun sens.
* Le terme 'objet' est très large, là encore je faisais référence aux classes à la Java/C++ qui définisse un état interne et une série d'opérations liées à ces données. C'est surtout la notion d'identité qui s'oppose à celle de valeur.
* Concernant les effets de bords, la garantit de transparence référentielle pour le fonctions pures est un avantage. Évidemment il est possible de dégénérer vers le passage systématique de tout l'état du système via une "state monade" ;)
* Pour la généricité, elle est au coeur du système de type. Mais c'est vrai qu'il faudra toujours un effort supplémentaire pour généraliser du code.