¿Por qué la sintaxis del lenguaje funcional no está más cerca del lenguaje humano?

13

Me interesa la programación funcional y decidí enfrentarme con Haskell. Me duele la cabeza ... pero finalmente lo conseguiré ... Sin embargo, tengo una curiosidad, ¿por qué la sintaxis es tan críptica (a falta de otra palabra)?

¿Hay alguna razón por la que no sea más expresivo , más cercano al lenguaje humano?

Entiendo que la FP es buena para modelar conceptos matemáticos y tomó prestada una parte de sus medios de expresión concisos, pero aún así no es matemática ... es un lenguaje.

    
pregunta JohnDoDo 05.10.2012 - 11:48

8 respuestas

14

Lenguajes funcionales como Haskell y su antecedente Miranda surgió del concepto matemático de cálculo lambda . Desde la página de Wikipedia:

  

El cálculo Lambda (también escrito como λ-calculus o llamado "lambda calculus") es un sistema formal en lógica matemática para expresar el cálculo mediante la unión y sustitución de variables.

     

...

     

El cálculo Lambda ha desempeñado un papel importante en el desarrollo de la teoría de los lenguajes de programación. Las contrapartes más prominentes para el cálculo lambda en informática son los lenguajes de programación funcional, que esencialmente implementan el cálculo (aumentado con algunas constantes y tipos de datos). Más allá de los lenguajes de programación, el cálculo lambda también tiene muchas aplicaciones en la teoría de la prueba. Un ejemplo importante de esto es la correspondencia de Curry-Howard, que proporciona una correspondencia entre los diferentes sistemas de cálculo lambda mecanografiado y los sistemas de lógica formal.

Debido a esta historia, las sintaxis de estos lenguajes funcionales (y los elementos funcionales de lenguajes más imperativos) están fuertemente influenciados por la notación matemática utilizada por el cálculo lambda.

