Palabras clave sin distinción entre mayúsculas y minúsculas en un idioma [cerrado]

Estamos tratando de escribir un lenguaje de script personalizado. Se ha sugerido que el lenguaje sea indulgente proporcionando palabras clave que no distingan entre mayúsculas y minúsculas .

Personalmente, no me gusta la idea, pero hay pocas personas en mi equipo que se inclinan hacia ella y dicen que hará feliz al usuario final. Se dan ejemplos de lenguajes como FORTRAN, BASIC, SQL que dicen que no distinguen entre mayúsculas y minúsculas.

¿Es esta una buena idea?

Pregúntese quién es el usuario final. Si está destinado a ser escrito por alguien con experiencia en programación en C o Javscript, o experiencia en TI en Unix, entonces la distinción entre mayúsculas y minúsculas es probablemente lo correcto, porque eso es lo que el usuario espera. Pero para la mayoría de los usuarios finales, incluso los usuarios avanzados, esto será confuso.

VB / VBA / VBScript distingue entre mayúsculas y minúsculas, y esta fue una decisión tomada para permitir que los no programadores se familiaricen fácilmente con el lenguaje. Las fórmulas de Excel, no exactamente los scripts, pero lo más cerca que se encuentran muchos usuarios, no distinguen entre mayúsculas y minúsculas. En la mayoría de los casos, la elección del caso puede hacer que el texto se vea más o menos profesional y pulido, pero el caso en sí mismo no cambiará el significado semántico de las palabras. Es por eso que creo que los no desarrolladores se verán confundidos por un lenguaje de script que distingue entre mayúsculas y minúsculas.

Nuevamente, esta no es una opción técnica. Es una elección de gestión de productos que deben hacer las personas que conocen bien al público objetivo.

Debe decidir según la experiencia del usuario que desee presentar, no lo fácil o difícil de implementar.

Si facilitará que sus usuarios tengan insensibilidad a mayúsculas y minúsculas, entonces eso es lo que debe implementar.

Como un caso en punto, SQL no distingue entre mayúsculas y minúsculas. Esto hace que sea muy fácil de usar en un entorno interactivo.

Otra forma de ver esto es si alguna vez habrá una diferencia entre keywordy Keyworden su idioma, y ​​¿será esta diferencia significativa para el usuario? Para un lenguaje de secuencias de comandos, diría que la respuesta es "no".

Los lenguajes de programación deben ser sensibles a mayúsculas y minúsculas, punto. Las personas pueden adaptarse a esto muy fácilmente: simplemente deben recordar trabajar principalmente en minúsculas y tener cuidado con los identificadores de mayúsculas y minúsculas en las API existentes.

Una vez parecía obvio hacer que los idiomas no distingan entre mayúsculas y minúsculas. Esto se debe a que las minúsculas no estaban disponibles en todos los sistemas informáticos y sus dispositivos de E / S (teclados, impresoras y dispositivos de visualización). Las implementaciones de lenguaje de programación tenían que aceptar programas escritos en mayúsculas, ya que solo eso podía mostrarse o imprimirse. Y para eso tenían que ser mayúsculas y minúsculas, porque aceptar mayúsculas y mayúsculas y minúsculas al mismo tiempo significa rechazar minúsculas. Las minúsculas eran algo que los programadores querían, pero que no siempre podían tener. Nadie realmente quería trabajar con programas que gritaban en mayúsculas; fue solo una limitación de hardware.

