Codificación en otros idiomas (hablados)

Esto es algo que siempre me he preguntado y no puedo encontrar ninguna mención al respecto en ningún sitio en línea. Cuando una tienda de, digamos, Japón, escribe código, ¿podría leerlo en inglés? ¿O los idiomas, como C, PHP, cualquier cosa, tienen traducciones al japonés que escriben?

Supongo que lo que pregunto es si todos los programadores del mundo saben lo suficiente en inglés para usar exactamente las mismas palabras reservadas que yo.

¿Este código:

If (i < size){
    switch
        case 1:
            print "hi there"
        default:
            print "no, thank you"
} else {
    print "yes, thank you"
}

mostrar exactamente lo mismo que estoy viendo ahora en inglés, o alguna otra persona que no hable inglés vería las palabras "if", "switch", "case", "default", "print" y " else "en su lengua materna?

EDITAR - sí, esto es serio. No sabía si las diferentes localizaciones de un idioma tienen diferentes palabras clave. o si hay incluso diferentes localizaciones.

Si entendí bien, la pregunta en realidad es: "¿todos los programadores del mundo saben lo suficiente inglés para usar exactamente las mismas palabras reservadas que yo?"

Bueno ... el inglés no es el tema aquí, sino las palabras reservadas del lenguaje de programación. Quiero decir, cuando comencé hace unos 10 años, no tenía ni idea de inglés, y aun así podía programar cosas simples aprendiendo el lenguaje de programación, incluso cuando no sabía lo que significaban (en inglés). De hecho, esto me ayudó a aprender inglés.

Por ejemplo. Sé hacer una "iteración" (iteración por supuesto) tuve que escribir:

 for( i = 0 ; i < 100 ; i++ ) {}

Para mí el "para", el ";" y el "++" donde son simples palabras o símbolos extranjeros. Más tarde me enteré de que "for" significaba "para" y "while" significaba "mientras", etc. pero mientras tanto no necesitaba saber inglés, pero en mi caso lo que necesitaba era saber "C".

Por supuesto, cuando necesitaba aprender más cosas, tenía que aprender inglés, porque la documentación está escrita en ese idioma.

Entonces la respuesta es: No, no veo si, mientras, para etc. en mi idioma nativo. Los veo en inglés, pero para mí no significaron nada más que para el lenguaje de programación a su vez.

Es como una sentencia switch en bash: case .. esac. ¿Qué es "esac" ... para mí el final de la declaración de cambio en bash.

Supongo que eso es lo que llamamos "abstracción"

En el lenguaje Java, algunos métodos deben nombrarse (al menos parcialmente) utilizando el idioma inglés debido a la convención de JavaBeans.

Esta convención requiere que se establezca una propiedad X mediante un par de métodos getX () y setX (). Aquí en el Canadá francés, donde algunos desarrolladores están obligados a codificar en francés, esto conduce a la siguiente farsa:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

Tengo problemas para encontrar referencias, pero recuerdo tres historias.

Un hacker Lisp defiende funciones sin sentido como "cdr" y "car" comparándolas con la programación en su idioma no nativo: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171. html

Cuando Yukihiro Matsumoto ("Matz") comenzó a desarrollar Ruby, usó palabras clave en inglés a pesar de que estaba escribiendo toda la documentación en japonés. . No hubo documentación en inglés para Ruby durante un par de años, y muy pocos estadounidenses lo usaron. Pero ahora es un idioma de clase mundial, y el hecho de que nació en Japón es solo de interés histórico. Si el idioma hubiera estado usando palabras clave en hiragana, habría tenido muchas más dificultades para ganar popularidad.

Leí un ensayo una vez, tal vez alguien más pueda encontrarlo, Google no es de ayuda hoy en día, que sugiere que traducir palabras clave estaba mal orientado porque las palabras no son en realidad en inglés, son jerga. No solo (para usar los ejemplos anteriores) para y pour no tienen el significado exacto que tiene for en inglés, para los no programadores la frase "for loop" es una burla. Incluso los estadounidenses tienen que aprender un nuevo significado. Entonces, traducir el significado superficial de las palabras a otro idioma es más como hacer un juego de palabras entre idiomas en lugar de ser realmente útil.

