¿Cuáles serían buenos argumentos de hecho para convencer a la gerencia de alto nivel de considerar la programación funcional? [cerrado]

15

Hay toneladas de argumentos "teóricos" sobre por qué la programación funcional es una buena idea (demasiados para que haya quedado como una pregunta abierta, y correctamente).

Sin embargo, la mayoría de ellos son argumentos elaborados desde la teoría ("elegancia", etc.) o dirigidos a los desarrolladores.

El problema es que la mayoría de ellos son completamente inútiles cuando el objetivo es presentar la idea a la alta gerencia de una gran empresa , algunos de los cuales ni siquiera son desarrolladores, y todos se preocupan principalmente por los argumentos comerciales : costos, gestión del capital humano , entrega de productos, servicio al cliente e ingresos; así como hechos cuantitativos sobre puntos teóricos que no pueden respaldarse con hechos.

¿Hay algún argumento convincente para presentar para abordar esas preocupaciones comerciales en cuanto a considerar la adopción de la programación funcional como un concepto (no un lenguaje específico), frente a la combinación típica de procedimientos / OOP, por ejemplo, Java / C ++ / (Perl | Python) .

Preferiblemente, estoy buscando argumentos cuantitativos y / o basados ​​en investigaciones o estudios de casos. Por ejemplo, "de acuerdo con esta referencia, la tasa de errores de los sistemas multiproceso en Lisp / F # es 10% superior a la de Java" u "80% de los mejores graduados que expresan preferencias de la tecnología deseada denominada programación funcional como uno de los 3 principales intereses".

Sé que Graham presentó casos de uso de programación funcional para un estancamiento y estaría abierto a algunos de sus argumentos, suponiendo que puedan ser válidos para una empresa establecida más grande.

ps Estoy perfectamente consciente de que puedes hacer algo parecido a la programación funcional en Perl, probablemente Python y (posiblemente) incluso Java 8 o C ++ 14. Pero eso no significa que una organización que usa Perl, C ++ o Java apruebe funcional vs OOP / enfoques procesales incluso en esos idiomas

Para los propósitos de este lenguaje, "grande" se define como lo suficientemente grande como para tener un grupo dedicado de ingeniería / herramientas de desarrollo, que dicta lo que todos los desarrolladores pueden usar / hacer; y al menos cientos de desarrolladores de gama baja .

DVK
fuente
1
¿Estás buscando este, supongo? paulgraham.com/avg.html En realidad, creo que el artículo está un poco desactualizado, entre muchos conceptos funcionales que han entrado en los idiomas principales.
Doc Brown
34
¿Por qué la gerencia de alto nivel se preocupa por los lenguajes y métodos de programación que se utilizan? ¿Por qué estarían involucrados en tal decisión? ¿Seguramente eso es asunto de los gerentes técnicos?
Alto rendimiento Mark
8
@HighPerformanceMark: sustituya a "gerentes técnicos" por "gestión de alto nivel" y evalúe la pregunta nuevamente.
Robert Harvey
2
¿En qué negocio estás? Si realiza consultoría y programación por contrato, la programación funcional puede ser una palabra de moda que la gerencia puede pensar que impresionará a sus clientes.
JeffO
3
¿Qué argumentos comerciales le dio la gerencia para los idiomas que usa actualmente?
JeffO

Respuestas:

7

Hay un argumento muy simple, que al menos podría divertir a la gerencia.

Es bien sabido que las computadoras modernas no se están volviendo "más rápidas" como solían ser, porque la escala de frecuencia, por ahora, llega al límite. Aumentan su productividad potencial al agregar núcleos.

Esto implica que para beneficiarse más de esta arquitectura, los programas tienen que estar en paralelo. Pero la programación paralela es mucho más difícil que la secuencial, debido a la gran cantidad de nuevos desafíos que conlleva (consulte el artículo de Wiki para obtener una descripción completa).

