¿Los lenguajes de programación funcional se entienden mejor y es más probable que los usen personas con conocimientos de matemáticas?

Todos los lenguajes de programación son mejor entendidos por personas con experiencia en matemáticas.

Muchas personas que usan la programación funcional tienen esos antecedentes, por lo que a menudo usan términos matemáticos para hablar sobre ello. Esto puede dar a la gente la impresión de que esa es la única forma de hablar (y pensar) al respecto. Escucho mucho de personas que no saben mucho sobre FP, particularmente aquellos que quieren una excusa para no saber más.

Sí, esa percepción es una de las razones por las que hay proporcionalmente más personas matemáticamente calificadas que usan FP. Es un estereotipo autosuficiente. Los estereotipos sostienen divisiones sociales irracionales incluso en la programación.

No he estudiado matemáticas desde que tenía 18 años. Cuando hablo (o pienso) sobre FP, hablo sobre separación de preocupaciones, composición de funciones, diferentes tipos de polimorfismo, genéricos, reutilización de códigos. evaluación perezosa, inmutabilidad … ninguno de los cuales necesita una perspectiva matemática para discutir o considerar. Es interesante saber que el concepto de una función pura tiene un análogo matemático, pero eso en realidad no hace ninguna diferencia para mí.

Es más fácil entender las abstracciones de programación funcional si tienes un conocimiento matemático, pero déjame referirte a mi primer párrafo. Eso es cierto para todas las abstracciones informáticas.

El conocimiento matemático es más productivo cuando se razona sobre abstracciones de programación funcional. porque tienen una base matemática sólida. Soy más productivo al razonar sobre abstracciones de programación funcional. Los principios que aprendo sobre una abstracción son útiles para comprender a los demás (porque se reutilizan).

La programación funcional requiere que pienses en la abstracción. En la programación imperativa, es un extra opcional. Serás un mejor programador imperativo si piensas en la abstracción pero puedes escapar sin ella. No serás un programador funcional productivo si no piensas en la abstracción.

Si es posible salirse con la suya sin hacer algo, mucha gente elegirá ese camino. El resultado tiende a ser que el camino solo es recorrido por personas que tienen interés en lo que otras personas están evitando. Los matemáticos están naturalmente interesados ​​en esta cosa en particular.

Los matemáticos pueden pensar en la abstracción: no serían buenos para las matemáticas si no pudieran. Pero no es una habilidad exclusiva de ellos. ¿Puedes pensar en abstracciones? Si puede, la falta de antecedentes matemáticos no es una barrera para la programación funcional.

tl; dr

1. Si.
2. Si.
3. Otras personas aún pueden entender la PF y usarla.
4. Los mitos y los estereotipos a menudo son autosuficientes
5. FP es más abstracto. A los matemáticos les gustan las abstracciones. A los osos les gusta cagar en el bosque.

Richard Bird (Richard Bird (informático) – Wikipedia) escribe

Si bien ahora hay numerosos libros, tutoriales, artículos y blogs dedicados a Haskell, pocos enfatizan lo que me parece la razón principal por la que la programación funcional es lo mejor desde el pan en rodajas: la capacidad de pensar matemáticamente sobre programas funcionales. Y las matemáticas involucradas no son nuevas ni difíciles …

Si el mensaje del último párrafo lo apaga, si está huyendo perpetuamente del Mordor de Matemáticas, entonces el presente libro probablemente no sea para usted. Probablemente, pero no necesariamente (a nadie le gusta perder clientes). Todavía hay placer en aprender una forma novedosa y emocionante de escribir programas. Incluso los programadores que por una razón u otra no usan o no pueden usar Haskell en su trabajo diario …

Creo que eso lo resume bastante bien.

Tipo de datos Haskell para un árbol binario:
data Tree = Empty | Node Tree Tree

Y la serie generadora que los enumera
[matemáticas] T (x) = 1 + xT (x) ^ 2 [/ matemáticas]

