¿Los lenguajes de programación deben ser estrictos o estar sueltos? [cerrado]

Los diferentes tipos de idiomas tienen diferentes usos, por lo que la respuesta a esta pregunta realmente depende de para qué la vas a usar.

Por ejemplo, Perl es un lenguaje muy vago, y lo encuentro muy útil para escribir correcciones rápidas o secuencias de comandos de procesamiento de números. Para proyectos sólidos y sólidos utilizo C #.

Necesita obtener el saldo correcto para el uso objetivo. Cuanto más estricto sea, más tiempo tendrá que gastar en escribir el código, pero obtendrá mayor robustez, reutilización y más fácil de mantener.

Lo que busco en un lenguaje de programación (a diferencia de un lenguaje de scripting) es coherencia y escritura fuerte.

En los lenguajes de programación actuales, es posible omitir el punto y coma, por ejemplo, en ciertos lugares sin volverse ambiguos (la última expresión en un bloque {} es una). Si un lenguaje de programación le permite omitir caracteres en estos casos, un programador ahora tiene un problema adicional; Además de la sintaxis de lenguaje general, ahora tiene que saber en qué casos también se puede omitir partes de la sintaxis.

Este conocimiento adicional no es un problema para el programador que escribe el código, pero se convierte en una carga para cualquiera que tenga que interpretar el código existente en un momento posterior (incluido el autor original después de un tiempo).

Su ejemplo de PHP abre la posibilidad de errores sutiles en un programa cuando la constante key se agregaría en el mismo contexto. El compilador no tiene forma de saber que no es lo que se quería decir, por lo que el problema solo se hace evidente en el tiempo de ejecución en lugar de en tiempo de compilación.

En cualquier lugar donde exista cierta ambigüedad, el compilador debe tener alguna forma de adivinar qué significaba realmente el programador. Cada vez que esto sucede, existe la posibilidad de que el programador realmente haya querido decir algo diferente, pero no haya descartado la resolución de la ambigüedad.

Escribir código lógicamente correcto ya es bastante difícil. La adición de ambigüedades sintácticas puede parecer "amigable" en la superficie, pero es una invitación abierta a introducir errores nuevos, inesperados y difíciles de depurar en el código base. En pocas palabras, sé lo más estricto posible.

En su ejemplo, mencionó que los puntos y coma son opcionales en Python y JavaScript. Para Javascript, al menos, esto no es del todo cierto. Los puntos y coma son tan requeridos en JS como en cualquier otro lenguaje de la familia C. Pero la especificación de lenguaje requiere que el analizador de JavaScript inserte los puntos y coma que faltan en ciertas circunstancias. Esto es ampliamente considerado como algo muy malo porque tiende a malinterpretar tus intenciones y arruina tu código.

La respuesta a la forma en que deberías hacer que tu idioma sea igual a la respuesta a la pregunta del acento de Texas "¿Qué tan afortunado te sientes, punk?".

Todos los usuarios no tendrían que trabajar tan duro para la coherencia de la codificación si los idiomas no tuvieran tanta variación. No nos gusta cuando los usuarios realizan solicitudes que aumentan innecesariamente la complejidad, ¿por qué debería preguntarse por nuestros lenguajes de desarrollo?

Mi preferencia personal es la capacidad de tener la rigidez suficiente para capturar mis errores tipográficos, pero con la menor cantidad de texto extra posible. Hablo de este problema en enlace .

Dicho esto, estás diseñando tu idioma por ti mismo. Debes hacer que sea lo que quieras que sea.

Me gusta que mis idiomas hagan lo que quiero decir. En general eso se inclina bastante duro hacia lo suelto. También me gustaría poder etiquetar "estricto" en un elemento o bloque para poder depurar / analizar esa área limitada.

En general, tiendo a caer al lado de "Lo que me facilitaría las cosas como programador". Por supuesto que puede significar más de una cosa. En Javascript casi no hay comprobación de tipos, lo que funciona muy bien hasta que te encuentras con un error extraño. Por otro lado, en Haskell hay una gran cantidad de verificación de tipos que pone más trabajo al frente pero ataca algunas clases de errores.

Para ser honesto, vería un montón de idiomas para ver qué hacen y tratar de encontrar un nicho que ninguno de ellos tenga!

No creo que haya una manera correcta de hacerlo, o al menos si no es algo en lo que la gente haya encontrado un consenso todavía. Entonces al crear lenguajes con diferentes tipos de sistemas estamos aprendiendo.

Buena suerte.