La programación funcional ayuda a deshacerse de algunos de estos desafíos, por ejemplo, las condiciones de carrera no se aplican si solo usa variables y métodos inmutables sin efectos secundarios. La curva de aprendizaje para la programación funcional es a menudo empinada, pero la curva de aprendizaje para la programación paralela puede ser aún más pronunciada y nada intuitiva.

Entonces, si el desafío es escribir programas más eficientes de una manera más eficiente, uno puede comparar los costos de capacitar a las personas para escribir programas paralelos con los costos de capacitar a las personas para que aprendan programación funcional, y los riesgos que ambos enfoques pueden traer.

Con respecto a los lenguajes mixtos (que admiten el estilo de programación funcional e imperativo): desde un punto, pueden ser útiles para la transición (las personas pueden comenzar a usarlos de forma "familiar" y aprender gradualmente nuevos enfoques). Desde otro punto, esto podría ser una bendición disfrazada, porque las ventajas potenciales que brinda la programación funcional podrían cancelarse con el código torpe de alguien. Se puede mitigar esto estableciendo pautas de codificación claras (ver, por ejemplo, " Escala efectiva " de Twitter), aunque seguir las pautas requiere un cierto nivel de madurez del equipo. Desde este punto de vista, los lenguajes funcionales puros podrían ser "más fáciles" para el desarrollo de software debido a las reglas más estrictas que imponen por diseño.

Ashalynd
fuente
Si puede encontrar investigaciones / pruebas reales de estas afirmaciones para respaldarlas, especialmente "Los lenguajes funcionales ayudan a deshacerse de algunos de estos desafíos", hasta ahora es la mejor respuesta disponible.
DVK
Esta misma pregunta ya se ha discutido varias veces, por ejemplo, quora.com/Why-does-functional-programming-favor-concurrency o stackoverflow.com/questions/474497/…
Ashalynd
3
Excepto que muchos lenguajes OOP también admiten programación funcional, por lo que puede usar los aspectos funcionales al tirar al bebé con el agua del baño.
Andy
1
Correcto, la pregunta era sobre "programación funcional", no sobre "lenguajes funcionales". Cambiará la redacción.
Ashalynd
40

Te estás acercando a esto desde el lado equivocado. En la mayoría de las empresas, la administración no es responsable de "elegir el paradigma de programación", son (o al menos deberían ser) responsables de hacer que el equipo funcione de manera eficiente. Si todo su equipo está convencido de que la programación funcional mejorará la velocidad o la calidad de su trabajo, tampoco debería ser demasiado difícil convencer a la gerencia. Además, si su equipo solo comienza a usar construcciones funcionales en sus lenguajes de programación establecidos, y todos están contentos con eso, ni siquiera debería tener que pedir un permiso (diablos, un no programador puede que ni siquiera entienda la diferencia entre construcciones funcionales y funcionales, entonces ¿por qué quieres discutir ese tema con él?).

Pero tenga cuidado, si el resto de su equipo tiene una opinión diferente sobre FP, y comienzan a quejarse del código funcional suyo que otros miembros del equipo no entienden, podría tener problemas con la administración, por una buena razón, ya que en tal caso, el equipo pierde eficiencia.

Entonces, la esencia es: convencer a otros miembros del equipo, o los líderes de su equipo, pero no a la gerencia de alto nivel.

EDITAR: debido a su comentario, en realidad, esta es una respuesta a su pregunta ;-). El único argumento fáctico del que estoy hablando es "todo el equipo piensa que FP es útil para hacer el trabajo . En mi humilde opinión, ese es el argumento con la mayor probabilidad de ser aceptado por la gerencia de alto nivel, y es muy práctico. Tratar de usar argumentos técnicos para las personas no técnicas, rara vez funciona directamente, no porque sean "demasiado tontos para entender el razonamiento técnico", sino porque son lo suficientemente inteligentes como para saber que las decisiones técnicas deben ser tomadas por expertos técnicos, y también son lo suficientemente inteligentes como para no confiar en opinión de un solo experto.

