Je crois qu'il va falloir inventer le Turing tar pit tar pit :)
Si j'avais dit: "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une chaîne de tests en retournant un booléen à chaque appel", je serais tombé dans le Turing tar pit parce que c'est une solution moins efficace qu'un support natif, et qui fournit moins de garanties statiques (checked exceptions par exemple).
Si j'avais dit "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une transformation CPS", je serais tombé dans le Turing tar pit parce que c'est une transformation non locale et non triviale.
Ce que je voulais dire ici c'est que justement, il n'y pas non seulement pas besoin de support du langage pour faire de la programmation fonctionnelle, mais un langage n'a que peu à offrir en la matière. Il s'agit plus d'une philosophie de programmation.
Maintenant, certains langages (comme haskell) encouragent ce style de programmation en confinant par typage les effets de bords. Certains environnements (comme scala) encouragent ce style de programmation en fournissant des structures de données persistantes dans la bibliothèque standard. Dans les deux cas, il ne s'agit pas d'une simulation et ça n'a donc rien à voir avec le Turing tar pit.
Pour en revenir au sujet de départ, je pense que la personne qui a écrit le journal voulait parler de la capacité du langage à abstraire sur les fonctions, qu'on associe souvent aux langages fonctionnels parce qu'elle y est lié historiquement et, je suppose, parce qu'il y a "fonction" dans "fonctionnel". Ma remarque portait là-dessus.
[^] # Re: Programmation Fonctionnelle
Posté par _ . En réponse au journal Votre langage idéal ?. Évalué à 1.
Je crois qu'il va falloir inventer le Turing tar pit tar pit :)
Si j'avais dit: "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une chaîne de tests en retournant un booléen à chaque appel", je serais tombé dans le Turing tar pit parce que c'est une solution moins efficace qu'un support natif, et qui fournit moins de garanties statiques (checked exceptions par exemple).
Si j'avais dit "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une transformation CPS", je serais tombé dans le Turing tar pit parce que c'est une transformation non locale et non triviale.
Ce que je voulais dire ici c'est que justement, il n'y pas non seulement pas besoin de support du langage pour faire de la programmation fonctionnelle, mais un langage n'a que peu à offrir en la matière. Il s'agit plus d'une philosophie de programmation.
Maintenant, certains langages (comme haskell) encouragent ce style de programmation en confinant par typage les effets de bords. Certains environnements (comme scala) encouragent ce style de programmation en fournissant des structures de données persistantes dans la bibliothèque standard. Dans les deux cas, il ne s'agit pas d'une simulation et ça n'a donc rien à voir avec le Turing tar pit.
Pour en revenir au sujet de départ, je pense que la personne qui a écrit le journal voulait parler de la capacité du langage à abstraire sur les fonctions, qu'on associe souvent aux langages fonctionnels parce qu'elle y est lié historiquement et, je suppose, parce qu'il y a "fonction" dans "fonctionnel". Ma remarque portait là-dessus.
Gentiement.