Certaines constructions de programmation fonctionnelle réduisent-elles la rapidité?

Il est difficile de dire s'ils réduisent intrinsèquement la rapidité. Vous pouvez toujours imprimer une trace de pile si une fonction anonyme jette une exception. Drscheme parvient à dessiner des flèches rouges sur votre code lorsque quelque chose se passe, pour représenter la trace de la pile, et qui traite des fonctions anonymes. Cependant, nulle part à peu près autant d'efforts a été mis en œuvre dans le débogage d'une langue comme un stratagème ou Haskell, comme cela a été java avec, par exemple, Eclipse, bien sûr, les outils de débogage sont probablement pires.

Et, comme Jaredpar, dit, Visual Studio semble faire un bon travail avec cela et C #.

Les fonctionnalités que vous avez énumérées ne devraient pas causer de problèmes pour un débogueur conçu pour les gérer. Si votre débogueur suppose que vous déboguerez quelque chose de fondamentalement pas trop différent de C, vous pourriez avoir des problèmes.

Maintenant, une caractéristique trouvée plus souvent dans des langages fonctionnelles qui sont causent des maux de tête pour les debuggers est une forte utilisation d'une évaluation paresseuse. Haskell est particulièrement problématique à cet égard.

Je ne crois pas particulièrement que c'est le cas, de mon point de vue. J'utilise les fonctionnalités fonctionnelles de Scala, qui compile pour fonctionner sur la machine virtuelle Java. Debuggers tels que le travail de Intellij avec cela correctement.

Cela dit, certaines constructions de code sont présentées de manière différente de la manière dont vous vous attendriez normalement. Les blocs de fonction apparaissent dans certains cas sous forme de classes intérieures. Les listes apparaissent en tant qu'entité de la tête plus une liste de la queue (ou cela pourrait être l'inverse - je viens de commencer avec ceci!).

Il y a déjà de bonnes réponses concernant les fonctionnalités particulières que vous avez appelées.

En général, je dirais que certaines fonctionnalités de PF, ainsi que l'aspect de la programmation dans un style plus de PF, font au moins "interagir" avec l'expérience de débogage. Par exemple, en utilisant des fonctions d'ordre supérieur, on peut programmer un style sans points de vue. Lorsque vous le faites, cela laisse moins d'identifiants, ce qui signifie par ex. Moins de choses qui peuvent facilement être inspectées dans la fenêtre "Locaux" d'un débogueur. Les fermetures sont typiquement opaques jusqu'à ce que vous entrez dans leur corps.

FP utilise également de nombreuses constructions d'inversion de contrôle (évaluation paresseuse étant une seule, une «carte» ou «iter» plutôt qu'un «foreach» étant un autre), ce qui modifie le flux de contrôle et peut avoir une incidence sur laquelle -supping 'Works.

Alors que FP devient plus courant, je m'attends à ce que les outils de débogage continueront à s'améliorer. Il n'est pas clair pour moi si des FP sont "intrinsèquement" plus difficiles à déboguer, mais même si cela est vrai, n'oubliez pas que beaucoup de FP rend votre code moins susceptible de faire déboguer en premier lieu. :)