Doc Brown
fuente
77
Estoy sorprendido de que 19 personas hayan votado una respuesta que no responde la pregunta en absoluto . Es una pregunta práctica, en una situación práctica. Los miembros del equipo NO tienen voz y no necesitan ser convencidos. También no serán de trabajo - y tampoco lo hará que para el caso - no aprobado en la tecnología / idioma, como la cuestión hizo claro como el cristal.
DVK
1
@DVK si nadie más va a ver su código, entonces no necesita convencer a nadie más de que su idioma es bueno. Solo comienza a usarlo.
user253751
2
@DVK: debe proporcionar más información sobre cómo la administración controla los idiomas utilizados en su empresa. En la mayoría de los casos, la gerencia tiene poco aporte en esta área porque lo dejan en manos de los equipos y sus líderes.
JeffO
3
@DVK: las personas votan positivamente a las respuestas que encuentran más útiles para la pregunta en cuestión. Si la mayoría de las personas están votando respuestas que indican que se está acercando al problema incorrecto, entonces eso podría sugerir que un gran número de programadores han sido situaciones similares y encontraron útiles estas "no respuestas". La mayoría está de acuerdo en que hay algo fundamentalmente insalubre en su negocio, y no tiene nada que ver con las opciones de idioma. La mayoría está de acuerdo en que eso debe abordarse, cualquier intento de ir directamente después de la elección del idioma simplemente lo llevará al siguiente obstáculo, en lugar de una serie de soluciones.
Cort Ammon - Restablece a Mónica el
1
@CortAmmon Si bien estoy feliz de estar de acuerdo en que la pregunta indica algo mal con la forma en que se gestiona la empresa del autor de la pregunta, es muy poco probable que esté en condiciones de solucionar tales problemas. He visto de primera mano los problemas que puede causar un CTO obstinado (de hecho, solo ayer tuve que pasar mucho tiempo trabajando en un problema causado por una regla de que nuestra compañía no desplegará software fuera de los "archivos de programa" "directorios en máquinas Windows, pero Ruby no se instalará en un directorio con un espacio en su nombre.
Julio
16

Para comprender por qué la programación funcional no se ha apoderado del mundo, debe comprender el pensamiento corporativo detrás de las decisiones del lenguaje de programación. Para elegir Java por un momento:

  1. Hay ejércitos de programadores disponibles que pueden escribir resmas de código Java ordinario. Esto no es cierto para los programadores de Lisp o Haskell (o incluso Scala).
  2. Todos los demás están usando Java, por lo que debe ser bueno. Corrolary: los gerentes no tienen que justificar su elección de Java versus algún lenguaje oscuro del que nadie en la estructura de comandos haya oído hablar.

Si su organización ya está atrincherada en el Reino de los sustantivos , simplemente no va a suceder un cambio general en la programación funcional. La elección del idioma (y todas las demás opciones que la rodean) ya está profundamente arraigada en la cultura corporativa.

Asumiendo que su objetivo es crecer como desarrollador de software, su mejor apuesta es

  1. Incorpore conceptos funcionales en sus programas existentes donde sean útiles y apropiados,
  2. Use nuevas funciones de lenguaje funcional a medida que se agregan al idioma, y
  3. Aprenda patrones de diseño orientado a objetos, algunos de los cuales existen para superar las deficiencias del lenguaje en los lenguajes OO que no están presentes en los lenguajes funcionales.

Los argumentos de Paul Graham realmente solo se aplican a las nuevas empresas, y ha habido una serie de historias de advertencia de compañías que comenzaron a usar lenguajes puramente funcionales, pero luego fueron compradas por otra compañía cuyo primer negocio fue convertir inmediatamente la base de código funcional a un lenguaje OO para que sus desarrolladores de software existentes puedan entenderlo.

Robert Harvey
fuente
1
No, mi objetivo NO es (a los efectos de esta pregunta) "crecer como desarrollador de software". Mi objetivo es recopilar el mejor conjunto de argumentos para presentar a las personas que toman decisiones, que los influiría para permitir la PF como enfoque aprobado. Nada más y nada menos. Destaque los beneficios de FP, especialmente en comparación con la pila de procedimientos / OOP estándar.
DVK
Además, a menos que haya cometido un error de redacción importante, la pregunta definitivamente no significaba aludir al "cambio general" como resultado previsto de los argumentos que se buscan.
DVK
+1 para el Reino de los sustantivos. Lo he estado llamando "La guerra entre sustantivos y verbos".
Rob
44
@DVK: La forma de convencer a la gerencia de cualquier cosa ha sido la misma desde que comenzó el tiempo: muéstreles cómo les ahorrará dinero.
Robert Harvey
9

En mi experiencia (algo cínica), haber trabajado para una tienda donde usamos programación funcional y entrevistado en varios otros:

  1. Siempre hubo un CTO y otras personas técnicas de alto nivel que tenían experiencia con la programación funcional y lograron convencer a los ejecutivos no técnicos de ella. (Y por cierto, estas personas están mejor calificadas para responder a su pregunta que yo).
  2. Una vez que estas personas abandonen la empresa y sean reemplazadas por personas que no tienen esta inclinación, las cosas se irán al sur. Los nuevos muchachos echarán la culpa de todo lo que sale mal (incluidos, y particularmente sus propias fallas) al extraño lenguaje de programación y paradigma utilizado para construir lo que vino antes. Marginarán a las personas restantes con habilidades de programación funcional, expulsándolos de la empresa. El sistema construido en el lenguaje funcional se deteriorará sin mantenimiento. Este tipo de cosas, en mi opinión, es el mayor riesgo que una empresa asume si adopta un lenguaje funcional y no debe subestimarse.
  3. La organización debe tener una cultura de "construir en lugar de comprar" para que esto funcione. Porque adoptar un lenguaje funcional significará menos opciones de "compra".
  4. Casi siempre hubo algún compromiso con los detractores técnicos y no técnicos de la idea. El más común de estos compromisos es que cualquier lenguaje que no sea JVM fue simplemente fuera de consideración; Se propusieron Clojure y Scala, Haskell y O'Caml salieron de la nada.
sacundim
fuente
4

Cosas a tener en cuenta para la alta gerencia cuando / si la alta gerencia está involucrada en la selección de lenguajes de programación (lo cual es extraño, deberían dejarlo en manos de personas confiables y conocedoras (tanto en tecnología como en negocios):

  • Productividad
    • Empleados actuales y futuros
    • Todos los roles (arquitectos, desarrolladores, probadores, OP, ...)
  • Plataformas soportadas
    • Sistemas operativos (hardware)
  • Editor del lenguaje / plataforma
    • Licencias
  • Madurez del lenguaje / plataforma
    • Apoyo de / por el editor y / o comunidad
    • Bibliotecas
  • Migrar la base del código actual
    • O integración con

Tenga en cuenta que estos no son específicos de los lenguajes de programación funcionales. Estos tampoco son argumentos a menos que proporcione datos con estos. No podemos proporcionarle los datos, ya que dependen completamente del entorno de su empresa. Lo único que podríamos hacer es recopilar datos de la web para mostrar cuánto conocimiento e interés hay para un idioma específico. Tenga cuidado al traducir muchas preguntas en StackOverflow o muchas etiquetas en Linkedin a un idioma que sea popular.

Erno
fuente
1
Las empresas también están preocupadas por la contratación de personas, por lo que si es más difícil reemplazar un desarrollador funcional, diría que es una buena razón para que se involucren en tales decisiones.
Andy
1
@Andy - Sí, es por eso que no estoy refutando la pregunta y creo que los gerentes deberían estar interesados ​​en los temas que mencioné. Mi preocupación es más o menos que la solución (Lenguajes de programación funcionales) se elija ANTES de definir el problema (???).
Erno
¿Es realmente tan difícil reemplazar a un desarrollador funcional? Por la cantidad de desarrolladores informados que publican aquí y en otros sitios en Internet, sospecho que hay desarrolladores mucho más funcionales de lo que piensan los gerentes.
Giorgio
@Giorgio: nunca dije que era difícil reemplazarlos, pero creo que la disponibilidad puede variar de un lugar a otro. Algunos graduados universitarios nunca aprendieron lo básico, mientras que algunas universidades se especializan en ellos. Para una empresa, es muy importante tener en cuenta el largo plazo y la necesidad esperada de nuevas contrataciones.
Erno
@Erno: estoy de acuerdo con tu opinión. Estaba comentando el comentario de Andy. De todos modos, siempre he asumido que hay muy pocos programadores funcionales y que FP se ve como algo esotérico. Últimamente, mi impresión es más bien que hay muchos más desarrolladores de FP que trabajos de FP.
Giorgio
3

No creo que los argumentos o los hechos ayuden. Y ciertamente no sin mencionar los problemas que desea resolver.

Contra la creencia común y la autoevaluación típica, muchas decisiones se toman en base a la intuición. Y a menudo estas decisiones son muy buenas, porque incorporan en un nivel subconsciente mucha experiencia del individuo que toma la decisión.

Si desea impugnar una decisión como "Nos apegaremos al lenguaje similar a C hasta el final de todas las computadoras", debe hacer algo más que proporcionar algunos argumentos.

Probablemente, el primer paso sea descubrir a las personas y las razones detrás de la decisión de que la alta gerencia debería tener algo que decir en esas decisiones técnicas. Por supuesto, solo puedo adivinar aquí, pero es muy probable que tengan un historial de decisiones tomadas por personal técnico que salió mal. Seamos realistas: la mayoría de los desarrolladores no son muy buenos para tomar decisiones (incluso técnicas) a nivel de empresa.

Una vez que haya encontrado a estas personas, hable con ellas para ganar confianza. Posiblemente el mejor enfoque es: escucharlos. De qué están preocupados, cuáles son los riesgos y las posibilidades que ven. ¿Cuáles son los problemas que enfrentan? A partir de aquí, puede avanzar para involucrar a la gente de tecnología en este tipo de decisión. La administración a menudo no quiere realmente tomar estas decisiones, pero no confía en otros con ella. Entonces, si su equipo comienza a involucrarse en la decisión arquitectónica y demuestra que las decisiones que propone son una buena gestión, podría estar dispuesto a confiar en usted / su equipo.

Importante para llegar a decisiones arquitectónicas sólidas es:

  • Recopilar aportes de los interesados ​​(Gestión, Usuarios, Administradores, Ventas, Clientes ...)
  • Basar las decisiones en esa entrada
  • Comuníquese claramente: cuáles son las decisiones (propuestas); Qué riesgo pretenden mitigar; Qué intereses en conflicto son y con cierta demora: qué tan bien funcionaron.

Si trabaja para una gran empresa con más de 10 000 empleados, prepárese para aprender algunas de las siguientes lecciones.

  • la velocidad de codificación no es realmente relevante para el resultado final.
  • cosas como la mantenibilidad en la escala de décadas es.
  • Los problemas que cree que puede resolver utilizando lenguajes funcionales no son realmente relevantes para el resultado final
  • problemas como la capacitación de 1000 desarrolladores, la resistencia natural al cambio y el mantenimiento de una base de código escrita por desarrolladores con menos de 5 años de experiencia en la tecnología utilizada son.

Una vez que haya alcanzado un nivel de confianza para que sus argumentos sean escuchados y considerados, también habrá establecido una forma de reunir y considerar los requisitos en los que usted, su equipo y la gerencia confían.

Si este proceso produce la recomendación de utilizar un enfoque funcional en ciertas áreas que haya terminado.

Si este proceso produce la recomendación de ignorar los enfoques funcionales que van más allá de lo que el lenguaje de programación principal actual le ofrece, también habrá terminado.

La mala noticia es: dependiendo del tamaño y el estilo de la empresa, esto podría llevar fácilmente un par de años o décadas.

La buena noticia es: aprenderás mucho en el camino.

Dado que el primer paso es comenzar a hablar y especialmente a escuchar a la alta gerencia, recomendaría comenzar con la lectura de Just Listen .

Jens Schauder
fuente
3

Un buen enfoque sería demostrar que se muestran buenos resultados en la industria y se adoptan.

Puede obtener algunos datos de:

Idealmente, trate de hablar con los gerentes de algunas empresas que cotizan en bolsa, especialmente si están en su industria, y obtenga números y testimonios de ellos.

Google tiene muchos otros enlaces similares para Haskell, OCaml, etc.

LispGood
fuente
3
Algunas compañías verán esto como un caso en contra, ya que los practicantes de OO superan en número a los adherentes a la PF por un amplio margen .
Robert Harvey
1
@RobertHarvey: ese es un argumento de arenque rojo, al menos en mi caso específico. Ya son lo suficientemente inteligentes como para saber ESO. Lo que NO saben (y lo que descubrí de esta respuesta) es que Eaton Vance usa Scheme y, lo que es más importante, Faceboook , BoA / ML, Deutsche Bank y Google [usa Haskell]. Es decir, es algo que PUEDEN considerar sumergir un dedo del pie, ya que otros dignos decidieron hacerlo. Es sorprendente que la única respuesta realmente útil que trató de abordar la pregunta que hice (y no la que la gente quería responder) es la que tiene menos votos
DVK
1
@dvk: La pregunta que hizo (si lo entiendo correctamente) es "¿Cómo puedo convencer a mis jefes de que FP es algo bueno?" Bueno, a veces no lo es. Vivimos en un mundo mutable, y la programación funcional es, honestamente, un poco raro. Si no me crees, mira las mónadas. Las respuestas que abordan estas rarezas (y cómo afectan el diseño del software y el proceso de desarrollo) son útiles, lo creas o no.
Robert Harvey
@RobertHarvey (1) Retiro eso. Ahora DOS de las respuestas útiles son las más votadas :) (la nueva que acaba de publicarse podría mejorarse con hechos, pero es un buen comienzo).
DVK
@RobertHarvey: sí. La pregunta NO era "¿La FP es algo bueno" o "¿Es posible convencer a la gente de que la FP es algo bueno"? La pregunta era muy precisa: "¿Qué argumentos se pueden utilizar para apoyar CUANDO se trata de convencer de que es algo bueno"? Tampoco fue "¿Cómo puedo introducir sigilosamente FP en mi trabajo / codificación de manera positiva?", Que es lo que respondió: si esa fuera una opción que no estaría preguntando en primer lugar, estaría codificando: )
DVK
2