Durante un tiempo, era común incluso plegar cajas en los terminales. Si un terminal solo pudiera mostrar mayúsculas, pero tuviera que iniciar sesión en un sistema informático que admita mayúsculas y minúsculas, el terminal plegaría las minúsculas a mayúsculas. ¿Crees que esto fue hace tanto tiempo? "Al igual que el Apple II, el Apple II Plus no tenía funcionalidad en minúsculas". (http://en.wikipedia.org/wiki/Apple_II_Plus) Cuando los usuarios de las primeras computadoras Apple marcaron un BBS que tenía contenido en mayúsculas y minúsculas, el emulador de terminal (o host) tuvo que doblar todo a mayúsculas. Los mensajes escritos en mayúsculas eran comunes en los tableros de anuncios en esos días. Esta funcionalidad todavía se encuentra en sistemas operativos tipo Unix, como el kernel de Linux. Por ejemplo, escriba el stty olcucen su indicador de shell.La disciplina de línea Unix tty puede asignar minúsculas a mayúsculas en la salida, y puede asignar mayúsculas a minúsculas en la entrada. Esto le permite trabajar en un lenguaje de programación en minúsculas, en un terminal que no tiene minúsculas.

La insensibilidad a mayúsculas y minúsculas es un concepto desactualizado de una era informática pasada que no funciona muy bien en el mundo moderno de la informática internacionalizada. ¿Extiende eso a otros idiomas? ¿Qué tal el francés? ¿Consideras que È y è son equivalentes? O japonés? ¿Considera que hiragana y katakana son solo casos, de modo que フ ァ イ ル y ふ ぁ い る son el mismo identificador? El soporte para tal locura complicará enormemente su analizador léxico, que tendrá que tener mapas de equivalencia de casos para todo el espacio Unicode.

Tenga en cuenta que las matemáticas distinguen entre mayúsculas y minúsculas. Por ejemplo, la sigma en mayúscula puede denotar suma, mientras que la sigma en minúscula denota otra cosa, como la desviación estándar. Esto puede ocurrir en la misma fórmula sin crear ninguna dificultad. (¿El lenguaje de programación hará que Σ y σ sean equivalentes?)

La ortografía inglesa es sensible. Por ejemplo, muchos sustantivos propios corresponden a sustantivos ordinarios o incluso a otras partes del discurso. "mayo" es un verbo, pero "mayo" es un mes, o el nombre de una mujer. Además, si se escriben acrónimos o abreviaturas en minúsculas, puede ser confuso. SAT significa prueba de aptitud escolar, mientras que "sat" es el participio pasado de "sentarse". Las personas inteligentes prestan atención a los detalles y capitalizan adecuadamente.

Básicamente, cualquier nuevo lenguaje de programación creado desde 1985 que no distinga entre mayúsculas y minúsculas es PARA AQUELLOS QUE TODAVÍA GRITAN EN CORREOS ELECTRÓNICOS Y PUBLICACIONES SIN UN SEGUNDO PENSAMIENTO.

¿Qué sucede si su idioma alguna vez se usa como un objetivo de generación de código para traducir código en otro idioma y ese otro idioma distingue entre mayúsculas y minúsculas? Tendrá que transformar de alguna manera todos los nombres para capturar la distinción. (Por lo tanto, afirmar que esta no es una decisión técnica, y solo es cuestión de las preferencias emocionales del público objetivo, es ridículo).

Mire los molestos problemas causados ​​por el manejo de casos en Windows, cuando los archivos se importan desde otro sistema operativo. Eso es un problema técnico. Los sistemas de archivos sensibles a mayúsculas y minúsculas tienen un problema con los datos externos que no distinguen entre mayúsculas y minúsculas.

Common Lisp ha dado con el enfoque ideal: los nombres de los símbolos distinguen entre mayúsculas y minúsculas, pero cuando se leen los tokens, se doblan a mayúsculas. Esto significa que las fichas foo, fOO, FOOy Footodos denotan el mismo símbolo: el símbolo cuyo nombre se almacena como la cadena de caracteres "FOO". Además, este comportamiento es solo la configuración predeterminada de la tabla de lectura. El lector puede doblar letras en mayúsculas, minúsculas, invertir las mayúsculas o conservarlas. Las dos últimas opciones dan lugar a un dialecto sensible a mayúsculas y minúsculas. De esta manera, los usuarios tienen la máxima flexibilidad.

El factor determinante real es con qué frecuencia querrás tener varias cosas con el mismo nombre. La insensibilidad a mayúsculas y minúsculas funciona en SQL porque no es frecuente que desee una columna con el nombre SELECT. Sería molesto en Java porque todas las demás líneas se ven Object object = new Object(), donde desea que el mismo nombre haga referencia a una clase, una instancia y un constructor.

En otras palabras, la distinción entre mayúsculas y minúsculas es principalmente útil para sobrecargar un nombre, y la sobrecarga es principalmente útil en proyectos grandes y complejos. Para un uso más infrecuente, como un lenguaje de secuencias de comandos, la insensibilidad a mayúsculas y minúsculas puede hacer que la programación sea mucho más simple.

Una vez hice un lenguaje de reglas donde los identificadores no solo distinguen entre mayúsculas y minúsculas, sino que también insensibilizan los espacios en blanco. También permití crear alias que se referían al mismo identificador. Por ejemplo, ProgrammersStackExchange, los programadores apilan el intercambio y PSE resolvieron exactamente el mismo símbolo y podrían usarse indistintamente.

Para mi dominio, eso funcionó muy bien, porque el dominio tenía muchas formas extremadamente conocidas de referirse a lo mismo, y los conflictos de nombres eran raros. Nadie se sorprendería al escribir una consulta con un nombre y hacer que el resultado use otro. Tener soporte de lenguaje hizo que la traducción entre el dominio y el lenguaje de programación fuera muy fácil. Sin embargo, también dificultaba ciertas tareas, como encontrar todas las referencias a una variable. Afortunadamente, en mi caso ese tipo de situaciones rara vez surgieron, o fueron bastante fáciles de construir herramientas de soporte para ayudar, pero debes tener en cuenta tu propia situación.

Supongamos que su lenguaje de script distingue entre mayúsculas y minúsculas: ¿va a crear un compilador o un verificador de sintaxis que le dirá al usuario si comete un error al usar el caso incorrecto en un nombre de variable o una palabra clave? Si no, ese sería un argumento muy fuerte para hacer que el lenguaje no sea sensible a mayúsculas y minúsculas.

¿Puedes declarar variables sobre la marcha? Si es así, argumentaría en contra de mayúsculas y minúsculas, como rastrear un error causado por

ATypo = 42; 

Opuesto a

Atypo = 42; 

está solicitando innecesariamente el tiempo de depuración, cuando tener las dos declaraciones equivalentes simplemente hace la vida más fácil.

Se dan ejemplos de lenguajes como FORTRAN, BASIC, SQL que dicen que no distinguen entre mayúsculas y minúsculas.

La razón por la que FORTRAN y SQL (y COBOL) no distinguen entre mayúsculas y minúsculas es que fueron diseñados originalmente para su uso en máquinas donde los juegos de caracteres normales solo tenían letras mayúsculas. La insensibilidad de mayúsculas y minúsculas en esos idiomas (al menos) es más un artefacto histórico que una elección de diseño de lenguaje.

Ahora podría argumentar que la insensibilidad a mayúsculas y minúsculas es más indulgente, pero la otra cara es que la sensibilidad a mayúsculas y minúsculas da como resultado un código más legible porque FOCALIZA EL CODIFICADOR PARA UTILIZAR LA CAPACIDAD DE CONFIGURACIÓN.

La sensibilidad a mayúsculas y minúsculas se considera dañina.

La vida no distingue entre mayúsculas y minúsculas y tampoco lo son los usuarios o programadores.

Los lenguajes sensibles a mayúsculas y minúsculas son un accidente histórico, de sistemas restringidos que encontraron difíciles las comparaciones entre mayúsculas y minúsculas. Esta desventaja ya no existe, por lo que no hay razón para volver a crear un sistema informático que distinga entre mayúsculas y minúsculas.

Diría que la sensibilidad a mayúsculas y minúsculas es mala , ya que antepone la conveniencia de la computadora a la del usuario.

(Relacionado, recuerdo hace unos años, un genio se negó a pagar la factura de su tarjeta de crédito porque su nombre estaba en mayúsculas, pero lo deletreó en mayúsculas y minúsculas. Por lo tanto, argumentó, no estaba dirigido adecuadamente a él y no estaba una demanda válida de pago. El juez trató el argumento como se merecía).

Desde mi experiencia personal, no veo una gran diferencia entre los idiomas sensibles a mayúsculas y minúsculas.

Lo más importante es la nomenclatura y las convenciones estructurales que un programador debe mantener en su código y ningún compilador o analizador lo comprueba por él. Si te apegas a algún tipo de reglas, sabrás fácilmente un nombre propio (no pensarás si nombraste una variable checkOut o CheckOut) y tu código probablemente distinga entre mayúsculas y minúsculas y sea más fácil de leer.

No se debe usar CheckOut y checkOut y checkout y cHeCkOuT y CHECKOUT en el mismo significado. Hará daño a la lectura y hará que la comprensión de ese tipo de código sea más dolorosa (pero hay algo peor que uno puede hacer para destruir la lectura del código).

Si usa algún tipo de reglas, verá a simple vista, por ejemplo:

CheckOut.getInstance () - es un método estático de una clase llamada checkOut.calculate () - es un método de un objeto guardado en un campo variable o público llamado _checkOut.calculate () - es un método de un objeto guardado en un campo privado llamado CHECKOUT - es un campo / variable estático o constante final

sin consultar otros archivos o partes de un archivo. Hace que la lectura del código sea más rápida.

Veo que muchos desarrolladores usan reglas similares, en lenguajes que uso a menudo: Java, PHP, Action Script, JavaScript, C ++.

En un caso raro, uno puede estar enojado por la insensibilidad a las mayúsculas y minúsculas, por ejemplo, cuando desea usar CheckOut para un nombre de clase y checkOut para una variable y no puede porque choca entre sí. Pero es un problema de un programador que se usa para distinguir entre mayúsculas y minúsculas y para usarlo en sus convenciones de nomenclatura. Uno puede tener reglas con prefijos o postfijos estándar en un lenguaje que no distinga entre mayúsculas y minúsculas (no programo en VB pero sé que muchos programadores de VB tienen este tipo de convenciones de nomenclatura).

En pocas palabras: veo una mejor distinción entre mayúsculas y minúsculas (solo para lenguajes orientados a objetos) porque la mayoría de los desarrolladores usan lenguajes sensibles a mayúsculas y minúsculas y usan convenciones de nomenclatura basadas en mayúsculas y minúsculas, por lo que les gustaría que un lenguaje sea más sensible a mayúsculas y minúsculas para que sean capaz de cumplir con sus reglas sin algún tipo de modificaciones. Pero es un argumento bastante religioso, no uno objetivo (no basado en inconvenientes reales o buenos aspectos de la distinción entre mayúsculas y minúsculas), porque no veo ninguno cuando se trata de un buen desarrollador, cuando se trata de un DEVeLoPeR bAD se podría producir un código de pesadilla incluso cuando hay mayúsculas y minúsculas, por lo que no es una gran diferencia).