Yo sugeriría que un buen lenguaje de programación debería tener reglas estrictas, que se espera que las implementaciones apliquen de manera coherente, pero las reglas deben escribirse de tal manera que sean útiles. También sugeriría que uno debería considerar diseñar un lenguaje para evitar los casos en que la "distancia de Hamming" entre dos programas sustancialmente diferentes sea solo uno. Obviamente, uno no puede lograr tal cosa con literales numéricos o de cadena (si un programador que quiso decir 123 en lugar de 1223 o 13, el compilador no puede saber muy bien qué significó el programa). Por otro lado, si el lenguaje utilizara := para la asignación y == para la comparación de la igualdad, y no use un solo = para ningún propósito legal, entonces se reducirían las posibilidades de asignaciones accidentales que se suponía que debían sean comparaciones y comparaciones accidentales de no hacer nada que se suponía que eran asignaciones.

Sugeriría que si bien hay lugares donde es útil para los compiladores inferir cosas, tal inferencia suele ser más valiosa en los casos más simples y menos valiosa en los casos más complicados. Por ejemplo, permitiendo el reemplazo de:

  Dictionary<complicatedType1,complicatedType2> item =
    new Dictionary<complicatedType1, complicatedType2()>;

con

  var item = new Dictionary<complicatedType1, complicatedType2()>;

no requiere ninguna inferencia de tipo complicada, pero hace que el código sea mucho más legible (entre otras cosas, usar la sintaxis más detallada solo en los escenarios donde se necesita, por ejemplo, porque el tipo de ubicación de almacenamiento no coincide exactamente con el tipo de la expresión que lo crea, ayudará a llamar la atención adicional a los lugares que lo requieran).

Una de las principales dificultades de intentar una inferencia de tipo más sofisticada es que pueden surgir situaciones ambiguas; Yo sugeriría que un buen lenguaje debería permitir que un programador incluya información que el compilador podría usar para resolver tales ambigüedades (p. Ej., Considerando que algunos pronósticos son preferibles a otros), determine que no importan (p. Ej., Porque aunque hay dos posibles las sobrecargas pueden ejecutar un código diferente, el programador ha indicado que deben comportarse de manera idéntica en aquellos casos en que se podría usar), o marcar aquellos (y solo aquellos) que no se pueden manejar de ninguna de las formas anteriores.

Para mí, la legibilidad es lo más importante.

Para alguien con experiencia en el lenguaje, el significado de un fragmento de código debe ser claro sin tener que analizar el contexto en profundidad.

El idioma debe poder marcar los errores con la mayor frecuencia posible. Si cada secuencia aleatoria de caracteres hace un programa sintácticamente correcto, eso no es útil. Y si las variables se crean automáticamente la primera vez que se usan, la ortografía client as cleint no le dará un error de compilación.

Además de la sintaxis, el lenguaje debe tener una semántica claramente definida, y tal vez sea incluso más difícil que decidir sobre una sintaxis decente ...

Buenos ejemplos:

• En Java, "1" es una cadena, 1 es un int, 1.0 es un doble y 1L es un largo. Una mirada y ya sabes lo que es.

• En Java, = es la asignación. Asigna el valor para los tipos primitivos y la referencia para los tipos de referencia. Nunca copia datos complejos ni compara.

• En Java, llamar a un método necesita paréntesis y de esta manera se distingue claramente de las variables, por lo que, si no hay paréntesis, no es necesario buscar una definición de método, solo está leyendo datos.

Malos ejemplos:

• En Java, un símbolo como client puede ser casi cualquier cosa: un elemento de ruta de paquete, una clase o nombre de interfaz, un nombre de clase interna, un nombre de campo, un nombre de método, una variable local e incluso Más. Depende del usuario introducir u obedecer las convenciones de nomenclatura o no.

• En Java, el punto . se usa en exceso. Puede ser separador dentro del nombre del paquete, separador entre paquete y clase, separador entre clase externa e interna, conector entre la expresión de la instancia y el método que se invocará en la instancia, y muchos más.

• En muchos idiomas, las llaves de los bloques if son opcionales, lo que genera errores desagradables si alguien agrega una declaración más al bloque (que no existe realmente).

• Operadores de Infix: a veces tengo que detenerme en una expresión numérica y pensar detenidamente lo que significa, paso a paso. Todos estamos acostumbrados a escribir expresiones matemáticas en notación infija como a * b / c * d + e . La mayoría de las veces recordamos la precedencia de la multiplicación y la división sobre la suma y la resta (pero ¿te diste cuenta de que no estamos dividiendo por c*d , sino dividiéndonos solo por c y luego multiplicándolos por d ?). Pero hay tantos operadores de infijo adicionales con sus propias reglas de precedencia y en algunos idiomas de sobrecarga que es difícil seguirlos. Quizás la aplicación del uso de paréntesis hubiera sido un mejor enfoque ...

Podrías considerar una analogía con el lenguaje natural. En el correo electrónico, ¿eres una gramática nazi? O está de acuerdo con algunos errores gramaticales, tales como infinitivos divididos, conjunciones faltantes o modificadores fuera de lugar. La respuesta se reduce a las preferencias personales.