Vienes a esto desde la dirección equivocada.

Estás tratando de convencer a la administración de un cambio a un paradigma funcional para tu propio entretenimiento y estás tratando de generar argumentos para apoyar esto que no tienen nada que ver con la verdadera razón por la que lo quieres. De lo contrario, no necesitaría hacer la pregunta, porque podría enumerar sus argumentos desde la parte superior de su cabeza.

Más bien, en lo que debería estar pensando es en qué necesita el negocio actual y cómo se sirve mejor. Si sucede que se sirve mejor usando un paradigma funcional, entonces, ¡sí! - Puedes jugar. Pero si realiza un análisis justo, teniendo en cuenta las necesidades comerciales operativas, la capacitación necesaria de los compañeros de trabajo, los antecedentes de futuros programadores, el mantenimiento, etc., a menudo no lo será.

Cobarde anónimo
fuente
2
Esto es un poco pedante, y no es demasiado útil para responder la pregunta, que debe ser abstraída de solo ayudar a OP en su "enfoque".
VF1
1

La alta gerencia sin habilidades técnicas no debería preocuparse por aspectos técnicos como el uso de paradigmas funcionales. Este no es su dominio de experiencia, y huele a microgestión. ¿Por qué no están delegando esas decisiones a personas que realmente tienen las habilidades requeridas?

