No, este no es otro intento de explicar las mónadas. No sé cómo hacer esto y no puedo imaginar cómo, por ejemplo, desde el presente, podría explicarme esto desde el pasado.
Lo mismo se aplica a otros conceptos de FP. Entiendo su valor, cómo usarlos. Pero no sé cómo transmitir esto a las personas que inicialmente se inclinan negativamente hacia un enfoque funcional. No creo que esto sea posible en absoluto. La práctica resuelve fácilmente este asunto, pero las personas rara vez lo alcanzan.
Ni siquiera sé cómo responder preguntas más simples. A pesar de que he estado escribiendo en Scala durante más de 3 años, no puedo explicar con los dedos las ventajas del lenguaje para una persona de afuera. Por ejemplo, hace un par de meses tuve una buena discusión.
Todo comenzó con la pregunta:
"¿Y para quién está escrito su idioma?" .
Toda esta inmunidad, funciones de orden superior, un gran sistema de tipos, efectos secundarios y otras mónadas giraban en mi cabeza, pero entendí que esto no era todo eso. La aclaración posterior finalmente me envió un golpe de gracia:
"Aquí, por ejemplo, Java es un lenguaje para trabajadores de cuello blanco" . Ese diálogo terminó con algunas tonterías incoherentes sobre la incapacidad de explicar la diferencia sin práctica.
No sabemos cómo vender FP
Esto no es solo un recuento de la experiencia personal. Todos nosotros, usuarios de lenguajes funcionales, estamos aproximadamente en la misma situación. Entendemos perfectamente la gran diferencia en comparación con los idiomas de
Blub , pero el resto del mundo no quiere escucharnos. Por supuesto, uno puede estar enojado con los conservadores limitados que anuncian "G", llevan tonterías con calma, se vuelven a contar mitos y cuentos de hadas, y firmes y con confianza en discusiones sobre cosas en las que ni siquiera pasaron un par de horas. También puede culpar a las grandes corporaciones con sus equipos de vendedores.
Pero me parece, en primer lugar, que el problema es que nosotros mismos no sabemos cómo vender FP. Sí, esta no es una tarea fácil. Sin embargo, cuando recuerdo cómo las personas toman decisiones, cómo y qué cosas se incluyen en las tendencias, empiezo a pensar que esto es posible.
Siempre hay algo mal con el desarrollo.
- ¡Los procesos son lentos! Y ahora, después de unos años, todas las mañanas, en todas las oficinas del país, la gente que está parada en la pizarra arrastra las etiquetas de una columna a otra.
- ¡La implementación es lenta! Y armados con valores devops, hacemos 10 lanzamientos al día, mientras que una nueva generación de administradores lo inunda con toneladas de rubí, python y yaml.
- Las aplicaciones son complicadas! Y así, equipos de 2-3 desarrolladores están construyendo una nueva arquitectura de microservicios, pensando en las responsabilidades de cada servicio en detalle y haciendo 10 solicitudes de pool para una pequeña revisión.
No es que considere todas estas manías de la industria como malas. También tienen muchos defectos también. Y no todos sabían cómo o cómo cocinarlos correctamente. Falta o falta una sintonización conveniente. Sin embargo, estos enfoques se han convertido en un estándar "de facto" para la industria. Y aunque la discusión sobre Docker en producción para algunos parece una pregunta abierta, todo ya ha sucedido.
Estoy seguro de que lo mismo puede suceder con los lenguajes funcionales. Sí, esto no es del todo correcto: comparar lenguajes de programación con metodologías y enfoques. Pero tenemos algo que pedir prestado en su posicionamiento para nosotros mismos. Todos ellos tienen un
problema estrictamente definido que resuelven. Y esto es velocidad: desarrollo, comunicaciones, planificación, implementación, hacer cambios ...
¿Por qué nos olvidamos de decir lo más importante?
Al mismo tiempo, desde el punto de vista del posicionamiento de los lenguajes de programación funcionales, es difícil decir que tienen un objetivo claro y comprensible. Los académicos lingüísticos "
FP vs OOP " generalmente se deslizan rápidamente en una medida de características y conceptos cuyo valor no es bien entendido por el campo de OOP. Los artículos y los informes del formato "
Mire cómo estas mónadas están magníficamente compuestas " a menudo refuerzan en las personas la opinión de que no necesitan esto, de lo que se inspiran para intentarlo. Todas estas interacciones rara vez responden a la pregunta "
¿Por qué es todo esto? " Hermosa y concisa? Bueno, en el mejor de los casos, se mencionarán menos errores.
¡Lo más importante en el uso de lenguajes funcionales es la misma velocidad de desarrollo! Y esta velocidad se logra con todos estos términos, conceptos y propiedades aburridos y aterradores que emergen de ellos. Composición más ligera debido a las funciones de orden superior, además de la velocidad de desarrollo. La inmunidad, además de la confiabilidad y menos errores, es equivalente a dar más tiempo para cosas útiles, en lugar de gastarlo en depuración, revisiones y soporte. Bueno, etc., creo que la lógica es clara.
Sí, eso suena demasiado simple e incluso obvio.
Sí, no dije nada nuevo aquí. Pero la importancia de la redacción y el énfasis es importante. Desafortunadamente, así es como funciona nuestro pensamiento. Para romper las barreras, las explicaciones por sí solas no son suficientes. Necesito práctica! Es necesario que una persona o empresa quiera pasar tiempo en esto. Las referencias a la "academia" o la belleza relativa inspirarán a pocos a pasar varios días sintiéndose como un idiota.
Vale la pena dejar de desarrollarse como sabios, esparciendo inmediatamente los términos a izquierda y derecha, demostrando la superioridad de su YP favorito sobre
Blub . En lugar de probar la utilidad de la característica X, es mucho más fácil usarla como explicación de alguna propiedad más comprensible. Si otros técnicos han tenido éxito, tal vez sea hora de que asumamos también la responsabilidad y que entremos firmemente con cosas obvias y simples.
Entonces, la próxima vez, con las dificultades de responder la pregunta “
¿Por qué? ”, No dude en ir con cartas de triunfo, tales como:
mayor velocidad de desarrollo ,
soporte más barato ,
menos desarrolladores .
Ah y más. ¡Los eventos comunitarios también juegan un papel importante en el posicionamiento!
Por lo tanto, estamos esperando a todos los que no son indiferentes a FP en la única conferencia funcional en Rusia - FPURE - Kazan - 24-25 de mayo .
El programa incluye: Haskell, Scala, Elixir, Clojure, teoría y práctica, y, por supuesto, ¡muchas personas de ideas afines con las que hay algo de qué hablar!