Programación funcional: mida siete veces, corte una vez

Buenas tardes Recientemente, escucho muy a menudo que ha llegado el ocaso de la OLP. Hoy, más y más personas se están moviendo hacia un paradigma funcional. Pronto, las personas que escriben en C ++ / C # / Java no se quedarán en absoluto. Es asi? No lo creo En mi opinión, el uso irreflexivo de FP (programación funcional) puede llevar mucho tiempo y un dolor de cabeza adicional, que es completamente incompatible con las decisiones de diseño actuales. ¡Asegurémonos de eso!



Quiero señalar: no se trata de expresiones lambda en Java / Python, sino de un FP más avanzado como Haskell o Scala con cats / scalaz.

Entonces, afirmo que:

1. AF está lejos de ser aplicable en todas partes.
2. Trae un dolor de cabeza cuando se integra con soluciones preparadas.
3. Pasar tiempo en FA no siempre es prudente.

Analizaremos estos puntos con más detalle y evaluaremos la escala de la tragedia.

1. AF está lejos de ser aplicable en todas partes

Esto parece sorprendente, pero no todos entienden esto. Además, lenguajes como C están muy lejos de la puesta del sol. Mucho más lejos que Haskell o Scala. Echa un vistazo a cualquier motor de juego. Con una probabilidad del 90%, la mayor parte está escrita en C. Eche un vistazo al firmware de cualquier dispositivo doméstico en su departamento. Lo más probable es que esto sea nuevamente C! Sistemas operativos? Por supuesto C.

¿Por qué está pasando esto? El hecho es que todo lo anterior funciona directamente con hierro. Iron no conoce ninguna función de orden superior. El hierro es un conjunto de registros (que ya es un estado mutable), interrupciones (nuevamente, que cambian de estado) y comandos que transfieren ceros y unos de una celda a otra.

Por supuesto, puedes usar la abstracción y olvidarte de todas estas cosas de hierro. Pero, en primer lugar, esto no siempre es razonable. Si nuestro programa es bastante simple, entonces no tiene sentido cerrar con algunas capas de abstracción. En segundo lugar, a menudo en tales programas, la velocidad del trabajo se coloca en una de las posiciones clave. Por lo tanto, el costo adicional de "explicar" la glándula FP arruinará por completo el beneficio de su desarrollo. AF no puede manifestarse aquí.

2. Trae un dolor de cabeza cuando se integra con soluciones llave en mano

Cada lenguaje de programación respetuoso tiene una gran cantidad de soluciones preparadas. En C #, es, por ejemplo, Entity Framework y .Net. En Java, estos son Hibernate y Spring. Y casi todos los marcos están destinados a trabajar en nuestro estilo OOP habitual. Casi siempre, estas soluciones tienen estados variables y son completamente inadecuadas para trabajar con transiciones de fase puras.

Cualquier programador funcional de núcleo duro dirá que necesita tirar estas soluciones y trabajar sin ellas. Esta bien Vamos a averiguar como referencia lo que perderemos con tal decisión:

1. Casi siempre, tales decisiones dan como resultado un código repetitivo.
2. Estamos perdiendo una gran capa de funcionalidad. Por supuesto, podemos tomar una biblioteca preparada para trabajar en un paradigma funcional. Pero casi siempre esa solución es mucho menos popular, lo que significa que no puede ofrecer la mitad de todas las posibilidades de soluciones populares.
3. Los productos terminados que utilizan esta solución deberán ser refactorizados casi por completo.
4. Estamos perdiendo una solución bien probada y altamente determinista. En cambio, nos estamos moviendo hacia lo desconocido. ¿Hay algún problema en las soluciones populares? Por supuesto! Pero sobre ellos, como regla, todo se sabe desde hace mucho tiempo. En nuestro nuevo enfoque, esto definitivamente no sucederá.

De hecho, la lista continúa durante mucho tiempo. En mi opinión, la totalidad de las pérdidas hace que la FA, al menos, no esté en todas partes y no siempre sea adecuada.

3. Pasar tiempo en FA no siempre es prudente

Sin embargo, lo sorprendente es que a menudo los programadores no ven lo que hay detrás del código. No siempre un lenguaje de programación y un paradigma determinan la calidad de un producto. En la parte posterior, todo va a la contenedorización. Casi no importa lo que escriba: Python, Java, Scala. El código en cualquiera de estos idiomas puede incluirse en una imagen y entregarse como un contenedor.

En un mundo así, no es tan importante lo que hay dentro del contenedor si cumple con todos los requisitos establecidos. Aquí es más importante cómo está organizado todo el sistema. Surge la pregunta: ¿está realmente seguro de que debe invertir su tiempo en estudiar FP con su teoría de categorías? Puede valer la pena invertir en el desarrollo de la arquitectura general del sistema. Además, es mucho más fácil encontrar personas sin conocimiento de FP que estén listas para proporcionarle dichos contenedores.

Imagina esta situación. Te sientas por la noche y estudias toda la teoría. Miras videos en YouTube, lees libros, profundizas en cálculos matemáticos. Con el tiempo, ya puede crear una pequeña aplicación, pero no todo está claro. Empiezas a practicar más: toma libros más avanzados, ve a reuniones, conversa con colegas sobre lo alto. Pero entonces apareció un proyecto real. Con tu conocimiento, caes en un papel de liderazgo en este proyecto. La vida es buena! Y entonces escribiste el servicio perfecto. Solo queda un problema. ¿Qué hacer a continuación? ¿Cómo configurar el proceso de automatización? ¿Cómo configurar el equilibrio inteligente? ¿Cómo encontrar su otro servicio? ¡Es posible que simplemente no tenga una respuesta a estas preguntas! ¿Todavía estás seguro de que la FA es tan necesaria para ti?

Conclusiones

De hecho, tengo una actitud extremadamente positiva hacia la FA. Todo lo que quiero decir es una herramienta que está lejos de ser siempre y en todas partes. En mi opinión, un ingeniero no debe pensar en categorías como / aversión. En cambio, debería haber las razones más objetivas para usar esta o aquella solución.

Antes de estudiar / presentar un paradigma funcional, uno debe hacer al menos tres preguntas: la posibilidad de aplicar en su campo profesional, cuánto puede afectar cuando se integra con soluciones preparadas, y si el tiempo y los recursos gastados serán recompensados. Si no tiene un ataque de pánico por ninguno de estos problemas, puede ponerlo en servicio.

Gracias por su atencion!