debugging - programación - programacion funcional vs orientada a objetos

¿Algunos constructos de programación funcional reducen la depuración?

Question

He oído que las siguientes características reducen la depuración (porque son anónimas y los depuradores no pueden rastrearlo bien)

1. Clases Anónimas
2. Clases internas
3. Bloques de cierre / funciones Lambda

¿Es esto cierto?

Answer 1

Es difícil decir si reducen intrínsecamente la depuración. Aún puede imprimir un seguimiento de pila si una función anónima arroja una excepción. DrScheme logra dibujar flechas rojas en todo el código cuando sucede algo, para representar el seguimiento de la pila, y eso se ocupa de las funciones anónimas. Sin embargo, no se ha dedicado tanto esfuerzo a la depuración de un lenguaje como Scheme o Haskell como ha sido en Java con, por ejemplo, Eclipse, por lo que las herramientas de depuración probablemente sean peores.

Y, como dijo JaredPar, Visual Studio parece hacer un buen trabajo con esto y C #.

Answer 2

Las características que ha enumerado no deberían causar problemas para un depurador diseñado para manejarlas. Si su depurador asume que va a depurar algo fundamentalmente no muy diferente de C, es posible que tenga problemas.

Ahora, una característica que se encuentra con más frecuencia en los lenguajes funcionales que realmente causa dolores de cabeza a los depuradores es el uso intensivo de la evaluación perezosa. Haskell es particularmente problemático en este sentido.

Answer 3

No creo particularmente que este sea el caso, desde mi punto de vista. Estoy usando las características funcionales de Scala, que se compila para ejecutarse en la Máquina Virtual de Java. Los depuradores como Intellij trabajan con esto correctamente.

Habiendo dicho eso, algunas construcciones de código se presentan de una manera diferente a como normalmente esperarías. Los bloques de funciones aparecen en algunos casos como clases internas. Las listas aparecen como entidades principales más una lista final (o podría ser al revés: ¡acabo de comenzar con esto!).

Answer 4

Ya hay algunas buenas respuestas con respecto a las características particulares que ha llamado.

En general, diría que algunas características de FP, así como el aspecto de la programación en un estilo más FP, al menos ''interactúan'' con la experiencia de depuración. Por ejemplo, al usar funciones de orden superior, uno puede programar en estilo sin puntos. Cuando lo hace, esto deja menos identificadores, lo que significa, por ejemplo, menos elementos que pueden inspeccionarse fácilmente en la ventana "locales" de un depurador. Los cierres suelen ser opacos hasta que entran en sus cuerpos.

FP también usa muchos constructos de inversión de control (la evaluación diferida es solo uno, un ''mapa'' o ''iter'' en lugar de un ''foreach'' siendo otro), lo que cambia el flujo de control y puede afectar la forma en que ''un solo paso'' trabajos.

A medida que FP se vuelve más común, espero que las herramientas de depuración continúen mejorando. No estoy seguro de si alguna FP es "intrínsecamente" más difícil de depurar, pero incluso si eso es cierto, no olvide que gran parte de FP hace que sea menos probable que su código necesite depuración en primer lugar. :)

Answer 5

Yo diría que esto es decididamente falso. Sí, sin soporte de depuración adicional estas construcciones pueden ser un poco más difíciles de depurar. En muchos idiomas, no son verdaderamente anónimos porque el depurador no comprende la semántica del lenguaje. En cambio, comprende la forma final del programa (el combo .exe y PDB). La mayoría de los constructos anónimos finalmente toman forma concreta en el programa final (muy cierto para las implementaciones de .Net).

Además, los lenguajes que implementan estas características a menudo se toman el tiempo para implementar un mejor soporte de depuración para ellos. Tome C # y VB por ejemplo

1. Ambos lenguajes agregan atributos DebuggerDisplay y reemplazan .ToString en los tipos anónimos generados para aumentar el soporte de depuración. Las implementaciones difieren un poco, pero el resultado es prácticamente el mismo.
2. Las clases internas no son muy especiales en cuanto a la depuración y no requieren mucho si hay trabajo adicional
3. VB y C # pasaron mucho tiempo en Visual Studio 2008 para "desenrollar" expresiones lambda y mostrar las variables libres capturadas como parte de la lista local original. Hace que sea mucho más fácil depurar una función