Realmente no he pensado mucho en programar en japonés antes, pero aquí vamos, usando el ejemplo de código de la pregunta.

Usando solo las declaraciones de idioma en japonés con las variables en inglés:

// In Japanese, it makes more sense to put the keywords/modifiers as
// postfix expressions rather than prefix expressions.
(i < size)か {
     (l[i])は {
     1だ:
         「もしもし。」を書く;
     省略時値:
         「いいえ、いいですよ。」を書く;
     }
} ない {
     「はい、ありがとうございます。」を書く;
}

Como ya han señalado muchas personas, en la mayoría de los lenguajes de programación solo tienes que aprender algunas palabras clave, por lo que no importa mucho si están en inglés (o en un idioma que no sea el tuyo, para el caso). Es solo un símbolo que asocias con alguna construcción. Por ejemplo, en VB tienes "THEN", que en muchos lenguajes de estilo C sería "{" y no hace una gran diferencia en la legibilidad (bueno, al menos así es como yo lo veo, siendo un idioma no inglés hablante nativo).

Pero donde las cosas a veces pueden ponerse complicadas, y donde la elección del lenguaje (natural) es importante es al nombrar identificadores. Si los nombres de variables, funciones, clases, etc., no tienen un nombre significativo para usted debido a la barrera del idioma, seguir incluso el código más simple puede ser bastante desafiante.

Recuerdo que una vez alguien me dio un breve fragmento de Actionscript tomado de algún blog. Los nombres estaban en alemán y como no hablo una palabra de ese idioma, las cosas podrían haberse llamado var_123, var_562 o func_333 también (y probablemente me hubiera sido más fácil recordar los nombres o al menos tener un posibilidad de deletrearlos correctamente sin copiarlos y pegarlos). Como se trataba de un fragmento breve e independiente, utilicé un traductor en línea para dar a esas variables y funciones nombres significativos en mi idioma nativo (español) y, después de eso, todo quedó claro. El punto es que el código era realmente simple, pero solo pude darle sentido sin demasiado (innecesario) esfuerzo adicional justo cuando superé la barrera del idioma.

Desde entonces, pasé a usar el inglés para nombrar identificadores. Te guste o no, es la "koine" de la programación, la ingeniería y en general las cosas técnicas. La mayoría de las API están escritas en inglés y también la mayor parte de la documentación (y probablemente los mejores recursos que puede encontrar también estén en inglés). Como un buen comentario, mantiene su código más coherente con el código con el que probablemente interactuará, y creo que tiende a ser más compacto y conciso que otros idiomas como el español (que de otra manera sería mi elección natural).

Por supuesto, si no puedes entender al menos algo de inglés, el problema sigue siendo el mismo, por lo que no es una solución perfecta. Pero, dada la cantidad de desarrolladores de muchos países diferentes, es probable que el idioma común para comunicarse (a través del código y, por supuesto, otros medios) sea el inglés. Entonces, elegir el inglés es quizás la mejor opción, aunque no sería la solución perfecta a este problema.

El lenguaje de programación define palabras clave y nombres de clases estándar, y es una buena práctica dar tipos, variables y funciones definidos por el usuario también nombres en inglés (como hablante no nativo, puedo decir ;-).

Así que sí, si todo va bien, podrás leer el código.

Sin embargo, lenguajes como Java y Perl permiten el conjunto Unicode completo para identificadores, por lo que si alguien escribe los nombres de sus clases en kanji, es probable que tenga un problema.

Actualización: para Perl hay un módulo de bromas que le permite escribir Perl en latín. Pero en realidad es solo eso, una broma. Nadie usa este tipo de cosas en serio.