Dicho esto, aquí hay algunos consejos para convencer a las personas con antecedentes técnicos (primer caso) y aquellos sin uno (segundo caso).

Primer caso

Si está hablando con personas que conocen la programación , comparar código escrito sin paradigmas de programación funcional y el mismo código escrito en estilo funcional puede ser lo suficientemente convincente:

Ejemplo de código C # que usa un estilo imperativo:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

El mismo código reescrito con la programación funcional en mente:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Luego pregúntales:

  1. ¿Cuántos errores puede cometer un programador en la primera muestra? ¿Qué hay del segundo?

  2. ¿Qué tan difícil es detectar errores?

  3. ¿Qué tan difícil es modificar el código?

Los tres factores influyen en la productividad y, por lo tanto, en el costo del producto.

Segundo caso

Si se trata de personas que no conocen la programación, no hay muchas cosas técnicas que pueda decirles. Una de las formas de convencer es mostrar el impacto real de los paradigmas funcionales en su trabajo y el trabajo de sus compañeros de trabajo.

Por ejemplo, compare dos proyectos realizados por el mismo equipo, uno con FP y otro sin usarlo. Mostrar que la cantidad de errores es mucho menor o que este fue el primer proyecto que la compañía entregó a tiempo debería ser lo suficientemente convincente.