Los lenguajes de programación deben ser insensibles a mayúsculas y minúsculas.

La razón principal por la que muchos idiomas en estos días distinguen entre mayúsculas y minúsculas es simplemente el diseño de lenguaje de culto de carga: "C lo hizo de esa manera, y C es increíblemente popular, por lo que debe ser correcto". Y como en tantas otras cosas, C se equivocó demostrablemente.

Esto es en realidad parte de la filosofía de conducción detrás de C y UNIX: si tiene que elegir entre una mala solución que es fácil de implementar y una buena solución que es más difícil de implementar, elija la mala solución y empuje la carga de trabajar en su desorden el usuario. Esto puede sonar como snark, pero es absolutamente cierto. Es conocido como el "principio de lo peor es mejor", y ha sido directamente responsable de daños por valor de miles de millones de dólares en las últimas décadas debido a C y C ++, lo que hace que sea demasiado fácil escribir software con fallas e inseguridad.

Hacer que un lenguaje no sea sensible a mayúsculas y minúsculas es definitivamente más fácil; no necesita las tablas lexer, parser y symbol para tener que hacer el trabajo extra de asegurarse de que todo coincida de una manera que no distinga entre mayúsculas y minúsculas. Pero también es una mala idea, por dos razones:

• Primero, especialmente si está construyendo un lenguaje de script, un error tipográfico simple en el que llama a algo "myObject" en un lugar y "MyObject" en otro, donde obviamente se refiere al mismo objeto pero es un poco inconsistente con las mayúsculas , no se convierte en un error de tiempo de ejecución. (Esto es infame como un punto de dolor importante en los lenguajes de secuencias de comandos que se equivocan, como Python).
• Segundo, no tener mayúsculas y minúsculas significa que no se puede abusar de mayúsculas y minúsculas para que la misma palabra se refiera a dos cosas diferentes en el mismo alcance simplemente cambiando la capitalización. Si alguna vez tuvo que trabajar con el código de Windows en un entorno C y se encontró con declaraciones feas HWND hwnd;, sabrá exactamente de lo que estoy hablando. Las personas que escriben así deberían ser eliminadas y fusiladas, y hacer que el lenguaje no distinga entre mayúsculas y minúsculas evita que el abuso de mayúsculas y minúsculas llegue a su código.

