¿Por qué no hay más lenguajes de programación en lenguaje multi natural?

¿Hay algún lenguaje de programación disponible y ampliable en más de un lenguaje natural?

Por ejemplo, una versión en inglés con un do..whilebucle, una versión en español con un hacer..mientasbucle, una versión en francés con faire..pendantay una versión en holandés con un doe..terwijl.

El único 'lenguaje de programación' que puedo pensar en ese tipo de implementos es Microsoft VBA.

Pregunta adicional: ¿Por qué hay tan pocos lenguajes de programación que vienen en múltiples idiomas?

Los nombres de las funciones en las fórmulas de Excel están localizados, donde puede usar la redacción en inglés o el equivalente local.

Esto ha llevado a innumerables apariciones de hojas de cálculo que se rompen a medida que se mueve a través de regiones e idiomas de usuario. También hace que sea difícil buscar información sobre la funcionalidad, ya que la documentación local está localizada y no menciona los nombres en inglés de las cosas, y por el contrario, preguntar SO con sus nombres locales no tiene sentido para la mayoría de los lectores.

Las palabras clave deben verse como apodos opacos, que simplemente se alinean con el significado de las palabras en inglés que se usan para deletrearlas. Hay muchos programadores que no hablan inglés por ahí que no saben qué significan la mitad de sus palabras clave.

En el siglo anterior, notablemente en los años 1960-1970, han sido algunos lenguajes de programación no basados ​​en inglés. En Francia, teníamos PAF y LSE con palabras clave de aspecto francés. WW2 Alemania tenía Plankalküll por K.Zuze. En la Unión Soviética, A.Ershov diseñó algunos idiomas (por ejemplo, Rapira ) con palabras clave rusas. IIRC PAF (diseñado e implementado por mi difunto padre cuando era un bebé - principios de la década de 1960) también se podía vender con palabras clave en inglés (o ruso o alemán). Y algunos idiomas, por ejemplo, APL , no tenían palabras clave en absoluto. Otros idiomas ( PL / I ) no tenían reservadopalabras clave Y podría redefinir palabras clave con técnicas de preprocesador (por ejemplo, hoy, en C, #define si ify #define sinon elsepara estudiantes franceses ...; trucos similares basados ​​en macro son posibles en PL / I o incluso Common Lisp).

Pero TIse desarrolló principalmente en un país de habla inglesa (EE. UU.). Entonces, los lenguajes de programación y sus implementaciones tenían especificaciones y documentación en inglés y palabras clave en inglés. Por lo tanto, cada desarrollador necesita poder leer inglés técnico, y no hay un valor agregado para "localizar" el lenguaje de programación (e incluso, hacerlo hace que el uso de otro software sea más difícil, como se respondió en otra parte). El dominio técnico y económico actual de los países de habla inglesa requiere que todos los ingenieros lean inglés hoy (estoy seguro de que incluso los ingenieros de software norcoreanos, chinos o iraníes pueden leer documentación en inglés y leer código con palabras clave e identificadores en inglés) . Por lo tanto, no hay suficiente valor agregado para "localizar" un lenguaje de programación (excepto quizás para enseñar programación primaria a niños de secundaria).

Además, el inglés tiene muchas palabras clave cortas (comparar sinonen francés con elseinglés o mettreen francés con putinglés), por lo que hay una pequeña ventaja en el uso de palabras clave en inglés ...

^{Quizás en un siglo, China podría convertirse en el país dominante de TI y podría florecer algún lenguaje de programación basado en chino. No sabemos qué pasaría entonces ...}

PD. El dominio del inglés no es específico de TI. Incluso si el Reino Unido abandona la Unión Europea -el escenario Brexit- , el idioma oficial de facto de la CE seguirá siendo el inglés (que entonces no será el idioma de ningún país miembro de la UE) y los proyectos H2020 ICT están escritos en inglés.

Hay muy buenas razones por las que los lenguajes de programación profesionales no se traducen.

1) Esfuerzo: sería una tarea enorme traducir un idioma moderno. Tome Java: sería una tarea pequeña traducir las aproximadamente 50 palabras clave, pero también necesitaría traducir la biblioteca estándar completa que consta de miles de clases y métodos y documentación relacionada.

2) Compatibilidad: incluso si el idioma base y la biblioteca de estándares fueron traducidos, aún no podría usar bibliotecas de terceros y código que no fue traducido. Las bibliotecas y el código de terceros son una parte importante de lo que hace que un lenguaje sea atractivo y útil. Con las versiones traducidas, cada idioma tendría que iniciar el ecosistema para cada traducción desde cero. Todos estarían peor.

3) Los programadores necesitan saber inglés de todos modos. Muchos estándares como HTTP, CSS, HTML utilizan el idioma inglés de todos modos para los identificadores. Estos no se pueden traducir ya que las palabras están integradas en el estándar.

Como los programadores necesitan saber inglés de todos modos, solo habría inconvenientes y ningún beneficio para crear versiones traducidas de lenguajes de programación.

Dicho esto, para los idiomas destinados a programadores casuales en lugar de programadores profesionales, podría tener sentido crear versiones traducidas. Este es el caso de VBA y creo que AppleScript también existía en versiones traducidas.

No conozco ningún otro idioma, excepto posiblemente alguna versión esotérica muy antigua de BASIC, que solía venir con muchos favores extraños, por lo que me atendré a la pregunta adicional: ¿por qué hay tan pocos lenguajes de programación traducidos?

