48 votos

dificultades o desventajas de la programación funcional

Cuando usted NO desea utilizar la programación funcional? ¿Qué es lo no tan bueno?

Yo soy más buscando desventajas del paradigma como un todo, no cosas como "no utilizados", o "no hay buen depurador disponible". Esas respuestas pueden ser correctas a partir de ahora, pero tratan con FP de un nuevo concepto (un tema inevitable) y no de las cualidades inherentes.

Relacionado con:

34voto

Norman Ramsey Puntos 115730

Es difícil para mí pensar en muchas desventajas de la programación funcional. Entonces de nuevo, soy un ex-presidente de la Conferencia Internacional sobre la Programación Funcional, así que usted puede asumir con seguridad que soy parcial.

Creo que las principales desventajas tienen que ver con el aislamiento y con barreras a la entrada. Aprender a escribir buenos programas funcionales significa aprender a pensar de manera diferente, y para hacerlo bien requiere una inversión considerable de tiempo y esfuerzo. Es difícil aprender sin un maestro. Estas propiedades conducir a algunas desventajas:

  • Es probable que un programa funcional, escrito por un recién llegado será innecesariamente lento-más probable que, por ejemplo, un programa en C, escrito por un recién llegado a C. Por otro lado, es igualmente probable que un programa de C++ escrito por un recién llegado será innecesariamente lento. (Todos aquellos brillantes características...)

    Generalmente, los expertos no tienen dificultad para escribir rápido de programas funcionales; y de hecho algunos de los mejores programas paralelos en 8 - y 16-core están ahora escrito en Haskell.

  • Es más probable que alguien que se inicie la programación funcional se dan por vencidos antes de darse cuenta de que el prometido aumento de la productividad que se alguien que empieza, digamos, Python o Visual Basic. Simplemente no hay mucho apoyo en la forma de libros y herramientas de desarrollo.

  • Hay menos gente a hablar. Stackoverflow es un buen ejemplo; los relativamente pocos Haskell programadores de visitar regularmente el sitio (aunque parte de esto es que Haskell programadores tienen sus propias animada los foros que son mucho más antiguas y mejor establecidas de Stackoverflow).

    También es cierto que usted no puede hablar con su vecino muy fácilmente, porque funcionales-conceptos de programación son más difíciles de enseñar y más difícil de aprender que los conceptos de orientación a objetos detrás de lenguajes como Smalltalk, Ruby y C++. Y también, el objeto-orientado a la comunidad ha pasado años desarrollando buenas explicaciones de lo que hacen, mientras que la funcional de programación de la comunidad parecen pensar que su material es, obviamente, un gran y no requiere ningún tipo especial de metáforas o de vocabulario para la explicación. (Ellos están equivocados. Todavía estoy esperando el primer gran libro Funcional de los Patrones de Diseño.)

  • Un conocido desventaja de perezoso de programación funcional (se aplica a Haskell o Limpia, pero no a ML o Esquema o Clojure) es que es muy difícil predecir el tiempo y el espacio de los costos de la evaluación de un perezoso programa funcional-incluso los expertos no pueden hacerlo. Este problema es fundamental para el paradigma y no va a desaparecer. Hay excelentes herramientas para descubrir el tiempo y el espacio comportamiento post facto, sino para utilizarlos de forma efectiva tienes que ser experto ya.

23voto

Brian Puntos 82719

Si su idioma no proporcionan buenos mecanismos de plomo/estado de excepción en el comportamiento a través de su programa (por ejemplo, la sintaxis de los azúcares, por monádico une), a continuación, cualquier tarea que implique estado/excepciones se convierte en una tarea. (Incluso con estos azúcares, algunas personas pueden encontrar que es más difícil lidiar con el estado/excepciones en FP.)

Funcional modismos a menudo hacer un montón de inversion-de-control o de la pereza, que a menudo tiene un impacto negativo en la depuración (el uso de un depurador). (Esto es algo compensado por la FP es mucho menos propenso a errores debido a la inmutabilidad/transparencia referencial, que significa que usted tendrá que depurar con menos frecuencia).

23voto

Chuck Puntos 138930

