¿Cómo presentar a su equipo el estilo funcional de codificación?

Tengo una situación en la que la mayoría de las personas de mi grupo provienen de un entorno de programación orientado a objetos con poca o ninguna comprensión de la programación funcional. Ni siquiera lo básico como los cierres.

¿Alguna sugerencia sobre cuál podría ser una buena manera de presentarles el estilo de codificación funcional? Una gran cantidad de codificación que hacemos puede acortarse si hacemos la forma funcional para nuestros casos específicos.

Ya he dado un par de presentaciones sobre paradigmas funcionales y de codificación. Desafortunadamente, no usamos un lenguaje de programación funcional adecuado como Haskell (básicamente el código heredado está en C, C ++, Java), por lo que tenemos que hacer lo que sea necesario con estos.

Luca Bolognese hizo esta presentación fantástica donde presenta la programación funcional (para presentar F #) usando un ejemplo de café que es realmente genial y me ayudó mucho a presentar la Programación Funcional a amigos y colegas.

También puede buscar una programación funcional del mundo real de Petricek, que es una excelente manera de comenzar a pensar funcionalmente en mi opinión.

¿Sus colegas codifican fuera del trabajo?

Teniendo en cuenta que no realiza ningún FP en su empresa, hacer que cualquiera aprenda un nuevo lenguaje / paradigma cuando no hace nada fuera de sus tareas de trabajo directo será casi imposible.

Si lo hacen, busque proyectos interesantes que les gusten y que estén relacionados con la programación funcional y muéstrenlos. No está en condiciones de exigir un cambio, por lo que tendrá que sembrar las semillas si le interesa a nivel personal. Así es como me lo presentaron, concedido, por mi mejor amigo que trabaja conmigo.

Fuera de eso, la mayoría de las personas escriben herramientas internas para facilitar las tareas pequeñas. Intenta escribir algunos de ellos en un lenguaje funcional. Cualquiera que quiera ver el código estará expuesto a la belleza (con suerte / posiblemente) del código y probablemente le preguntará al respecto cuando lo haga. Esa es una oportunidad para vender la idea.

Recuerde, hay lenguajes funcionales que funcionarán en su pila (scala / cierre ambos se ejecutan en la JVM). No es "puramente funcional" como lo es Haskell, pero es un buen comienzo en un largo viaje.

Si tiene algún control sobre la contratación, contrate personas que tengan alguna experiencia funcional (o que al menos estén interesadas en la programación funcional).

Y finalmente ... podría estar en la compañía equivocada si le apasiona escribir código funcional. No va a cambiar la forma en que toda su empresa escribe software, especialmente si están ganando dinero y, aún más, no en un período de tiempo razonablemente corto.

Esto se trata de venderlo a los desarrolladores ... la administración es una bestia completamente diferente.

Cambiar de la programación funcional imperativa a la pura es un gran cambio con una curva de aprendizaje empinada. Sugeriría intentar una transición menos rápida, y en ese caso tiene muchas opciones. Por ejemplo, Python admite comprensiones de listas y expresiones generadoras , Ruby admite funciones de orden superior a través de bloques de código, etc. Dado que mencionó Java, si todos ustedes tienen un fondo de Java y desean soporte de programación funcional completo, pueden probar Scala .

Contrata (o consigue que el jefe contrate) un programador funcional

Eventualmente, esto no se contagiará al resto de su equipo.

Además, como se dijo antes, alentarlos a escribir código en un lenguaje funcional durante su tiempo libre tampoco estaría de más.

Si la programación funcional realmente va a hacer la vida mucho más fácil en sus casos, entonces sugiero aislar uno de esos casos y demostrar implementaciones equivalentes tanto en OO como en lenguajes funcionales a sus colegas.

Si la diferencia en complejidad es tan amplia como usted dice, entonces esto debería hablar por sí mismo.

+1 a faif por mencionar a Scala: esto comenzó como un comentario sobre esa respuesta pero se hizo demasiado grande ...

Quería aprender algo sobre programación funcional (proveniente de C / C ++, algunos Python y Java oxidado); Traté de sumergirme en el fondo con Ocaml y luego Haskell y Just Didn't Get It. Luego probé Scala y descubrí que me permitía comenzar a usar cosas funcionales en un entorno cómodo de OOP / Java-ey donde podía recurrir fácilmente al estilo imperativo familiar cuando un enfoque funcional me eludía. Algunos pueden quejarse de la naturaleza "multiparadigma", "híbrido" del lenguaje, lo que significa que nunca estás obligado a estirarte para ser "puramente funcional", pero diría que significa que puedes ser pragmático sobre las cosas y saber que ser capaz de hacer cosas reales fácilmente de alguna manera cuando lo necesite.

Un par de años después (y más de 200 soluciones de Project Euler Scala en Scala más adelante) el encuentro con lo funcional definitivamente ha influido en mi Python (mucho más uso de mapa, filtro, reducción, lambdas, itertools, listas de comprensión y funciones de transferencia). nunca antes había contemplado) y, en menor medida, C ++: tal vez un poco más de intento de usar los adornos funcionales de STL, pero el impacto principal es que estoy mucho más cómodo usando el mapa de TBB / reducir construcciones y realmente me gusta cómo explotar la inmutabilidad puede dominar la complejidad en código multiproceso.

Entonces, personalmente, si fuera usted, estaría defendiendo la introducción de Scala en algunos de sus desarrollos en el mundo de Java, preferiblemente mostrando algunos ejemplos de que simplifica enormemente algo y produce los beneficios que reclama. Lo que sucede a continuación se reduce a todo el asunto de "defender" nuevas ideas e impulsar el cambio ... lo que parece que puede ser un problema mucho mayor.

Me gustaría recomendar un enfoque gradual usando Scala. Y recomendaría comenzar con el libro del creador de Scala, "Programación en Scala, 2ª edición" . Este libro es FANTÁSTICO al introducir lentamente una programación funcional (FP) usando Scala. Y al mostrar el movimiento hacia FP, no rechaza OO. De hecho, lo aprovecha. Estoy haciendo mi segundo paso ahora.

Básicamente, Scala le permite a uno hacer Java / OO "sin punto y coma". Y luego uno puede probar un poco de FP sin tener que ir por completo. Por ejemplo, al entrenarme para hacer FP, normalmente me enfocaré en la transparencia referencial en el nivel de método de la clase, pero dejaré que mis métodos tengan tantas var-s, mutabilidad e imperativo como sea necesario para hacer un primer paso en Una implementación. Luego, me concentro en reelaborar lentamente cada método para moverlo hacia FP puro. Y también uso el sitio hermano de StackOverflow, CodeReview, para obtener ayuda con mi transición mental / mental. Aquí hay un ejemplo de una publicación reciente que hice haciendo esto mismo.

De todos modos, la mejor de las suertes en su viaje FP. :)