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

13

Personalmente, encuentro el código de lectura lleno de identificadores Unicode confuso. 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 constantemente me doy cuenta de la falta (o la presencia) de la compatibilidad con los identificadores Unicode en las listas de (des) ventajas de varias implementaciones de lenguaje (como realmente importa). No lo entiendo: ¿por qué tanta atención?

    
pregunta Egor Tensin 13.11.2011 - 18:02

8 respuestas

15

Cuando piensas en Unicode, piensas en caracteres chinos o rusos, lo que te hace pensar en un código fuente escrito en ruso que has visto en Internet y que no se puede utilizar (a menos que sepas el ruso).

Pero si unicode puede usarse de manera incorrecta, no significa que sea malo por 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 sigue siendo 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();

en lugar de:

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 mi mouse, mientras que en el segundo caso, no tengo idea de dónde encontrar esos símbolos y me vería obligado a confiar en el ratón para ir y buscarlos en la lista de finalización automática.

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 , siendo más corto y más legible. Además, para dominios específicos con muchos símbolos, métodos abreviados de teclado puede 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 sepa bien el chino). Pero en algunos lenguajes de programación, los símbolos Unicode pueden ser útiles. Un ejemplo son las notas a pie de página¹.

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

    
respondido por el Arseni Mourzenko 01.01.2012 - 11:46
8

Yo diría:

  1. para facilitar a los no profesionales y los principiantes 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ódigo como:

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

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

    double ύψος, βάρος;
    cin >> ύψος >> βάρος;
    
  2. ¿No te gusta?

    class ☎ {
    public:
        ☎(const char*);
        void                                     
respondido por el ybungalobill 31.12.2011 - 22:13
5

Por supuesto, cada compilador moderno debe lidiar con el código fuente de Unicode hoy. Por ejemplo, las constantes de cadena pueden necesitar contener caracteres Unicode. Pero una vez que se logra esto, ¿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 en que: 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 deben hacer el control de calidad y no pueden leer ninguno de los 3 alfabetos anteriores!

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

    
respondido por el Ingo 21.11.2011 - 15:25
4

Creo que tiene mucho sentido permitir caracteres Unicode en cadenas y comentarios. Y si lexer & parser tiene que ser compatible con Unicode para eso, el escritor del compilador probablemente obtenga soporte de caracteres Unicode en identificadores de forma gratuita, por lo que parece una limitación arbitraria permitir solo caracteres ASCII en identificadores.

    
respondido por el nikie 14.11.2011 - 08:53
4

En lo que a mí respecta, esto es puramente por razones de marketing . Y, además, puede hacer que nuestras vidas sean más difíciles.

Los argumentos de marketing

¿Conoces esta loca lista 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 tictac y cruces y concluir con razón que dado que X tiene más tics que Y debe ser mejor.

Bueno, el soporte de 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érico, 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, por lo tanto, pueden presumir: "¡Ah, con Y no tienes soporte de Unicode para tus identificadores! En X lo hacemos, ¡para los estudiantes es mucho más fácil!"

La falacia de la accesibilidad

Lamentablemente, el argumento de la accesibilidad es falaz.

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

La programación se trata de comunicar

Su programa no solo está diseñado para el compilador (lo que podría preocuparse menos por los identificadores que usa), sino que también está dirigido a sus compañeros. Necesitan poder leerlo y entenderlo.

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

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

La programación requiere comprensión

La accesibilidad y la iniciación requieren que te bases en las bibliotecas para hacer el trabajo pesado por ti: no quieres reinventar una capa IO para leer / escribir en la consola en tu primera asignación.

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

Si respondes árabe marroquí, me sorprenderé.

A menos que solo confíe en las conferencias a las que asiste, y en los que presenten documentación completa sobre cada función de biblioteca que necesitará usar (y quizás incluso bibliotecas traducidas), entonces tendrá que aprender un Modicrum de la lengua inglesa. Pero entonces, probablemente ya lo hiciste mucho antes de comenzar este curso de programación.

Inglés es ...

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

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

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

Still...

Sí, como se había discutido 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 reclamaciones de marketing. También es fácil, ya que el analizador ya es Unicode para cadenas y comentarios, por lo que la mayoría da el salto.

Y podría haber un beneficio para ciertos usuarios.

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

    
respondido por el Matthieu M. 01.01.2012 - 15:01
3

¿Cómo vas a escribir identificadores ASCII en un teclado chino? Unas pocas palabras clave de idioma son 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 lo que quieran. No es de tu incumbencia en qué idioma se encuentra.

Si te sientes tan confundido al leer el código con identificadores que tienen símbolos de los idiomas de otras personas, entonces estoy seguro de que entiendes exactamente cómo se confunden ellos cuando tienen que usar identificadores con símbolos desde su idioma en.

    
respondido por el DeadMG 13.11.2011 - 18:38
2

De acuerdo con PEP 3131 - Soportar identificadores no ASCII con fecha de 2007, la primera parte de los estados de razón:

  

El código de Python lo escriben muchas personas en el mundo que no están familiarizadas con el idioma inglés, o que incluso están familiarizadas con el sistema de escritura latina. Tales desarrolladores a menudo desean definir clases y funciones con nombres en sus idiomas nativos, en lugar de tener que encontrar una traducción al inglés (a menudo incorrecta) del concepto que quieren nombrar. Al utilizar identificadores en su idioma nativo, mejora la claridad del código y la capacidad de mantenimiento del código entre los hablantes de ese idioma.

Todavía no he investigado otros idiomas, pero debería estar entre las razones por las que agregaron el soporte.

    
respondido por el 吴烜_中文编程 23.12.2018 - 02:12
1

Realmente haría la vida más fácil (para algunos de nosotros, de todos modos) si el compilador no soportara 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 ingresa 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 tengo una respuesta fácil, me temo.

Los comentarios de derecha a izquierda de Unicode 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, quizás, si no hubiera apoyo en primer lugar? Una vez más, no es una llamada fácil.

    
respondido por el sq33G 01.01.2012 - 09:57

Lea otras preguntas en las etiquetas