Por lo tanto, haga un esfuerzo adicional para hacerlo bien. El código resultante será más limpio, más fácil de leer, tendrá menos errores y hará que sus usuarios sean más productivos, ¿y ese no es el objetivo final de ningún lenguaje de programación?

No puedo creer que alguien haya dicho "la distinción entre mayúsculas y minúsculas facilita la lectura del código".

¡Ciertamente no! He mirado por encima del hombro de un colega las variables llamadas Compañía y compañía (compañía de variable pública, compañía de variable privada emparejada) y su elección de fuente y color hace que sea increíblemente difícil distinguir entre las dos, incluso una al lado de la otra.

La declaración correcta debe ser "mayúsculas y minúsculas facilita la lectura del código" Esa es una verdad mucho más obvia, por ejemplo, variables llamadas CompanyName y CompanyAddress en lugar de companyname. Pero ningún lenguaje que conozca te hace usar solo nombres de variables en minúsculas.

La convención más loca que conozco es la "mayúscula pública, minúscula privada". ¡Solo está pidiendo problemas!

Mi opinión sobre los errores es "mejor que algo falle ruidosamente y lo antes posible en lugar de fallar silenciosamente pero parece tener éxito". Y no hay antes que el tiempo de compilación.

Si por error usa una variable en minúsculas cuando pretendía usar mayúsculas, a menudo se compilará si hace referencia a ella dentro de la misma clase . Por lo tanto, puede parecer que tiene éxito tanto en el tiempo de compilación como en el de ejecución, pero está haciendo sutilmente lo incorrecto y quizás no lo detecte durante mucho tiempo. Cuando detectas que hay algo mal

