¿Podemos estudiar lenguajes de programación en el contexto de la lingüística? ¿Los lenguajes de programación evolucionan naturalmente de manera similar a los lenguajes naturales?
Aunque la racionalidad completa y la coherencia matemática son esenciales para los lenguajes de programación, todavía existe la necesidad (especialmente los lenguajes modernos) de hacerlos legibles y cómodos para los humanos.
¿Están evolucionando los lenguajes de programación para volverse más lingüísticos y, por lo tanto, más naturales? Por ejemplo, el código de máquina, las tarjetas perforadas y los lenguajes de ensamblaje han dado paso a lenguajes más legibles como Ruby y Python, etc.
Cuando digo que los lenguajes de computadora se están volviendo más naturales, no quiero decir que contienen más "palabras que tenemos en inglés", sino que parecen parecerse más a un lenguaje natural, en términos de su complejidad de gramática y capacidad de expresar significado. (por ejemplo, poder describir de manera elocuente una consulta de una base de datos de manera comprensible tanto racional como humana).
¿Qué piensan todos ustedes? ¿Los lenguajes de programación se parecen más a los lenguajes naturales y, por lo tanto, se vuelven aplicables a las leyes de la lingüística?
O tal vez los idiomas viven en un espectro, donde por un lado tienes los lenguajes racionales extremos y por otro los más creativos. Tal vez, los lenguajes de programación y naturales son idénticos y ambos simplemente se encuentran en este espectro de lenguaje (su única diferencia, tal vez es la 'cosa' a la que están tratando de dar su significado).
¿Existe alguna conexión entre la separación (efecto Babel Tower) de los idiomas humanos y los idiomas de la computadora? ¿Se vuelven más diversos por las mismas razones (es decir, para resolver diferentes problemas dentro de sistemas informáticos / sistemas de cultura en constante evolución, etc.)?
fuente
Respuestas:
No, realmente no. Los lenguajes de programación se han convertido más en lenguajes naturales solo en el sentido de "palabras que tenemos en inglés" ( sic ).
Una característica clave de los lenguajes de programación es que no son ambiguos. Cuando escribe un programa y lo ejecuta, tiene un significado bien definido, que es su comportamiento. Si desea escribir un programa que funcione según lo previsto (un objetivo difícil), es importante que el comportamiento¹ del programa sea lo más predecible posible. Los lenguajes de programación no han hecho mucha diferencia en la gran brecha hacia los lenguajes naturales.
Por el contrario, se ha trabajado para cerrar la brecha desde el otro lado: analizar lenguajes naturales con las mismas herramientas que los lenguajes de programación. Este campo se llama procesamiento del lenguaje natural . Estos enfoques han sido descartados en favor del aprendizaje automático . Citaré un pasaje en el artículo de Wikipedia que es directamente relevante aquí:
Una forma en que la programación evoluciona es que a medida que diseñamos sistemas cada vez más grandes, el código fuente no siempre es una buena forma de entenderlos. Por ejemplo, una CPU Intel es uno de los objetos más complejos jamás diseñados por Man, y su "código fuente" no es solo una colección de archivos de texto, ni mucho menos. Pero el diseño completo tampoco está evolucionando hacia algo parecido a un lenguaje humano. No sé cuáles son las herramientas cognitivas o metáforas apropiadas aquí, y no creo que nadie lo sepa todavía; preguntar de nuevo en un par de siglos.
¹ O más bien, el conjunto de posibles comportamientos anotados con las circunstancias bajo las cuales surgen, pero eso solo agrega un paso de indirección en el modelado, por lo que esto no es realmente relevante aquí.
fuente
Los lenguajes de computadora tienden a funcionar bien con brevedad y precisión, algo así como la notación matemática, que no ha mostrado ninguna inclinación particular a evolucionar hacia el lenguaje natural (que yo sepa) en los últimos miles de años.
También dudo que si se comunicara con su bebé exclusivamente en Haskell durante los primeros años de su vida, desarrollaría la fluidez del lenguaje natural. Entonces, creo que hay un contraste bastante agudo entre los lenguajes naturales y de computadora.
Quizás una mayor difusión de las técnicas de construcción del lenguaje ha mejorado un poco la "naturalidad" con el tiempo, supongo, ya que los programadores "votan con los pies" al usar idiomas que les parecen más fáciles y la cantidad de personas capaces de crear idiomas ha aumentado con más profesionales y mejores herramientas, pero este es un pequeño efecto en los bordes y no representa una transformación fundamental de los lenguajes de programación en humanos.
fuente
Un caso de estudio interesante en esta área es Perl vs Ruby (y Python ). Perl es un lenguaje de secuencias de comandos desarrollado a principios de los años 90 que agregó mucha capacidad en comparación con los lenguajes de secuencias de comandos basados en Unix anteriores (por ejemplo, bash). El autor Larry Wall dice que sus antecedentes en lingüística inspiraron algunas de las características del lenguaje.
Sin embargo, Perl tiene una sintaxis incómoda y muchos casos especiales que hacen que el idioma sea algo parecido al inglés en todas sus sutiles idiosincracias que inspiran varios niveles de crítica . Los lenguajes de secuencias de comandos posteriores como Ruby y Python, desarrollados por científicos informáticos, tienen mucha más consistencia en su sintaxis. El principal problema es que el lenguaje natural tiene grandes cantidades de ambigüedad (esto se estudia en el campo de la lingüística), por lo que el lenguaje natural tendrá un lugar clave en las futuras interfaces humano-computadora como Siri, pero esas interfaces estarán inherentemente sujetas a problemas de ambigüedad.
Entonces, aquí hay un caso en el que la evolución de los lenguajes de computadora se alejó de una idea de lenguaje natural. Además, la historia general de los lenguajes de programación de computadoras es que se han desarrollado y cambiado para eliminar la ambigüedad (que es altamente inherente al lenguaje natural). esto no se entendió temprano en la historia de los compiladores (posiblemente en la década de 1970) y, por ejemplo, las primeras versiones del lenguaje Fortran tenían declaraciones con significados ambiguos que dependían de la implementación del compilador. parte de la teoría del lenguaje CS relacionada con el análisis fue desarrollada en parte en respuesta al descubrimiento de la ambigüedad en el análisis del lenguaje.
fuente
El lenguaje de máquina es muy preciso, mientras que un texto escrito por humanos generalmente se puede interpretar de muchas maneras diferentes (algunos textos poéticos, por ejemplo).
Lo que evoluciona cada vez más es la coincidencia de patrones, por ejemplo, cuando escribe un código feo, un compilador puede ayudarlo a proponer varias soluciones posibles y luego arrojar alguna advertencia o error que puede ayudarlo a exprimirse. (basado en patrones de código comunes, por ejemplo)
Hay una investigación específica sobre patrones de interacción / diseño, incluso T9 y SWYPE son reconocedores de patrones que te ayudan mucho (los programas que graban tu voz y la convierten en texto también son reconocedores de patrones).
Por supuesto, un programa es algo que se basa en mecanismos precisos, por lo que necesita lenguajes precisos (no naturales), mientras que una simple búsqueda web en Google es muy natural, solo tiene que escribir pocas palabras y obtendrá lo que desea.
Cada tarea y objetivo diferentes tiene su propio idioma, no es una simple "evolución de un solo idioma", hay muchos más idiomas. Las tareas precisas necesitan lenguajes precisos y las tareas relajadas requieren lenguajes relajados
Puede escribir la misma pieza de código C y luego compilarlo con varios compiladores diferentes, y (a menos que algún compilador tenga errores) el resultado del código será el mismo incluso si se genera un ensamblaje diferente, mientras que para una búsqueda en la web se obtiene el mismo Las palabras clave para diferentes motores de búsqueda dan resultados diferentes.
fuente
Hace algunos años, mi hijo mayor y yo desarrollamos un sistema de programación y desarrollo en inglés simple con el interés de responder las siguientes preguntas:
¿Pueden los programas de bajo nivel (como compiladores) ser escritos conveniente y eficientemente en idiomas de alto nivel (como inglés)?
¿Se pueden analizar los lenguajes naturales de una manera relativamente "descuidada" y aún así proporcionar un entorno suficientemente estable para una programación productiva?
¿Es más fácil programar cuando no tiene que traducir sus pensamientos en lenguaje natural a una sintaxis alternativa?
Ahora podemos responder a cada una de estas tres preguntas, por experiencia directa, con un rotundo "Sí".
Nuestro analizador funciona, creemos, algo así como el cerebro humano. Considerar. Un padre le dice a su pequeño hijo:
"¿Quieres chupar esta botella, pequeño?"
Y el niño escucha
"bla, bla, SUCK, bla, bla, BOTELLA, bla, bla".
Pero responde correctamente porque tiene una "imagen" de una botella en el lado derecho de su cabeza conectada a la palabra "botella" en el lado izquierdo, y una "habilidad" preexistente cerca de la parte posterior de su cuello conectada a término "chupar". En otras palabras, el niño combina lo que puede con las imágenes (tipos) y habilidades (rutinas) que ha acumulado, y simplemente ignora el resto. Nuestro compilador hace lo mismo, con nuevas imágenes (tipos) y habilidades (rutinas) definidas, no por nosotros, sino por el programador, mientras escribe un nuevo código de aplicación.
Una definición de tipo típica se ve así:
Un polígono es una cosa con algunos vértices.
Internamente, el nombre "polígono" ahora está asociado con un tipo de estructura asignada dinámicamente que contiene una lista de vértices doblemente vinculada. "Vértice" se define en otra parte (antes o después de esta definición) de manera similar; El plural se entiende automáticamente.
Una rutina típica se ve así:
Para agregar una x coord y ay coord a un polígono: Cree un vértice dado la x y la y. Agregue el vértice a los vértices del polígono.
Tenga en cuenta que no se requieren nombres formales (nombres propios) para parámetros y variables. Esto, creemos, es una idea importante. Mi silla y mesa del mundo real nunca se llaman (en una conversación normal) "c" o "myTable". Me refiero a ellas simplemente como "la silla" y "la mesa". Del mismo modo aquí: "el vértice" y "el polígono" son los nombres naturales de tales cosas.
Tenga en cuenta también que los espacios están permitidos en los "nombres" de rutina y variables (como "x coord"). Este es el siglo XXI, ¿sí? Y esos "apodos" también están permitidos (como "x" para "x coord"). Y que los posesivos ("vértices del polígono") se usan de una manera muy natural para hacer referencia a "campos" dentro de los "registros".
Tenga en cuenta, también, que la palabra "dado" podría haber sido "usar" o "con" o cualquier otro equivalente ya que nuestro análisis descuidado se centra en las imágenes (tipos) y habilidades (rutinas) necesarias para la comprensión, e ignora tanto como sea posible, el resto.
En el nivel más bajo, las cosas se ven así:
Para agregar un número a otro número: Intel $ 8B85080000008B008B9D0C0000000103.
Tenga en cuenta que en este caso tenemos los idiomas más altos y más bajos, inglés y código de máquina (aunque en hexadecimal), en una sola rutina. La idea aquí es que (como un libro de matemáticas típico) un programa debe escribirse principalmente en un lenguaje natural, con fragmentos apropiados en sintaxis más convenientes según (y solo como) se requiera.
Puede obtener nuestro sistema de desarrollo aquí: www.osmosian.com/cal-3040.zip. Es un pequeño programa de Windows, de menos de un megabyte de tamaño. Si comienza con el PDF en el directorio de "documentación", antes de pasar diez páginas, volverá a compilar todo el shebang en sí mismo (en menos de tres segundos en una máquina de última generación de Walmart).
Las preguntas y comentarios deben dirigirse a [email protected]
fuente
La separación de los idiomas humanos proviene de la evolución (¿darwiniana?) En comunidades aisladas. La separación de los lenguajes de programación proviene de variaciones en la necesidad técnica, ideología técnica, de cambios en la comprensión técnica y teórica, de cambios en nuestra capacidad técnica para implementar. Es un proceso algo más consciente, creo.
¿Podrían los lenguajes de computadora ser más como lenguajes naturales? Probablemente un poco, hasta cierto punto. Supongo que gran parte de la complejidad del lenguaje natural es el resultado de una variedad de fenómenos de evolución concurrentes que no tienen ninguna razón para producir un resultado consistente en ningún momento, a pesar de que es probable que las viejas inconsistencias se eliminen progresivamente mientras aparecen nuevas. . No soy experto en lingüística diacrónica. Pero, ¿queremos ese tipo de complejidad en los lenguajes de programación?
El tema de la ambigüedad es importante, pero no como lo afirma la mayoría de las personas. Un lenguaje es un medio de comunicación, y debe analizarse en el contexto de esa comunicación (hombre-hombre, hombre-máquina, ambos, entre lugares o entre tiempos, ... para decirlo un poco simplista). Lo que importa no es si solo puede hacer declaraciones inequívocas en el idioma, sino si siempre puede asegurarse de que la comunicación será inequívoca en el contexto previsto. Existe un lenguaje de programación bien conocido y ampliamente utilizado, que permite escribir programas ambiguos (bueno, lo hizo, pero no he visto las últimas versiones por un tiempo). En este caso, el compilador es lo suficientemente inteligente como para detectar la ambigüedad y solicitar una aclaración, que se puede incorporar en el programa para eliminar la ambigüedad. Tenga en cuenta que la detección de ambigüedad no significa que solo una de las posibles opciones tenga significado, todas tienen significado. El problema es si una de las entidades comunicantes puede detectar la ambigüedad para que el remitente pueda aclararla. Los seres humanos son malos en esto, pero las computadoras pueden ser bastante buenas.
Los formalismos y los lenguajes de programación podrían tener una sintaxis más rica y flexible. Creo que la razón principal por la que no lo hacen es el simple conservadurismo. Las herramientas sintácticas utilizadas siguen siendo muy a menudo herramientas diseñadas hace treinta años o más, para cumplir con las limitaciones de las computadoras de la época. Analizar la eficiencia ya no es un problema tan crítico en la compilación y existen técnicas más potentes de manera manejable.
Curiosamente, la base más utilizada para la sintaxis de lenguajes de programación proviene de la investigación del lenguaje natural: la gramática libre de contexto. Gran parte de la investigación técnica se trasladó a la informática teórica / técnica en los años sesenta, para ser redescubierta a principios de los ochenta por personas de lenguaje natural (estoy simplificando). Desde entonces, se han realizado muchos progresos para la sintaxis en lenguajes naturales, mientras que la informática parece en gran medida atascada con las viejas herramientas sintácticas. El péndulo del lenguaje natural ahora se balancea nuevamente hacia técnicas estadísticas, pero no se olvidan los enfoques algebraicos para la sintaxis. Lo más probable es que los buenos enfoques provengan de una combinación de técnicas algebraicas y estadísticas.
Mi sensación es que el área crítica es la semántica y la transición entre la sintaxis y la semántica. Esto aún es muy difícil de formalizar para el lenguaje natural, mientras que tenemos muchas técnicas precisas en el caso de lenguajes de programación y sistemas formales. Como el juego está lejos de ser jugado para lenguajes naturales, es difícil decir qué impacto podría tener en los lenguajes de programación en el futuro.
Otro punto es que muchos diseñadores de lenguaje de programación están tratando de probar algo o imponer una ideología técnica. Por lo tanto, se vuelven extremadamente prescriptivos en su diseño para evitar que los usuarios se aparten de sus paradigmas previstos. Desafortunadamente, esto es extremadamente contraproducente para la creatividad. El lenguaje más creativo jamás diseñado fue uno de los primeros: Lisp (1958). La libertad y flexibilidad que permitió fue la fuente de una considerable creatividad. El precio era que requería autodisciplina y comprensión. Pero Lisp era realmente un metalenguaje, un lenguaje para la creación de idiomas.
Ahora, para tomar otra perspectiva, los programas son en realidad pruebas de su especificación vista como una declaración matemática (bueno, estoy simplificando nuevamente). Algunas personas (no recuerdo referencias, lo siento) han estado jugando con probadores de teoremas para producir pruebas que parecerían haber sido escritas por un matemático en lenguaje natural. Así que supongo que la idea de tener programas que parecen estar escritos en lenguaje natural puede no ser totalmente absurda.
Sin embargo, puede notar que, incluso cuando es escrito informalmente por un matemático, el discurso matemático se ve muy diferente de la conversación ordinaria o de un libro de historia. Esto se debe a una diferencia significativa en el universo del discurso en cuestión, los dominios semánticos de los que se habla. Por lo tanto, si bien puede imaginar lenguajes de programación que se parecen más a los lenguajes naturales, existe una limitación natural que es el dominio del discurso y sus propias propiedades deseables. Lo más probable es que siga siendo esencialmente superficial, es decir, mayormente sintáctico. El matemático puede hablar sobre sistemas formales y sobre política. Esperemos que los dos discursos no se vean similares. Las computadoras no pueden (¿todavía?) Hablar de política o entenderla. El día que lo hagan ya no estará programando.
Mirando hacia atrás en la historia, los lenguajes de alto nivel fueron, desde el primer momento (FORTRAN) un intento de acercarse a una forma más natural para expresar tareas computacionales, pero estas tareas se entendieron como matemáticas o lógicas (Fortran 1957, Algol 1958, Lisp 1958 ), o más orientado a los negocios (Cobol 1959). En 10 años, las personas se preocupaban por los idiomas que estarían más cerca, mejor adaptados al problema en cuestión, y hubo una investigación significativa en el llamado
extensible languages
, que abarca tanto la sintaxis como la semántica. Una vía importante para expresar problemas de forma más natural fue la aparición deobject orientation
(a veces bajo otros nombres). Aunque siempre es difícil asignar la paternidad, probablemente surgió del trabajo sobre inteligencia artificial, principalmente en Lisp, y del lenguajeSimula 67
(Familia Algol), que en sí misma tenía la intención de expresar problemas del mundo real más naturales que se simulan en una computadora. Todo parece históricamente consistente.fuente
Aunque son similares en cuanto a que las preguntas formuladas son similares, son bastante distintas en términos de complejidad. La principal diferencia es que el lenguaje natural es intrínsecamente ambiguo (incluso a nivel de las palabras). ¿Incluso no está claro qué se entiende por palabra? Sin embargo, en el mundo de los lenguajes de programación, se dispone de una variedad de dispositivos de definición. Mire las gramáticas para analizar el lenguaje natural y aquellas para analizar los lenguajes de programación, la diferencia de tamaño es sorprendente. La cuestión es que las gramáticas para los lenguajes de programación son sistemas formales; entonces son susceptibles de análisis matemático. Al abordar las ambigüedades surgen muchos problemas para los cuales una solución en el lenguaje de programación sería trivial o simple.
Quizás la brecha entre los lenguajes naturales y los lenguajes de programación se reducirá si la brecha entre los informáticos y las personas "naturales" se reduce.
fuente
En los últimos años, el interés en (E) DSL e interfaces fluidas ha aumentado constantemente, en una gran variedad de lenguajes: Haskell, los diversos lenguajes de secuencias de comandos, C #, Java e incluso C ++ (piense en la sobrecarga de
operator<<
para hacer la salida).Hasta cierto punto, estos permiten que el código se lea más naturalmente. Ilustraré con un ejemplo de EDSL en groovy. El paquete groovy.time te permite escribir
Si tuviera que hacer esto a través de la clase java.util.Calendar, tendría que escribir algo como esto para el primer ejemplo:
fuente
Los lenguajes de computadora (incluso los rudimentarios lenguajes de máquina de días pasados) son lenguajes humanos, ya que son principalmente para la comunicación con otros seres humanos, están definidos por humanos y se usan solo secundariamente para transmitir instrucciones a una máquina. Por lo tanto, evolucionan de la misma manera que evolucionan los lenguajes "naturales" (solo busque "modismos" para su idioma favorito, compruebe cómo, por ejemplo, C ha evolucionado de K&R C a ISO-C 2011 actual. Pero existen en un entorno diferente, ellos debe transmitir un significado preciso (las computadoras aún son demasiado tontas para tener sentido y corregir lo que se les pide), y hay una prima en la facilidad de procesamiento (por lo tanto, la gramática y el vocabulario de incluso C ++, PL / 1 o APL son mucho más simples que, por ejemplo, el inglés, que según los idiomas naturales es bastante simple).
Lo mismo puede decirse del formalismo de las matemáticas o de las ciencias en general, o incluso los planos (inherentemente 2D, no 1D como los demás).
fuente