Porque todas esas ventajas también son desventajas.
Programas apátridas; Sin efectos secundarios
Los programas del mundo real tienen que ver con los efectos secundarios y la mutación. Cuando el usuario presiona un botón es porque quiere que algo suceda. Cuando escriben algo, quieren que ese estado reemplace cualquier estado que solía estar allí. Cuando Jane Smith en contabilidad se casa y cambia su nombre a Jane Jones, es mejor que la base de datos que respalda el proceso comercial que imprime su cheque de pago se trata de manejar ese tipo de mutación. Cuando disparas la ametralladora al alienígena, la mayoría de las personas no modelan mentalmente eso como la construcción de un nuevo alienígena con menos puntos de vida; modelan eso como una mutación de las propiedades de un extraterrestre existente.
Cuando los conceptos del lenguaje de programación funcionan fundamentalmente contra el dominio que se está modelando, es difícil justificar el uso de ese lenguaje.
Concurrencia; Juega extremadamente bien con la creciente tecnología de múltiples núcleos
El problema simplemente se resuelve. Con estructuras de datos inmutables, tiene una seguridad de subprocesos barata a costa de posiblemente trabajar con datos obsoletos. Con estructuras de datos mutables, tiene la ventaja de trabajar siempre en datos nuevos a costa de tener que escribir una lógica complicada para mantener los datos consistentes. No es que uno de esos sea obviamente mejor que el otro.
Los programas suelen ser más cortos y, en algunos casos, más fáciles de leer.
Excepto en los casos en que son más largos y difíciles de leer. Aprender a leer programas escritos en un estilo funcional es una habilidad difícil; la gente parece ser mucho mejor para concebir los programas como una serie de pasos a seguir, como una receta, más que como una serie de cálculos a realizar.
La productividad aumenta (ejemplo: Erlang)
La productividad tiene que subir mucho para justificar el gasto masivo de contratar programadores que saben programar en un estilo funcional.
Y recuerde, no desea tirar un sistema de trabajo; la mayoría de los programadores no están construyendo nuevos sistemas desde cero, sino que mantienen los sistemas existentes, la mayoría de los cuales fueron construidos en lenguajes no funcionales. Imagínese tratando de justificar eso a los accionistas. ¿Por qué descartó su sistema de nómina de trabajo existente para construir uno nuevo a costa de millones de dólares? "Porque la programación funcional es increíble" es poco probable que deleite a los accionistas.
La programación imperativa es un paradigma muy antiguo (que yo sepa) y posiblemente no sea adecuado para el siglo XXI.
La programación funcional también es muy antigua. No veo cómo la edad del concepto es relevante.
No me malinterpretes. Me encanta la programación funcional, me uní a este equipo porque quería ayudar a traer conceptos de la programación funcional a C #, y creo que programar en un estilo inmutable es el camino hacia el futuro. Pero la programación en un estilo funcional tiene enormes costos que no se pueden descartar. El cambio hacia un estilo más funcional va a suceder lenta y gradualmente durante décadas. Y eso es lo que será: un cambio hacia un estilo más funcional, no una aceptación general de la pureza y belleza de Haskell y el abandono de C ++.
Construyo compiladores para vivir y definitivamente estamos adoptando un estilo funcional para la próxima generación de herramientas de compilación. Esto se debe a que la programación funcional es fundamentalmente una buena combinación para el tipo de problemas que enfrentamos. Nuestros problemas tienen que ver con tomar información en bruto (cadenas y metadatos) y transformarlos en diferentes cadenas y metadatos. En situaciones en las que ocurren mutaciones, como si alguien estuviera escribiendo en el IDE, el espacio del problema se presta inherentemente a técnicas funcionales como la reconstrucción incremental solo de las partes del árbol que cambiaron. Muchos dominios no tienen estas buenas propiedades que los hacen evidentemente susceptibles a un estilo funcional .