Si reemplaza el 1 con Empty, + con |, x con Node y T (x) con Tree, tiene una traducción muy natural de este cálculo matemático al código Haskell y viceversa. Es probable que alguien que ha enumerado los árboles de esa manera asimile Haskell más fácilmente que alguien cuya idea de un árbol se parezca a:

  typedef struct tree {
	 árbol de estructura * l, * r;
 } árbol;

Claro, es similar, pero no existe este concepto de vacío o en la definición.

En primer lugar, hay niveles en matemáticas. El cálculo de Lambda es una matemática teórica en la que puede leer y comprender sin conocer con fluidez su horario. Las matemáticas más altas tienen más que ver con conceptos y abstracciones que con operaciones numéricas.

En segundo lugar, he visto a muchas personas matemáticas / científicas que tienden a seguir con C, Python y R. La programación funcional es muy específica para el cálculo lambda y la lógica combinatoria inspirada en el trabajo de Alonzo Church y Haskell Curry (y muchos más). La mayoría de las personas con experiencia en matemáticas nunca han aprendido estos temas de alto nivel.

Creo que si el mundo no hubiera visto los gustos de Java y, en cambio, se popularizó un lenguaje funcional como Lisp, Haskell u Ocaml, habría sido mucho más fácil para las personas entender la PF. Muchas estructuras de datos complejas se pueden expresar con delicadeza, elegancia y brevedad en un FP, mientras que son realmente verbosas y torpes en una contraparte imperativa.

Hay dos preguntas, y tal vez una tercera relacionada que está implícita.

1) ¿Los lenguajes de programación funcional son mejor entendidos por las personas con conocimientos de matemáticas que las personas que no?
La respuesta es ambas, si y no. Esas personas las entienden mejor en la misma medida en que esas personas entienden mejor los lenguajes de programación no funcionales.
En otras palabras, los idiomas en sí no se entienden mejor, pero las relaciones entre el lenguaje y las matemáticas, obviamente, se entienden mejor.
Esto es como preguntar si C es mejor entendido por personas que ya conocen el ensamblaje. El lenguaje en sí no. Pero las implicaciones reales de algunas construcciones de lenguaje y optimizaciones para la plataforma de hardware específica para la que está programando se entenderían mejor si conociera la arquitectura de ensamblaje y hardware de la máquina.

2) ¿Los lenguajes de programación funcional tienen más probabilidades de ser utilizados por personas con conocimientos matemáticos que por personas que no los tienen?
La respuesta es nuevamente sí y no. Depende de si esas personas simplemente tienen antecedentes matemáticos o si realmente están haciendo una investigación matemática (y si es así, qué tipo de investigación). Las personas que conocen y entienden lenguajes funcionales eventualmente los usarán si es posible, independientemente de sus antecedentes matemáticos. Algunos (pero no todos) los problemas matemáticos se resuelven mejor usando esos lenguajes, por lo tanto, algunos matemáticos que realizan investigaciones matemáticas pueden usarlos con más frecuencia que otros programadores.
En el mundo de C y ensamblador, algunas personas que conocen al ensamblador tienen más probabilidades de usar C, pero no todos. Depende de lo que estén haciendo. Es probable que un programador web que sepa que ensamblador no use C. Sin embargo, sí lo es un desarrollador de SO. Podría decirse que las personas que tienen años de experiencia con el ensamblaje tienen más probabilidades de ser desarrolladores de sistemas operativos que desarrolladores web, por lo tanto, en este sentido, la respuesta es sí.

Y ahora para la pregunta no formulada:
3) ¿Los lenguajes de programación funcional son más rápidos de entender para las personas que tienen conocimientos de matemáticas que las que no?
La respuesta es sí. Porque esas personas ya sabrían algunas de las cosas.
Esto es como preguntar si C es más rápido de aprender para los programadores que ya conocen el ensamblaje. Sí lo es. Pero no hay implicación de que necesite conocer el ensamblaje para aprender C.

No tengo experiencia en matemáticas. Actualmente estoy aprendiendo Haskell a través de la Introducción a la programación funcional FP101x (curso edX) y Programación en Haskell (libro de 2007).

