¿Cuál es el punto de agregar soporte de identificador Unicode a varias implementaciones de lenguaje?

Personalmente, encuentro confuso leer el código lleno de identificadores Unicode. En mi opinión, también evita que el código se mantenga fácilmente. Sin mencionar todo el esfuerzo requerido por los autores de varios traductores para implementar dicho soporte. También noto constantemente la falta (o la presencia) de soporte de identificadores Unicode en las listas de (des) ventajas de diversas implementaciones de lenguaje (como si realmente importara). No lo entiendo: ¿por qué tanta atención?

Cuando piensas en Unicode, piensas en caracteres chinos o rusos, lo que te hace pensar en algún código fuente escrito en ruso que has visto en Internet y que no se podía usar (a menos que sepas ruso).

Pero si Unicode puede usarse de manera incorrecta, no significa que sea malo en sí mismo en el código fuente.

Al escribir código para un campo específico, con Unicode, puede acortar su código y hacerlo más legible . En lugar de:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

puedes escribir:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

que puede no ser fácil de leer para un desarrollador promedio, pero aún así es fácil de leer para una persona que usa símbolos matemáticos a diario .

O, al hacer una aplicación relacionada con la fotografía SLR, en lugar de:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

puede reemplazar la apertura por su símbolo ƒ, con una escritura más cercana a ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Esto puede ser inconveniente : al escribir el código C # general, preferiría escribir:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

más bien que:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

porque en el primer caso, IntelliSense me ayuda a escribir todo el código casi sin escribir y especialmente sin usar el mouse, mientras que en el segundo caso, no tengo idea de dónde encontrar esos símbolos y me vería obligado a depender del mouse para ir y búscalos en la lista de autocompletado.

Dicho esto, sigue siendo útil en algunos casos. currentLens.GetMaximumƒ();de mi ejemplo anterior puede confiar en IntelliSense y es tan fácil de escribir como GetMaximumAperture, más corto y más legible. Además, para dominios específicos con muchos símbolos, los atajos de teclado pueden ayudar a escribir los símbolos más rápido que sus equivalentes literales en el código fuente.

Lo mismo, por cierto, se aplica a los comentarios. Nadie quiere leer el código lleno de comentarios en chino (a menos que usted también sepa chino). Pero en algunos lenguajes de programación, los símbolos Unicode aún pueden ser útiles. Un ejemplo son las notas al pie¹.

