Argumentos para la programación funcional [cerrado]

Recientemente he estado aprendiendo F # por diversión (soy un desarrollador de VB.NET/C#), y realmente me gusta algo de lo que tiene para ofrecer. Teóricamente eso es. Pero tengo problemas para pensar en escenarios en los que elegiría codificar en F # en lugar de en C #. ¿Algunas ideas?

Algunos argumentos para la programación funcional pura:

• Es más fácil dividir tareas para los sistemas multi-core de hoy
• Es más fácil demostrar que su programa es correcto
• La composición funcional puede ser asombrosa, concisa y poderosa.

Para un tratamiento completo, vea Por qué es importante la programación funcional y Por qué es importante la programación funcional .

Tengo problemas para pensar en escenarios en los que elegiría codificar en F # en lugar de en C #. ¿Algunas ideas?

Desde aquí :

Servidores asincrónicos

• Flujos de trabajo asincrónicos para el IO asincrónico.
• Procesador de buzones para el paso de mensajes seguros para subprocesos.
• Tipos de unión para el estado del servidor y el catálogo de mensajes.
• Coincidencia de patrones y recursividad de cola para las máquinas de estado.

Metaprogramación (por ejemplo, análisis)

• Generadores de analizadores como fslex y fsyacc.
• Combinadores de analizador como FParsec.
• Patrones activos para elegantes analizadores enrollados a mano.
• Tipos de datos algebraicos para representar árboles de análisis.
• Coincidencia de patrones para manipular árboles, por ejemplo, aplicar etapas de optimización.
• Reflexión para la generación en tiempo de ejecución de código rápido.

Informática técnica

• Funciones de orden superior para un código algorítmico elegante y rápido.
• Tipos de datos algebraicos y coincidencia de patrones para manipulación simbólica.
• Interoperabilidad para la riqueza de las bibliotecas .NET.
• Interactividad usando F # interactive.
• Expresiones de cálculo para masajear datos.
• Unidades de medida para mejorar la corrección.

Aplicaciones GUI

• Modelo como mensaje asíncrono que pasa entre el código de interfaz de usuario y el código lógico de la aplicación.
• Las funciones de orden superior le permiten definir interfaces de usuario de forma declarativa.

Programación lógica

• Colecciones persistentes para retroceder fácilmente.
• La cola exige confiabilidad.
• Generalización automática para una fácil programación genérica.

Pruebas

• Ejecute pruebas unitarias de forma interactiva.
• BDD significa escribir un intérprete.
• Buen lenguaje de secuencias de comandos para escribir arneses de prueba y visualizar resultados.

Actuación

• inline para abstracción de orden superior sin costo.
• Tail requiere máquinas de estado rápidas.
• Estructuras de datos puramente funcionales para baja latencia.
• Metaprogramación para generación de código optimizado.

Esto es para lo que utiliza la programación de estilo funcional, más o menos a diario.

Hacemos muchas cosas estadísticas y actuariales con conjuntos de datos bastante grandes. Los datos que se obtienen de la base de datos son esencialmente objetos estáticos e inmutables. No hay razón para crear una clase con métodos.

Cada etapa del cálculo agrega algunos detalles adicionales, pero esencialmente no muta el objeto. Al "final" de la tubería, realmente estamos haciendo una reducción elegante para calcular sumas, recuentos y otras cosas.

Imagina esto.

for data in summarize( enrich( calculate( some_query( criteria() ) ) ) ):
    print data

Cada "fase" del cálculo es un bucle de programación funcional que realiza una simple lectura-cálculo-rendimiento y crea un objeto compuesto de otras cosas más resultados.

(Usamos Python, de ahí la programación funcional usando las funciones del generador).

Es más fácil usar objetos sin estado e inmutables.

Técnicamente, no es una propiedad única de una programación funcional, y F # no es un lenguaje funcional puro. F #, como uno de los descendientes de ML, proporciona una excelente coincidencia de patrones y tipos de datos algebraicos. Entonces, para cualquier tarea que requiera estructuras de datos complejas, F # es mucho más expresivo y fácil de usar que C #.

Imagine implementar un compilador en C # y F #: representar un árbol de sintaxis abstracta y transformarlo es mucho más simple si su lenguaje proporciona ADT y una coincidencia de patrones.

Ideal para el tipo de mapa reducido de multisistema masivo y paralelismo masivo multinúcleo. Bastante bueno, considerando que hoy en día los servidores de nivel de entrada vienen con 48 núcleos (96 contando HT).

Si quieres un funcionamiento completo, prueba Haskell, Erlang también tiene algunas cosas geniales al respecto.

Simon Payton-Jones dijo sobre Haskell, que quiere tener un programa que obviamente no tenga errores, en lugar de no tener errores obvios.

(Probablemente obtuve un poco la cita, pero entiendes la idea)

Al limitar los efectos secundarios, es mucho más fácil demostrar que su código es correcto.

Una ventaja definitiva es que es mucho más fácil de paralelizar.