Creo que es simplemente una complejidad adicional que los implementadores de compiladores y bibliotecas no ven una gran necesidad. Aquí hay algunas razones que contribuyen en mi opinión.

• Limitará la audiencia de su código si no se apega a un lenguaje "universal". Claro, no todos saben inglés, pero lo mismo es cierto para todos los idiomas.
• Las palabras clave de una sola palabra no son necesariamente una sola palabra en todos los idiomas, lo que complica el análisis. Nunca lo he comprobado, pero puedo imaginar que haya una buena cantidad de carcasas especiales para tratar con el tipo de varias palabras de c ++ "largo largo".
• Si comienza a traducir palabras clave, ¿considerará también las configuraciones regionales y cómo se formatean los números? Coma versus punto como separador decimal, por ejemplo. ¿O requieren que los sustantivos alemanes estén en mayúscula?
• La gran mayoría del texto en un programa dado son variables, métodos y nombres de clase, sin mencionar los comentarios. Si bien existen ciertamente bibliotecas escritas en otros idiomas, tener que mantener las traducciones del código fuente de todas las bibliotecas para servir a todos los usuarios sería una gran carga para la mayoría de los desarrolladores, sin mencionar la complejidad adicional en las discusiones sobre dicho código.
• Los compiladores tendrían que entender todos los idiomas implementados. Quizás incluso varios idiomas en el mismo archivo. Una pequeña hazaña para una computadora seguramente, pero trabajo extra sin embargo. Quizás termines teniendo que lidiar con la misma palabra clave que significa cosas diferentes en diferentes idiomas, o los términos simplemente son demasiado ambiguos para leer bien.
• (Ok, obstinado) Seguramente la mayoría de las personas que han tenido que lidiar con documentos de MS Office programados y formateados en diferentes idiomas descartarán la idea porque no vale la pena.

Personalmente, me encantaría si pudiéramos trabajar con el código de una manera más estructurada, en un editor que realmente entendiera el código como lo que es, declaraciones, instrucciones, etc. que nos permitirían hacer muchas cosas interesantes , tal vez incluso sea compatible con la traducción automática. Para cualquiera que se pregunte de qué estoy hablando, vea la imagen de Smalltalk y el navegador de refactorización, e imagine en qué se convertiría si hubiera tenido más tracción.

Si tiene un lenguaje que se define en términos de "etiquetas simbólicas" en un nivel y "designadores de etiquetas de superficie" en el otro, con mapeos bien definidos entre ellos, ciertamente sería posible.

Imagine un idioma donde tiene su if, while... do, switchy todas las otras palabras clave definidas (de alguna manera) en el estándar, podría enviar bibliotecas del sistema en "formato tokenizado", con código local escrito en forma no tokenizada. Luego, el compilador real funciona en la capa tokenizada y puede que todo esté bien.

Sin embargo, esta no es toda la historia. Todavía terminaría en situaciones en las que haya obtenido bibliotecas de algún lugar que no sea "la biblioteca estándar", interconectadas por nombres de funciones. Y esos no tendrían un mapeo canónico entre idiomas y requerirían la traducción a un idioma local para que se pueda usar bien, o terminaría con una mezcla de idiomas en su código fuente.

Todas las respuestas dadas son excelentes, pero de todos modos daré mis dos centavos.

Al comienzo de la computación , el dominio técnico, cultural y económico de los EE. UU. Y el Reino Unido hizo lógico cuáles fueron los idiomas más exitosos creados con palabras en inglés.

Más tarde, cuando el software se convirtió en una industria , también se convirtió en un esfuerzo global. No es un secreto que hay menos programadores de los necesarios, por lo que las compañías de software, y especialmente las empresas que definen la industria como IBM, comenzaron a contratar programadores de todas partes del mundo: Rusia, Pakistán, India, Francia, Alemania, Israel, etc. principalmente para programar en idiomas exitosos a nivel mundial ya existentes que ya se basaban en inglés y que también creaban nuevos idiomas, y para esa fuente dispar de programadores, el idioma común ya existente era una mejor opción que cualquier otro idioma.

Más recientemente, el movimiento de código abierto y software libre hizo de la creación de software un esfuerzo que es aún más global que antes. Algunos proyectos de software abiertos, incluidas algunas plataformas de programación, lenguajes y marcos, son proyectos enormes que involucran a cientos de colaboradores.

¿Qué idioma usaría una persona de Israel para colaborar con una persona de Sri Lanka? Lo más probable es que no hablen ni lean la lengua materna del otro. Entonces el inglés viene al rescate.

Nos guste o no, el inglés es el idioma de los esfuerzos globales . Y no porque Estados Unidos lo esté presionando, sino porque el mundo lo está presionando.

Parafraseando a Jay Walker :

Tu lengua materna es la que más usas todos los días, y siempre estará en el centro de tu corazón y tu cerebro, pero con el inglés eres parte de una conversación más amplia.

Ver video, "English Mania" .

Línea de fondo:

Los lenguajes de programación que usan diferentes lenguajes continuarán existiendo y se seguirán inventando (como Scratch basado en tokens gráficos), pero al menos en el futuro previsible serán relativamente pocos.

El inglés también es un idioma "sin acento", tampoco tiene caracteres extraños que necesiten una codificación diferente de ASCII. Soy italiano y, a veces, me enfrento a errores de codificación si utilizo un diseño de teclado italiano o caracteres acentuados como àèéìòù. Además, "más" se traduce en "altrimenti", "en" es "dentro" ... eso sería frustrante.