Una gran desventaja a la programación funcional es que en un plano teórico, que no coincide con el hardware, así como de la mayoría de los lenguajes imperativos. (Esta es la otra cara de uno de sus evidentes fortalezas, ser capaz de expresar lo que quiere hacer, en lugar de cómo desea que el equipo para hacerlo.)

Por ejemplo, la programación funcional hace un uso intensivo de la recursividad. Esto está bien en el puro cálculo lambda debido a que las matemáticas' "pila" es ilimitado. Por supuesto, en el hardware real, la pila es muy finito. Ingenuamente recursing sobre un gran conjunto de datos puede hacer que su programa bum. La mayoría de los lenguajes funcionales optimizar la recursión de la cola para que esto no suceda, sino hacer un algoritmo cola recursiva puede obligar a hacer algún lugar unbeautiful código de gimnasia (por ejemplo, una cola recursivos en el mapa de la función crea una atrás de la lista o crear una diferencia de lista, por lo que tiene que hacer trabajo extra para volver a normal asignado lista en el orden correcto en comparación con la no-cola-versión recursiva).

(Gracias a Jared Updike por la diferencia de la lista de sugerencias.)

17voto

Jon Harrop Puntos 26951

Creo que la mierda que rodea los lenguajes funcionales es el mayor problema de la programación funcional. Cuando comencé a usar la programación funcional en la ira, un gran obstáculo para mí fue la comprensión de por qué muchos de los altamente evolucionados argumentos esgrimidos por la comunidad Lisp (por ejemplo, acerca de las macros y homoiconic sintaxis) estaban equivocados. Hoy en día, veo a muchas personas de ser engañados por el Haskell de la comunidad con respecto a la programación paralela.

De hecho, usted no tiene que mirar más allá de este mismo hilo para ver algunos de:

"En general, los expertos no tienen dificultad para escribir rápido de programas funcionales; y de hecho algunos de los mejores programas paralelos en 8 - y 16-core están ahora escrito en Haskell."

Declaraciones como esta puede dar la impresión de que los expertos elegir Haskell porque puede ser muy bueno para el paralelismo, pero la verdad es que Haskell rendimiento de la chupa y el mito de que Haskell es bueno para multinúcleo paralelismo que se perpetúa por Haskell investigadores con poco o ningún conocimiento acerca del paralelismo que evitar real de revisión por pares por solo publicando dentro de la zona de confort de revistas y conferencias bajo el control de su propia camarilla. Haskell es invisible en el mundo real paralelo/mst/HPC precisamente porque es una mierda en la programación paralela.

Específicamente, el verdadero reto en programación multinúcleo es tomar ventaja de los cachés de la CPU para asegurarse de núcleos no son muertos de hambre de los datos, un problema que nunca ha sido abordado en el contexto de Haskell. Charles Leiserson del grupo en el MIT, hizo un excelente trabajo de explicar y resolver este problema utilizando sus propios Cilk idioma que pasó a convertirse en la columna vertebral de la programación paralela para lances del mst en tanto Intel TBB y Microsoft TPL .NET 4. Hay una excelente descripción de cómo esta técnica puede ser usada para escribir elegante de alto nivel imperativo código que se compila a escalable de alto rendimiento de código en el papel de 2008 El caché de la complejidad de multiproceso caché ajeno algoritmos. He explicado esto en mi reseña de algunos de los estado-de-el-arte Paralelo Haskell investigación.

Esto deja un gran signo de interrogación sobre el puramente funcional paradigma de programación. Este es el precio que usted paga por abstracción del tiempo y el espacio, que siempre fue la principal motivación detrás de este paradigma declarativo.

EDIT: Texas Multinúcleo Tecnologías también han encontrado recientemente Haskell a ser decepcionante en el contexto de varios núcleos de paralelismo.

14voto

Jared Updike Puntos 3946

Felipe Wadler escribió un artículo acerca de esto (que se llama ¿por Qué nadie Usa Lenguajes de Programación Funcional) y se dirigió a las dificultades prácticas a dejar que la gente el uso de PF idiomas:

Actualización: inaccesible antiguo enlace para aquellos con ACM de acceso:

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X