Creo que son los lenguajes estáticamente escritos los que necesitan el fondo matemático. Con Haskell, y un poco de ML estándar que aprendí cuando comencé a programar lenguajes (curso de la Universidad de Washington / Coursera), las matemáticas y la teoría eran pesadas.

Afortunadamente, la parte “mejor entendida” se trata solo de aprender el idioma y una vez que supere esa joroba, podría usar Haskell sin pensar mucho en las matemáticas y darle “sentido común”.

En cuanto a “es más probable que se use”, creo que esto es cierto para el uso en una sólida formación en informática, que se alinea estrechamente con las matemáticas. No estoy seguro de cuánto podré usar Haskell, pero estoy interesado en usarlo para la programación de sistemas. Dado que es una influencia en Scala (lenguaje de programación), deseo utilizar Haskell para mejorar mi comprensión de Scala y, a continuación, como base para aprender la programación funcional reactiva. Hay un subgrupo de la comunidad Scala, el promovido por Typesafe junto con Akka y Play Framework, que no parece centrarse en las cualidades funcionales de Scala.

Los lenguajes funcionales de la familia Lisp no parecen necesitar el fondo matemático. Uno podría pensar que sí porque SICP – Estructura e interpretación de programas de computadora utiliza ejemplos matemáticos, pero tal vez sea porque es del MIT. El material de aprendizaje de Clojure no parece centrarse en las matemáticas en absoluto.

Para mí es todo lo contrario. Tengo un doctorado en lógica matemática, pero no estoy convencido de que las mónadas sean una solución sensata a los problemas que enfrenta un lenguaje de programación funcional. No hay nada que haya visto hacer con mónadas que no se pueda hacer tan fácilmente en Lisp.

Por supuesto, Lisp no es un lenguaje funcional puro, y diría que en realidad no es un lenguaje funcional en absoluto. Pienso en ello como un lenguaje de reescritura de términos.

Para decirlo de la manera más tendenciosa posible, sospecho que las mónadas son una forma de pasar de contrabando intelectual a Haskell. A partir de ahora es, en el mejor de los casos, un experimento interesante. Tomar prestado un concepto de la teoría de categorías para manejar io me parece absolutamente loco. En lugar de torturar el lenguaje de programación en una cama Procrustean, sería preferible ampliar la lógica para lidiar con el cambio de estado.

Sin embargo, no soy un programador profesional.

Personalmente no tengo ningún fondo matemático, solo me gusta la limpieza y la elegancia de FP. La inmutabilidad, las funciones puras y la componibilidad son solo buenas ideas cuando se trata de desarrollar software, y estoy dispuesto a usar cualquier cosa que reduzca mi conteo de errores y me permita escribir un código cada vez menos comprensible.

Sin embargo, no me excedo: utilizo principalmente FP en lenguajes que no son FP, utilicé Haskell solo para aprender. Afortunadamente, los lenguajes convencionales más decentes hoy en día intentan acomodar tantos paradigmas de FP como sea posible, y mis tres principales (C #, Python y JavaScript) lo admiten bastante bien.

Digámoslo de esa manera. Tener una base matemática es una ventaja al aprender lenguajes de programación funcionales. Ya sabe cómo funciona la concatenación de funciones y piensa en esta estructura. Sin embargo, todos pueden convertirse en un buen programador funcional en un período de tiempo decente

La programación funcional fue inventada por matemáticos que estudiaban computabilidad, pero estoy de acuerdo con los demás en que no se requiere un fondo matemático.

Pero los ingenieros que pasamos años estudiando Variables estatales para ingenieros lo evitamos como la peste. No se presta a nuestro tipo de pensamiento y no lo recomiendo a los ingenieros.

Los humanos pasaron 2.000 años inventando el concepto de Estado, y luego los Programadores Funcionales nos dicen que lo desechemos.

Un fondo matemático casi siempre es útil. Es casi como tener superpoderes. 😉