Arseni Mourzenko
fuente
3
Veo lo que has hecho allí, pero tu ejemplo no es del todo convincente. Básicamente, ha desenrollado su ejemplo funcional en uno imperativo, que no es algo que sucedería en ninguna empresa práctica. Tu yield returnes un poco tramposo, ya que es un ejemplo de cómo prepararías el código para usarlo en un escenario de Linq de todos modos, y tus ifdeclaraciones podrían escribirse de manera más sucinta con operadores ternarios. Todo su primer ejemplo podría refactorizarse en funciones imperativas, de modo que la complejidad esté oculta.
Robert Harvey
@RobertHarvey Podría refactorizar el primer ejemplo en un grupo de funciones imperativas, pero serían funciones imperativas personalizadas que son específicas de esa consulta; aún tendría que verlo todo para convencerse de que la consulta es correcta. Esa refactorización aumentaría aún más el tamaño del código imperativo. Incluso si pudiera escribirlo de la misma manera compacta, todavía tiene que leer el código cuidadosamente porque todo el trabajo se está haciendo a través de los efectos secundarios; no querrá perderse un efecto secundario que se realiza en la segunda parte de un operador ternario al final de una línea.
Doval
1
@RobertHarvey Ni siquiera estoy seguro de que los dos fragmentos de código sean equivalentes, ya que el imperativo "filtra" creando una segunda lista en lugar de simplemente omitir la iteración. ¿El equivalente real no usaría solo un bucle y, por lo tanto, estaría aún más anidado?
Doval
55
No hay duda de que es un buen caso para incorporar conceptos funcionales en un lenguaje imperativo / OO, pero no necesariamente un buen caso para usar lenguajes totalmente funcionales en un entorno corporativo que ya es imperativo / OO.
Robert Harvey
Otro problema (quizás menos válido) con su ejemplo: podría escribir el primer ejemplo en Perl totalmente legible en su mayoría que no sea FP en, supongo, el 30% del volumen. Tal vez menos. Depende de si acepta map/ grepcomo no FP. IOW, estás presentando argumentos de que Java es un mal lenguaje, no que FP es un buen enfoque.
DVK