Es mucho mejor usar una convención donde la variable privada tiene un sufijo, por ejemplo, la variable pública de la compañía, la variable privada de la compañía. Nadie va a mezclar accidentalmente los dos, y aparecen juntos en el intellisense.

Esto contrasta con una objeción que las personas tienen a la notación húngara, donde una variable privada prefijada pCompany no aparecería en un buen lugar en el intellisesne.

Esta convención tiene todas las ventajas de la terrible convención de mayúsculas / minúsculas y ninguno de sus inconvenientes.

El hecho de que las personas sientan la necesidad de recurrir a la sensibilidad a las mayúsculas y minúsculas para distinguir entre variables muestra tanto la falta de imaginación como la falta de sentido común, en mi opinión. O, lamentablemente, a la oveja humana le gusta la costumbre de seguir una convención porque "esa es la forma en que siempre se ha hecho"

¡Haz que las cosas con las que trabajas sean claras y obviamente diferentes entre sí, incluso si están relacionadas!

No debe introducir insensibilidad a mayúsculas y minúsculas sin una muy buena razón para hacerlo. Por ejemplo, lidiar con las comparaciones de casos con Unicode puede ser una perra. La distinción entre mayúsculas y minúsculas (o la falta de ella) de los idiomas más antiguos no tiene importancia, ya que sus necesidades eran muy diferentes.

Los programadores en esta era esperan mayúsculas y minúsculas.

La distinción entre mayúsculas y minúsculas hace que el código sea más legible y la programación más fácil.

• Las personas encuentran que el uso apropiado de mayúsculas y minúsculas es más fácil de leer .

• Permite / alienta a CamelCase de modo que la misma palabra con un caso diferente pueda referirse a cosas relacionadas: por lo Car car; tanto, la variable nombrada carse crea de tipo Car.

• ALL_CAPS_WITH_UNDERSCORES indica constantes por convención en muchos idiomas

• all_lower_with_underscores se puede usar para variables miembro u otra cosa.

• Todas las herramientas de programación modernas (control de fuente, editores, diff, grep, etc.) están diseñadas para distinguir entre mayúsculas y minúsculas. Siempre tendrá problemas con las herramientas que los programadores dan por sentado si crea un lenguaje que no distinga entre mayúsculas y minúsculas.

• Si se interpretará el idioma, puede haber una penalización de rendimiento para el análisis del código que no distingue entre mayúsculas y minúsculas.

• ¿Qué pasa con los caracteres no ingleses? ¿Decide ahora no admitir nunca el copto, el chino y el hindi? Le sugiero encarecidamente que haga que su idioma predetermine todo para UTF-8 y que sea compatible con algunos idiomas que tienen caracteres sin mayúsculas o minúsculas. No utilizará estos caracteres en sus palabras clave, pero cuando comience a desactivar la distinción entre mayúsculas y minúsculas en varias herramientas (para encontrar cosas en los archivos, por ejemplo), se encontrará con algunas experiencias surrealistas y probablemente desagradables.

Cual es el beneficio? Los 3 idiomas que menciona son de los años 70 o anteriores. Ningún lenguaje moderno hace esto.

Por otro lado, cualquier cosa que realmente haga feliz al usuario final trae un poco de luz al mundo. Si realmente afectará la felicidad del usuario, entonces tienes que hacerlo.

Si desea que sea realmente simple para los usuarios finales, puede hacerlo mejor que la sensibilidad / insensibilidad a las mayúsculas y minúsculas: ¡eche un vistazo a Scratch ! Unos pocos gatos de dibujos animados y colores más amigables para los negocios, y tienes el lenguaje más amigable que he visto, ¡y no tienes que escribir nada! Solo un pensamiento.