La precisión con la que tanto las notaciones matemáticas como los lenguajes informáticos pueden describir los requisitos y la precisión con la que las computadoras requieren que sus instrucciones estén escritas se correlacionan bien entre sí. Sin embargo, la imprecisión del lenguaje natural crea una enorme barrera para su uso para la programación de computadoras. Incluso los ( programación de lenguaje natural más exitosos, como Wolfram Alpha necesita una experiencia de dominio significativa para ser utilizada de manera efectiva.

    
respondido por el Mark Booth 05.10.2012 - 12:38
29

La sintaxis de Haskell está cerca del lenguaje humano. Está diseñado específicamente para parecerse a la notación matemática, que es un lenguaje diseñado por humanos (por lo tanto, un lenguaje humano ) para expresar precisamente los conceptos sobre los que se basa Haskell.

Puede mostrar un pedazo de código Haskell a cualquier matemático o lógico, y él podrá entenderlo, incluso si nunca ha oído hablar de Haskell y no sabe absolutamente nada sobre programación, informática o incluso computadoras.

Por otro lado, puede mostrar a cualquier matemático o lógico un fragmento de código como este:

x = x + 1

y estará completamente confundido, diciendo: "Esto no tiene sentido, no hay x , por lo que x es igual a x más 1 ."

Si una notación específica es o no "críptica" o no, es una cuestión de opinión y familiaridad.

    
respondido por el Jörg W Mittag 05.10.2012 - 12:11
12

Creo que una cosa con la que probablemente te encuentres es algo que también encontré al aprender programación funcional, que es que con la programación funcional puedes (y casi tienes que) pensar / trabajar a un nivel más alto que con la programación programación imperativa.

Lo que te parece menos expresivo, creo que en realidad es más expresivo: no tienes que explicar cada pequeño detalle y puedes hacer más con menos código en la programación funcional. Hay más poder a lo que escribes.

Por ejemplo, podría escribir imperativamente:

for each (Person person in people)
    print(person.name)

que es totalmente legible como inglés.

Una versión de Haskell puede ser (y esto no es válido, pero es solo para comparación sintáctica):

map (print . name) people

que requiere menos código y menos detalles. No tengo que dividir las cosas en un bucle y su (s) variable (s) ( for each (...) ), la función map se encarga de eso.

Trabajar a ese nivel puede tardar un tiempo en acostumbrarse. Si ayuda, Haskell fue probablemente el momento más difícil en el que aprendí un nuevo idioma desde que empecé a programar, y conozco > 10 idiomas (incluido Lisp). Sin embargo, valió la pena aprender.

    
respondido por el paul 05.10.2012 - 17:17
8

Actualmente estoy tratando de enfrentar a Scala en este momento, por lo que puedo simpatizar. Al menos con Scala puedo volver a un estilo imperativo cuando las cosas se ponen difíciles.

Creo que hay varias fuerzas en juego aquí:

  • Los diseñadores de lenguajes funcionales tienen necesariamente una sólida formación matemática, por lo que toman prestada la notación matemática que es natural para ellos.

  • Mayor expresividad (es decir, poder de las declaraciones, en lugar de La proximidad al inglés) de cualquier idioma tiene (IMO) un precio correspondiente En la pendiente de la curva de aprendizaje. Terseness es una cualidad muy apreciada. en Scala, con muchas cosas que son opcionales.

  • Los lenguajes funcionales hacen las cosas de manera muy diferente, por lo que los básicos las operaciones no se asignan a construcciones imperativas.

respondido por el Richard Close 05.10.2012 - 12:05
3

Si entendí su último comentario correctamente, su pregunta es ¿por qué Haskell a menudo usa operadores simbólicos en lugares donde también podría usar palabras clave alfanuméricas (o nombres de funciones)?

Respecto a las palabras clave, una respuesta sería que las palabras clave le impiden utilizar ciertas palabras como nombres de variables. Por ejemplo, siempre me molesta cuando quiero llamar a mis variables from y to en un idioma en el que una de ellas es una palabra clave, como en Python.

Otra razón para los operadores simbólicos en general es la concisión. Eso no se aplica realmente en sus ejemplos específicos de listas de comprensión ( <- no es más corto que in ), pero en muchos casos lo hace.

Otra razón es la legibilidad. Esto puede parecer contrario a la intuición porque los operadores simbólicos suelen ser más difíciles de aprender, ya que sus "nombres" realmente no le dicen nada sobre lo que hacen (mientras que el nombre de una función normalmente lo hará), pero una vez que sabe lo que hace un operador determinado, Las expresiones con operadores simbólicos de infijo a menudo son más fáciles de analizar para un ser humano que uno con muchas llamadas a la función de prefijo alfanumérico, ya que los operadores se distinguen más fácilmente visualmente de los operandos de esa manera. Por ejemplo, la mayoría de la gente estaría de acuerdo en que 2 * 3 + 4 es más fácil de leer que add (mult 2 3) 4 o add(mult(2, 3), 4) .

    
respondido por el sepp2k 05.10.2012 - 12:36
3

Los lenguajes informáticos imperativos en su mayoría no están más cerca de los lenguajes naturales que, por ejemplo, Haskell es.

Sin embargo, algunos están diseñados para parecerse más al inglés: Cobol y Hypercard, por ejemplo. Las lecciones que tomaría de estos ejemplos son:

  • la similitud con los lenguajes naturales no parece producir mejoras directas en la usabilidad
  • la emulación de lenguajes naturales directamente puede producir lenguajes informáticos que son detallados y oscuros

Se informó que el lenguaje informático Perl fue diseñado con algunos aspectos más sutiles del lenguaje natural en mente . Yo juzgaría que Perl lo hace mejor que Cobol o Hypercard en la usabilidad general, pero las personas tienen opiniones diferentes sobre Perl.

    
respondido por el comingstorm 05.10.2012 - 21:37
3

Creo que Haskell se vuelve tan similar al lenguaje humano como se puede obtener sin introducir una sintaxis loca. Realmente hace un gran esfuerzo hacia esto, por ejemplo, con la cláusula where para posponer una definición y con la sintaxis de comprensión de lista, que es exactamente lo que escribiría en una pizarra. También evita caracteres extraños como llaves y tiene un uso liberal de sangría. El ejemplo típico es quicksort:

qsort [] = []
qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
               where lesser = [x | x <- xs, x <= p] 
                     greater = [x | x <- xs, x > p]

Admitido, es un ejemplo simple, pero no conozco ningún otro idioma que lo haga tan legible como es.

Hacer cosas más complicadas puede ser difícil de leer en Haskell, pero eso tiene que ver con el sistema de tipos, el IO restringido y no con la sintaxis en absoluto.

En todo caso, diría que Haskell ha sacrificado la simplicidad sintáctica para acomodar una sintaxis que es más similar al lenguaje humano. Un lenguaje como esquema tiene una sintaxis que está muy lejos de lo que un humano escribiría, pero es realmente sencillo explicar sus reglas.

    
respondido por el Andrea 05.10.2012 - 13:19
2

Creo que la diferencia tiene que ver con la forma en que la programación funcional / declarativa hace declaraciones acerca de un problema como si fuera un problema matemático, donde la programación imperativa describe un proceso . En el mundo de los negocios, los programas informáticos envuelven o reemplazan los procesos físicos, por lo que puede encontrar un lenguaje que refleje que sea más intuitivo.

Resulta que el estilo funcional se presta para hacer un uso seguro de múltiples procesadores (porque minimiza la mutabilidad y los efectos secundarios), algo que veremos más en el futuro. Además, la mayoría de los lenguajes funcionales modernos tienen colecciones con iteradores a las que se pueden pasar funciones. Estos métodos pueden dividir su carga de trabajo en varios procesadores de manera muy eficiente sin que usted lo sepa.

    
respondido por el GlenPeterson 08.10.2012 - 16:01

Lea otras preguntas en las etiquetas