^{Certainly Ciertamente no disfrutaría las notas al pie en el código C # donde hay un estricto conjunto de reglas de estilo sobre cómo escribir comentarios. En PHP, por otro lado, si hay muchas cosas que explicar, pero esas cosas no son muy importantes, ¿por qué no ponerlas al final del archivo y crear una nota al pie en el PHPDoc del método?}

Yo diría:

1. facilitar a los no profesionales y novatos que aprenden programación (por ejemplo, en la escuela) y no saben inglés. No escriben código de producción de todos modos. He visto muchas veces códigos como:

   double upsos, baros;
   cin >> upsos >> baros;
   

   Solo deja que el pobre tipo lo escriba en su idioma:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. No te gusta

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

Por supuesto, cada compilador moderno debe tratar con el código fuente Unicode hoy. Por ejemplo, las constantes de cadena pueden necesitar contener caracteres Unicode. Pero una vez que esto se logra, ¿por qué no permitir también los identificadores Unicode? No es gran cosa a menos que el código del compilador dependa de que los caracteres sean códigos de 7 bits.

Pero el OP tiene razón en la medida: ahora es posible que un indio que hable hindi deba mantener un código con identificadores rusos y comentarios en árabe. ¡Qué pesadilla para los chinos pobres que se supone que deben hacer el control de calidad y que no pueden leer ninguno de los 3 alfabetos anteriores!

Por lo tanto, ahora es una tarea organizativa asegurarse de que los identificadores y comentarios de un programa estén escritos en un lenguaje común. No puedo evitarlo, pero creo que esto será inglés por algún tiempo.

Creo que tiene mucho sentido permitir caracteres unicode en cadenas y comentarios. Y si el lexer y el analizador tienen que admitir unicode para eso de todos modos, el escritor del compilador probablemente obtenga soporte de caracteres unicode en los identificadores de forma gratuita, por lo que parecería una limitación arbitraria permitir solo caracteres ASCII en los identificadores.

En lo que a mí respecta, esto es puramente por razones de marketing . Y además, puede hacernos la vida más difícil.

Los argumentos de marketing.

¿Conoces estas listas locas de características que la mayoría de los idiomas presumen? Es bastante inútil en general, porque está tan lejos del lenguaje que no proporciona mucha información específica, pero permite vestir rápidamente las mesas con ticks y cruces y concluir con razón que, dado que X tiene más ticks que Y, debe se mejor

Bueno, el soporte Unicode para los identificadores es una de esas líneas. No importa que, en comparación con el soporte de Lambda, el soporte de programación genérica, etc., puede que no sea mucho, a las personas que dibujan las tablas no les importa la calidad de cada línea, solo el número de ellas.

Y así pueden jactarse: "¡Ah, con Y no tienes soporte Unicode para tus identificadores! ¡En X sí, así que para los estudiantes es mucho más fácil!"

La falacia de la accesibilidad

Desafortunadamente, el argumento de accesibilidad es falaz.

Oh, entiendo que poder escribir "résultatDuJetDeDé" en lugar de "diceThrowResult" (sí, soy francés) puede parecer una victoria a corto plazo ... ¡sin embargo, hay inconvenientes!

La programación se trata de comunicar

Su programa no solo está destinado al compilador (que podría importarle menos los identificadores que utiliza), sino también a sus compañeros. Necesitan poder leerlo y comprenderlo.

• leerlo implica poder visualizar los caracteres que usó, Unicode no es tan compatible con todas las fuentes
• entenderlo significa confiar en los identificadores, a menos que los complemente con comentarios largos, pero eso está violando la regla DRY.

Por supuesto, su compañero de clase puede hablar el mismo idioma que usted (no es obvio, tuve clases de programación con alemanes, españoles, libaneses y chinos), y también su maestro ... pero suponga que de alguna manera está trabajando en casa y de repente necesita ayuda: Internet es genial, puede hablar con miles de miles de personas que conocen la solución, solo responderán si entienden su pregunta. Y también necesitas entender su respuesta.

La programación requiere comprensión

La accesibilidad y la iniciación requieren basarse en las bibliotecas para hacer el trabajo pesado por usted: no desea reinventar una capa de E / S para leer / escribir en la consola en su primera asignación.

• ¿En qué idioma se escriben esas bibliotecas?
• ¿En qué idioma están documentadas esas bibliotecas?

Si contesta árabe marroquí, me sorprenderé.

A menos que solo confíe en las conferencias a las que asiste, y que presenten documentación exhaustiva sobre cada función de biblioteca que necesitará usar (y tal vez incluso bibliotecas traducidas), tendrá que aprender un poco del idioma inglés. Pero entonces, probablemente ya lo hiciste mucho antes de comenzar este curso de programación de todos modos.

Inglés es...

... la lengua franca de los programadores (y la mayoría de los científicos).

Cuanto antes lo admita y lo acepte en lugar de luchar contra él, antes podrá uno realmente aprender y progresar.

Algunos inevitablemente se levantarán en contra de esto, y defenderán con razón su derecho a hablar el idioma de su elección (su idioma materno generalmente), sin embargo, como Babel demostró, cuantos más idiomas se usan, más difícil es la comunicación.

Todavía...

Sí, como se ha argumentado una y otra vez, algunos soportes Unicode (principalmente símbolos) pueden facilitar enormemente la comprensión para las personas que tienen que traducir fórmulas matemáticas o físicas, por ejemplo, en código. Existe el inconveniente de que algunos símbolos están sobrecargados, pero aún podría ayudar.

Entonces por qué ?

Bueno, como se dijo, no se trata realmente de la conveniencia del usuario, sino de las afirmaciones de marketing. También es muy fácil, ya que el analizador ya conoce Unicode para cadenas y comentarios de todos modos, por lo que la mayoría da el salto.

Y puede haber un beneficio para ciertos usuarios.

Pero personalmente solo trataré con código escrito con identificadores en inglés. No me importa si necesita mi ayuda con su código o si su biblioteca es simplemente increíble y podría ganar mucho si la uso: si no puedo entenderlo, tendré que ignorarlo.

¿Cómo va a escribir identificadores ASCII en un teclado chino? Algunas palabras clave de idioma es una cosa, y tener que hacer todo el código de esa manera es otra.

Los programadores deben tener el derecho y la capacidad de llamar a sus variables como quieran. No es de tu incumbencia el idioma en el que está.

Si te sientes tan confundido al leer códigos con identificadores que tienen símbolos de los idiomas de otras personas, entonces estoy seguro de que entiendes exactamente cuán confundidos se sienten cuando tienen que usar identificadores con símbolos de tu idioma.

De acuerdo con PEP 3131 - Soporte de identificadores no ASCII fechados en 2007, la primera parte de Justificación establece:

El código Python está escrito por muchas personas en el mundo que no están familiarizadas con el idioma inglés o que no conocen el sistema de escritura en latín. Dichos desarrolladores a menudo desean definir clases y funciones con nombres en sus idiomas nativos, en lugar de tener que proponer una traducción al inglés (a menudo incorrecta) del concepto que quieren nombrar. Al usar identificadores en su idioma nativo, mejora la claridad del código y la facilidad de mantenimiento del código entre los hablantes de ese idioma.

Todavía no he investigado otros idiomas, pero debería ser una de las razones por las que agregaron el soporte.

Realmente facilitaría la vida (para algunos de nosotros, de todos modos) si el compilador no admitiera Unicode. Los identificadores de derecha a izquierda son horribles. El alfabeto romano combinado y los identificadores Unicode de derecha a izquierda son aún peores.

Lo malo de la falta de soporte es que ciertos asistentes de GUI toman el texto que ingresó para un elemento y lo usan automáticamente como el identificador del elemento. Entonces, ¿qué harían exactamente con el texto Unicode en esos elementos? No hay una respuesta fácil, me temo.

Los comentarios Unicode de derecha a izquierda también pueden ser divertidos. Por ejemplo, en VS 2010, los comentarios XML se muestran (correctamente) como RTL en el código ... pero cuando usa Intellisense para extraer el identificador en otra parte del código, la información sobre herramientas muestra (incorrectamente) LTR. Mejor, tal vez, si no hubiera apoyo en primer lugar? De nuevo, no es una llamada fácil.