Segunda actualización: la idea de lenguajes de programación localizados no es tan ridícula. El lenguaje de macros de Excel está localizado, pero afortunadamente está almacenado en un idioma canónico (inglés) en el archivo, por lo que la localización es solo una capa por encima de lo normal. Tales cosas solo tienen sentido para los "programas" pequeños, para los programas "reales" se vuelve difícil de mantener.

En realidad no son algunos lenguajes de programación no basado en Inglés (Wikipedia)

Soy noruego, pero siempre he usado inglés para todo el código excepto para la salida (ignorando algunos códigos tontos de la escuela). En realidad, suelo escribir todo en inglés y luego traducirlo a mi idioma nativo, usando gettext (o algo así).

Soy británico y un problema con el que nos encontramos a menudo es el choque ortográfico estadounidense / británico. Esto ocurre a menudo con términos relacionados con la programación como Inicializar () o Inicializar (), Analizar () o Analizar (), etc. Esto puede (ha) conducir a problemas al intentar anular métodos y, a veces, es difícil de detectar.

Dado que el marco (en nuestro caso C #) fue diseñado por estadounidenses, descubrimos que es mejor ser coherente y usar la ortografía estadounidense. Incluso adoptamos el color.

Tenemos una combinación de nacionalidades en nuestros equipos de desarrollo y la mayoría de las personas no británicas tienden a la ortografía estadounidense de forma natural.

AppleScript estuvo una vez disponible en dialectos francés y japonés. No sé por qué fue retirado.

Llevando esto al siguiente nivel, ¿qué hay de poder sustituir símbolos?

Después de ver lenguajes como Brainf ** k y Whitespace , pensé en hacer un lenguaje como este: sería idéntico a C excepto que usa llaves de cierre para abrir, llaves de apertura para cerrar, intercambiar los significados de + y -, * y / ,; y:,> y <, etc.

El concepto no es más que un compilador de C alterado y truculento. Pero, al igual que pensar en las palabras clave de manera diferente, lo desafía a repensar algunas suposiciones básicas si nunca antes había pensado en tales cosas. Ex:

int foo)int i, char c( }
    int six = 2 / 3:
    int two = six + 4:
    if )i > 0( }
        printf)"i is negative"(:
    {
{

Estoy en un equipo francés desarrollando un sistema de software en C #. A pesar de que las palabras clave del lenguaje de programación son aparentemente en inglés, imagino que tendría grandes dificultades para leer el código, ya que todos los nombres de funciones, variables, comentarios de código, tablas y columnas de bases de datos, especificaciones técnicas, protocolos, etc., están todos en Francés, incluidos esos encantadores caracteres acentuados ç, é, è, ù, etc. Ni siquiera estoy seguro de si el sistema funcionaría en otro lugar debido a errores de localización, como confiar en que la coma es el separador decimal predeterminado.

De lo contrario, WinDev es una plataforma de programación popular en Francia, y su lenguaje de programación WLanguage tiene palabras clave en francés o inglés, vea un ejemplo aquí: texto del enlace

El único idioma que vi localizado es Excel con sus macros. Si intenta sumar una columna usando una versión italiana de Office, debe escribir SOMMA(A1:A10)y no SUM. Es una pena.

Por cierto, solo porque es divertido, así es como debería verse su código con palabras clave italianas:

se (i < size){
    commuta
        caso 1:
            stampa "hi there"
        normalmente:
            stampa "no, thank you"
} altrimenti {
    stampa "yes, thank you"
}

He visto VBA traducido a comandos similares al español. es una de las cosas más feas jamás vistas. Me avergonzaría tener algo como esto en mi computadora.

PD: Creo que el español es un idioma mucho más agradable que el inglés; pero traducir está mal

Bueno, como señalaron otros, es probable que las palabras clave y las llamadas al sistema permanezcan en inglés.

Sin embargo, comprender las palabras clave del idioma es solo una pequeña parte para comprender el código. Los nombres de las variables, los nombres de las funciones y los comentarios corren el riesgo de estar en el idioma nativo del autor.

Editar : Regresé a mi juventud, donde fui a las tablas de mapeo de mi TRS-80 BÁSICO incorporado para cambiar las palabras clave al francés. Podría cambiar todas las palabras clave, pero no pude agrandar ninguna de ellas. Hecho para programas divertidos.

No te burles de esto. Hace algunos años, Microsoft había anunciado G # (Sharp alemán) - C # con palabras clave alemanas y API. Por supuesto, era una broma de April Fools, pero todo el sitio sobre eso parecía tan real y profesional (y estaba en microsoft.com). De miedo.

En el trabajo, utilizamos dos sistemas de bus de campo, ambos desarrollados en países de habla alemana, que tienen una mezcla aterradora de alemán e inglés para los identificadores, incluidos algunos adorables falsos amigos. Es un desastre.

No, las palabras clave e identificadores en inglés están bien. Aunque algunos podrían discutir si debería ser Color o Color :)

En varios proyectos de VBA en los que he trabajado (sí, muy temprano en mi carrera) tuvimos que detectar la versión de Office que estaba instalada en la máquina del usuario y cambiar las fórmulas utilizadas en las hojas de datos en consecuencia.

Como programo en portugués, "SUM" tendría que traducirse a "SOMA" y así sucesivamente. No puedo imaginar el trabajo necesario para que esto suceda en varios idiomas. ¿Alguien más ha sufrido este problema?

Hay algunos idiomas que tienen palabras clave traducidas. Fórmulas de Excel, por ejemplo. Si escribe algunos cálculos en una hoja de cálculo, estará en su idioma.

Afortunadamente, esto no es una práctica general, e incluso los que no hablan inglés como yo agradecen a Dios que existe un lenguaje estándar para las palabras clave:

• es más fácil compartir tu trabajo.
• evita que la documentación se convierta en una pesadilla más grande de lo que ya es.
• Las palabras y oraciones en inglés suelen ser breves y sintácticamente pragmáticas. En literatura, los idiomas latinos son mucho más hermosos, pero en lo técnico, el inglés es genial.

Y donde parar ¿Te imaginas una C en griego antiguo?

Las palabras clave deben permanecer en un idioma, y ​​bueno, comenzó con el inglés, déjelo así. Esto podría haber sido peor (¿idioma asiático?). Entonces tenemos que escribir métodos y comentarios en inglés. Ok, más trabajo para nosotros, pero al menos la base del código internacional sigue siendo congruente.

Sin embargo, hay un caso en el que utilizar nombres de métodos y comentarios en la lengua materna puede ser una buena práctica: en un país del tercer mundo. Me voy a Senegal en unos meses para gestionar un proyecto de Django. Senegal tiene una tasa de analfabetización enorme y, por lo tanto, ya es genial que inviertan energía en mejorar sus conocimientos de programación. El francés es el idioma nativo aquí, por lo que sería ineficaz obligarlos a aprender computación Y una nueva lengua al mismo tiempo.

Por cierto, ese sería su código con palabras clave en francés:

Si (i < taille) {
    cas par cas :
        cas 1:
            afficher "salut"
        défaut:
            afficher "non merci"
} sinon {
    afficher "oui, merci"
}

No es que traducir las palabras clave no tenga nada que ver con traducir las cadenas. Por supuesto, tenemos "hola, allí" traducido a nuestro idioma. Los codificadores europeos incluso tienden a usar I18N mucho más que los estadounidenses, por lo que su servicio puede llegar a un público más amplio.

En términos generales, la mayoría de los programadores se adaptan a la forma en inglés. Aprendí a programar cuando tenía 7 años y solo hablaba hebreo (que es de derecha a izquierda) y no hablaba inglés, lo que hizo que fuera una experiencia fascinante.

El problema que suele tener es con la documentación, las variables y los nombres de las funciones. He visto muchas variables en otros idiomas usando el alfabeto inglés.

El único idioma con el que estoy familiarizado que realmente se tradujo fue el buen y antiguo Logo (que sigue siendo sorprendente hasta el día de hoy).

Cuando era niño fuimos a Francia, y en un museo al que fuimos, recuerdo haber encontrado una pantalla que te mostraba cómo escribir programas de computadora. El lenguaje era una especie de variante BASIC y lo recuerdo claramente usando POUR en lugar de FOR, y así sucesivamente. Tenía 7 años y acababa de aprender BÁSICO, ¡¡y me parecía completamente natural que los franceses tuvieran su propio dialecto como este !!

Supongo que puede haber sido LSE lo que vi.

El lenguaje de programación de Filemaker está localizado. Los scripts (¡y los datos!) Se almacenan en una terrible forma "canónica".

Entonces, si escribe un script en la versión estadounidense, luego lo abre en la versión francesa, todas las palabras clave y los nombres de las funciones integradas estarán en francés. ¡¿Pero por qué no funciona ?! ¡Ajá! La versión francesa utiliza "," como punto decimal y, por tanto, para evitar ambigüedades utiliza ";" para separar los argumentos de la función, donde la versión americana usa "." y "," respectivamente. Esta conversión la tienes que hacer tú mismo.

Así que trabajas a través de la interfaz de edición de scripts increíblemente mala (no puedes escribir scripts como archivos de texto) para arreglar todas estas cosas. ¡Corre! ¡Excelente! ¡Los resultados están todos mal! ¡Oh no! ¡Ajá! La fecha del 7 de enero de 2004 que ingresó en la versión estadounidense se interpreta como 1 de julio de 2004; aparentemente, las fechas no solo se muestran sino que se almacenan en un orden que depende de la configuración regional. ¿Te estoy tomando el pelo ? No.

[Nota: Filemaker 8 y 9 pueden estar cuerdos; solo trabajé con 3 - 7.]

Su pregunta es interesante con respecto a Perl porque su sintaxis está diseñada para seguir el lenguaje natural (inglés). Me pregunto si eso lo hace más difícil para los que no hablan inglés ...

Por supuesto, Perl y Perlers se niegan a seguir las reglas convencionales. El científico loco Damian Conway escribió el módulo Lingua :: Romana :: Perligata que usa la magia negra de los filtros fuente para permitirle escribir Perl en latín.

Aquí en Australia todavía necesitamos deletrear color como color . Sin embargo, me resulta molesto cuando otros desarrolladores (australianos), que trabajan en un proyecto australiano, deciden que los nombres de las variables internas deben escribirse al estilo americano.

No tendría sentido, en mi humilde opinión, utilizar una sintaxis de lenguaje . Simplemente acabaría con cualquier tipo de portabilidad.

La única excepción son los lenguajes educativos, como LOGO. Fueron diseñados para facilitar el aprendizaje, por lo que la portabilidad no es un problema.

Leí mucho código, pero el problema siempre está en los nombres y comentarios de las variables / métodos, si están comentando su código en su propio idioma, usando caracteres especiales como japonés o cirílico, ¡estamos en problemas! pero las palabras clave creo que permanecerán en inglés como están.

en italiano

se (i < dimensione){
    scegli
        caso 1:
            stampa "ciao"
        mancante:
            stampa "no, grazie"
} altrimenti {
    stampa "sì, grazie"
}

Para confirmar las preocupaciones de algún poster anterior he visto un código de Fortran con una macro incluida para traducir todas las palabras clave del inglés al francés. Permítame no continuar con esto.

También tuve que trabajar con un código que contenía identificadores simultáneamente en italiano, alemán, inglés y francés, no solo porque se desarrolló en muchos lugares diferentes, sino también porque el desarrollador principal pensó que era divertido y lo ayudó a no duplicar nombres de identificadores ( por supuesto, con una rutina de 2000 líneas de largo ...)

Creo que WordBasic fue localizado. WordBasic se usó para escribir macros en Word antes de que se usara VBA.

Si lo recuerdo correctamente, solo WordBasic escrito en la versión en inglés se ejecutaría en todas las versiones localizadas. Si escribiera una versión holandesa, solo podría ejecutarla en una palabra holandesa.