¿Por qué las declaraciones en muchos lenguajes de programación terminan en punto y coma?

¿Hay alguna razón por la que se eligió un punto y coma como terminador de línea en lugar de un símbolo diferente?

Quiero saber la historia detrás de esta decisión, y espero que las respuestas conduzcan a ideas que puedan influir en las decisiones futuras.

En inglés, el punto y coma se usa para separar elementos en una lista de declaraciones, por ejemplo

Vio a tres hombres: Jamie, que venía de Nueva Zelanda; John, el hijo del lechero; y George, un hombre demacrado.

Al programar, está separando una serie de afirmaciones y utilizando un punto completo podría confundirse fácilmente con un punto decimal. El uso del punto y coma proporciona un método fácil de analizar para separar las declaraciones individuales del programa mientras se mantiene cerca de la puntuación normal en inglés.

Editar para agregar
En los primeros días, cuando la memoria era costosa, el procesamiento era lento y se diseñaban los primeros lenguajes de programación, era necesario dividir el programa en declaraciones separadas para su procesamiento. Algunos idiomas requieren que cada instrucción se coloque en una línea para que el retorno de carro pueda actuar como delimitador de instrucción. Otros idiomas permitieron un formato más libre al diseño del texto y, por lo tanto, requirieron un carácter delimitador específico. Este personaje fue elegido como punto y coma, muy probablemente debido a la similitud con su uso en el idioma inglés (esto tiene que ser una suposición; no estaba allí en ese momento) y como no produjo un conflicto con la otra puntuación marcas y símbolos necesarios para fines matemáticos u otros fines sintácticos.

Editar de nuevo
La necesidad de algún carácter terminador vuelve a los requisitos para analizar el texto del idioma. Los primeros compiladores se escribieron en lenguaje ensamblador o, en algunos casos, directamente en instrucciones de máquina binarias hechas a mano. Tener un carácter especial que identifica el final de la declaración y delimita el fragmento de texto que se está procesando hace que el procesamiento sea mucho más fácil. Como dije anteriormente, otros idiomas han utilizado el retorno de carro o los corchetes. Algol, Pascal, Ada, BCPL, B, C, PL / M y otras familias de idiomas utilizan el punto y coma. En cuanto a cuál fue el primero en usar este personaje en particular, no retrocedo lo suficiente en la historia como para recordarlo. Su elección y adopción tiene perfecto sentido como

• Su uso refleja el uso en la puntuación normal en inglés.
• Otros caracteres (por ejemplo, el punto final) pueden ser confusos ya que ya tienen un uso común (un punto completo también se usa como punto decimal).
• Un carácter de puntuación visible permite el diseño de código de formato libre.
• El uso de un carácter delimitador similar en lenguajes derivados o posteriores se basa en la familiaridad adquirida por todos los programadores que han usado el lenguaje anterior.

Como comentario final, creo que se ha dedicado más tiempo a estas respuestas y comentarios de lo que se dedicó a decidir usar el punto y coma para finalizar una declaración al diseñar el primer idioma que lo utilizó de esta manera.

Muchos lenguajes usan una sintaxis que está modelada después de C (que fue modelada después de B - gracias @Crollster). Como se puede ver en los comentarios, hay una larga cadena de tales lenguajes ... B fue inspirado por PL / I, que fue precedido por ALGOL al usar el ;como separador.

Como en C el terminador de la declaración es ;, estos lenguajes siguen su ejemplo.

En cuanto a por qué se seleccionó como un terminador de declaración en C, posiblemente debido a su uso en inglés "para indicar declaraciones interdependientes" .

C también se inventó en el PDP-11 en un momento en que había una cantidad limitada de memoria disponible para los juegos de caracteres, por lo que los inventores de los lenguajes tuvieron que trabajar dentro de estas limitaciones.

FORTRAN utilizó el retorno de carro para delinear declaraciones. COBOL utiliza período. LISP no usó nada, confiando en paréntesis para todo. ALGOL fue el primer idioma en utilizar punto y coma para separar las declaraciones. PASCAL siguió el ejemplo de ALGOL, usando punto y coma para separar las declaraciones.

PL / I usó punto y coma para terminar las declaraciones. Hay una diferencia, y se ve fácilmente en PASCAL. Ada siguió el ejemplo de PL / I en este artículo, en lugar de ALGOL.

El punto y coma como separador o terminador de enunciados fue rápidamente aceptado por la comunidad informática como una notación útil, y, que yo sepa, cada lenguaje posterior estructurado en bloques siguió el ejemplo de ALGOL y usó punto y coma para separar o terminar enunciados.

Hace muchos años me dijeron que BCPL usaba tanto el punto y coma como el retorno de carro como separadores / terminadores de declaraciones, pero nunca usé el lenguaje yo mismo y no puedo verificar esto. En algún momento, el uso del retorno de carro para separar o terminar las declaraciones se eliminó de los descendientes de BCPL. BCPL engendró B, B engendró C, C engendró C ++, Java, D y una gran cantidad de cosas considerablemente menos pensadas que PASCAL y Ada.

¿Por qué no cualquier otro símbolo?

Algunos idiomas han usado otros símbolos; por ejemplo, las versiones antiguas de BASIC usaban dos puntos.

Sin hacer caso de las pocas excepciones, sin embargo, creo que hay dos razones principales. La primera es que simplemente estás buscando algo inequívoco. En un analizador típico, si se encuentra con un error lo suficientemente grave como para no poder seguir analizando la declaración actual, normalmente intenta sincronizar el analizador simplemente saltando al terminador de la instrucción y reinicia el analizador desde el comienzo de la siguiente declaración. Para eso, desea algo que normalmente no ocurrirá en ningún otro lugar del código, y un punto y coma es un símbolo con poco significado, por lo que es bastante fácil dedicarlo a este propósito.

La segunda razón es algo similar, pero apunta más a las personas que leen / usan el código. Nuevamente, se trata del hecho de que el símbolo real que usa no importa mucho. Hay una ventaja sustancial en la legibilidad que se obtiene al usar el símbolo que su lector está acostumbrado a ver para un propósito particular, cuando y si es posible. Eso no significa que C sea la única sintaxis perfecta y todo lo demás deba seguirla servilmente, pero sí significa que suficientes personas están familiarizadas con ese estilo de sintaxis que un lenguaje vagamente similar gana mucho (y pierde muy poco) siguiendo aproximadamente la misma sintaxis donde puede.

Notaría que esto es muy parecido a diseñar casi cualquier otro programa. Si escribo un programa que usa ventanas de algún tipo, intentaré usar las características nativas de las plataformas de destino. Muchas de las decisiones que encarnan serán en gran medida arbitrarias, y podrían hacerse de manera diferente sin una gran pérdida de funcionalidad, pero igualmente, cambiarlas sin una ganancia sustancial en la funcionalidad solo confunde a los usuarios sin lograr nada útil. Los mismos principios básicos se aplican a "¿qué debería terminar (o separar) las declaraciones en un idioma?" como "¿cómo debería ser una barra de desplazamiento" o "cómo debería funcionar un control de árbol?" En todos estos casos, la decisión es principalmente arbitraria, y la uniformidad proporciona un beneficio sustancial en sí mismo.

Añadiría que sucede lo mismo en muchos idiomas, solo en la forma en que la mayoría de nosotros estamos tan acostumbrados antes de programar que pocas personas piensan en ello. ¿Por qué todos usan "+" para indicar la suma, o "-" para indicar la resta? Porque la forma del símbolo no importa mucho, pero todos los que acuerdan aplicar el mismo significado a cada símbolo importan mucho.

El punto y coma se propuso originalmente en Algol 60 como un separador de declaraciones , no como un terminador.

Antes de Algol 60, el único lenguaje de programación de alto nivel que existía era Fortran, que requería que cada declaración estuviera en una línea separada. Las declaraciones que abarcan varias líneas, como do-loops, se consideraron una rareza y se consideraron como 'bloques de declaración'.

Los diseñadores de Algol 60 se dieron cuenta de que las declaraciones necesitaban una estructura jerárquica (if-then-else, do-loops, declaraciones de casos, etc.) y podían anidarse una dentro de otra. Entonces, la idea de que cada enunciado se sentara en una línea separada ya no tenía sentido. Composición secuencial de enunciados de la forma S1; S2; ... Sn opcionalmente encerrado entre corchetes de inicio y fin se denominaron declaraciones compuestas , y se ajustan a la estructura jerárquica de las declaraciones previstas por Algol 60. Entonces, aquí, el punto y coma es claramente un separador de declaraciones , no un terminador.

Esto dio lugar a problemas en la práctica. Algol 60 también tenía una "declaración vacía" que se denotaba sin escribir nada. Entonces, uno podría escribir " comenzar S1; terminar " donde el punto y coma aparece como si estuviera terminando S1. Pero el compilador Algol 60 realmente lo trató como un separador entre S1 y una declaración vacía invisible que lo sigue. Estas sutilezas fueron un poco demasiado para los programadores prácticos. Habiendo estado acostumbrados a lenguajes orientados a líneas como Assembly y Fortran, realmente pensaron en el punto y coma como un terminador de declaraciones. Cuando se escribieron los programas, generalmente se ponía un punto y coma al final de las declaraciones, así:

    a [i]: = 0;
    i: = i + 1

y el punto y coma realmente parecía un terminador para la primera declaración. Si los programadores trataran el punto y coma como un terminador, entonces una declaración como esta daría un error de sintaxis:

    si i> 0 entonces
      a [i]: = 0;
    más
      a [i]: = 1;

porque el punto y coma termina el "if" y, por lo tanto, el "else" se cuelga. Los programadores estaban completamente confundidos.

Entonces, PL / I, que fue el sucesor de IBM para Fortran orientado a la línea, decidió convertir el punto y coma en un terminador de declaración en lugar de un separador. Los programadores estaban contentos con esa elección. La mayoría de los lenguajes de programación siguieron su ejemplo. (Pascal se resistió a la tendencia, pero su sucesor, Ada, se rindió).

[Nota agregada: el artículo de Wikipedia sobre comparaciones de lenguajes de programación tiene una buena tabla que resume cómo se trata el punto y coma en varios lenguajes de programación.]

Esto es una suposición bastante pura, pero al mirar un teclado QWERTY estándar restringido a valores ASCII, los caracteres naturales para la terminación / separación serían.!?,:; y el carro vuelve. de esos!?: debe ser descalificado de inmediato por tomar múltiples claves y la terminación de la declaración será algo muy común. Los períodos se descalificarían porque se confunden fácilmente con los puntos decimales, lo que los haría innecesariamente complicado para ser un terminador dado el espacio limitado de las computadoras iniciales. los retornos de carro se descalificarían después de que las líneas de código pudieran ser más largas de lo que se puede mostrar en una sola línea en la pantalla, por lo que sería más difícil leer un programa cuando las líneas debían desplazarse horizontalmente, o requerir caracteres adicionales para crear una continuación en la siguiente línea que nuevamente agrega complejidad. esto se va, y; como opciones, de esas, se usa mucho más a menudo por escrito en comparación con; por lo tanto, se elige el punto y coma porque es más fácil de escribir, menos confuso porque agrega significado a un personaje con significado limitado y menos complicado porque realmente no existen casos especiales con su uso.

Se eligió el punto y coma porque era el mejor personaje basado en la pereza y la simplicidad.

Es en gran medida una elección arbitraria. Algunos idiomas han hecho otras elecciones. COBOL termina las declaraciones con el .carácter. FORTRAN, BASIC y Python generalmente terminan las declaraciones con líneas nuevas (con sintaxis especial para declaraciones de líneas múltiples). Y Lisp pone entre paréntesis sus declaraciones entre paréntesis.

La razón principal ;es tan popular como separador / terminador de enunciados es que la mayoría de los lenguajes populares actuales se basan en ALGOL , que utilizó esa convención.

en lugar de un símbolo diferente?

¿Qué otro símbolo podrías elegir?

Los caracteres ASCII # $ @ [] ^ _ `{|} ~ no siempre estuvieron presentes en las codificaciones de caracteres anteriores como ISO 646 .

Los caracteres ()*+-/<=>se usan típicamente como operadores matemáticos y crearían ambigüedades de análisis si se usan como terminadores de enunciados.

product = a * b *  // If '*' were a statement terminator,
c * d *            // Are there two factors, or four?

Se aplicarían problemas similares a 'y ", que generalmente se usan como delimitadores de cadena; ,, que generalmente se usa para separar argumentos de funciones, y ., que generalmente se usa como un punto decimal (o como un delimitador en construcciones como some_struct.some_field).

Eso se va !%&:;?.

Elegir !o ?probablemente no causaría dificultades técnicas, pero su significado en inglés daría un mal humor al programa.

print(x)?  # Yes, you should.
           # It's an IMPERATIVE language; stop questioning my commands.
print(x)!  # OK!  You don't have to shout!

El &sería una elección más sensata como un separador de instrucciones (no terminador), porque

do_thing_a() &
do_thing_b()

puede leerse como un comando para hacer la cosa A y luego hacer la cosa B. Pero la mayoría de los lenguajes con un &operador lo usan como un AND lógico o bit a bit .

El %signo puede causar confusión en declaraciones como interest_rate = 2.99%(que establecería la variable en 2.99lugar de la esperada 0.0299). Por supuesto, el conocido significado matemático de %no impidió que C lo usara como el operador restante.

Entonces eso se va :y ;.

: es una elección sensata, y de hecho se usa como el separador de enunciados intralínea en la mayoría de los dialectos de BASIC.

Pero ;tiene la gramática inglesa de su lado; se puede usar para separar cláusulas dentro de una oración.

En lugar de tratar de responder a su pregunta principal, creo que es mejor centrarse en su pregunta implícita:

Quiero conocer la historia detrás de esta decisión, y espero que las respuestas conduzcan a ideas que puedan influir en las decisiones futuras en el diseño e implementación de lenguajes de programación.

Si desea aprender sobre el diseño del lenguaje de programación y el historial de implementación, y obtener más información sobre el proceso, entonces las actas de las Conferencias de Historia de los lenguajes de programación son un muy buen lugar para comenzar. (Sin embargo, creo que necesitará una membresía de ACM para poder acceder a los procedimientos).

¿Por qué las declaraciones en muchos lenguajes de programación terminan en punto y coma? ¿Hay alguna razón por la que se eligió un punto y coma como terminador de línea en lugar de un símbolo diferente?

Tomando su pregunta principal como una pregunta de ejemplo que podría intentar responder leyendo los procedimientos de HOPL, me gustaría ofrecer el siguiente punto: las personas que diseñan un nuevo lenguaje de programación generalmente lo hacen porque consideran los que saben que son roto / deficiente de alguna manera. Su nuevo lenguaje está, por un lado, diseñado para corregir esta deficiencia. Por otro lado, los diseñadores de idiomas también copiarán elementos de diseño de otros idiomas que consideren buenos, o simplemente no cambiarán aquellos elementos con los que no tuvieron problemas.

Especialmente esa última parte es importante: en lugar de tratar de averiguar qué lenguaje de programación fue el primero en usar punto y coma como terminadores y por qué muchos otros lenguajes de programación lo copiaron, probablemente aprenderá más mirando los lenguajes que no copiaron eso. Por ejemplo, aunque Smalltalk se inspiró mucho en Simula, nocopie su sintaxis y, en particular, su uso de punto y coma como terminadores de sentencias. Cambió los terminadores (separadores realmente) a un punto y usa el punto y coma para otra cosa. Por el contrario, el primer idioma que alguna vez usó un punto y coma como un terminador de declaración puede haber tenido una razón para cambiar esto de lo que se usó en los idiomas anteriores. También es posible que sea el primer idioma en introducir el concepto completo de un terminador de enunciados (o lo hizo independientemente de otros idiomas) y que el punto y coma se haya utilizado por alguna razón que ahora se pierde en el tiempo. (Sospecho que este último es el caso aquí, ya que ninguno de los otros respondedores ha podido desenterrar una cita de la persona que introdujo el punto y coma en lugar de ofrecer suposiciones modificadas sobre por qué el punto y coma era una buena opción). punto, Creo que aprenderá más al ver por qué los diseñadores de idiomas cambiaron las cosas en lugar de por qué las copiaron / conservaron. Cuando las personas cambian cosas que generalmente quieren o tienen que explicar el cambio, mientras que no lo hacen al copiar o mantener las cosas igual porque “¿por qué lo cambiaríamos? ¡así es como se hace!

Se trata de visibilidad.

Los primeros separadores de declaraciones fueron el '.' como en COBOL y nueva línea, retorno de carro en FORTRAN.

El CR demostró ser limitante ya que dificulta el flujo de una declaración en varias líneas.

El punto final causó un problema más interesante. Cuando lees un texto en inglés, tu cerebro procesa las paradas completas en un nivel subliminal, eres consciente de que una oración ha terminado y puedes hacer una pausa para respirar, pero realmente no lo notas. eso lo señaló. También en muchas fuentes el '.' es el carácter más pequeño posible a veces representado como un solo píxel. Los períodos faltantes o adicionales se convirtieron en la causa más común de errores en los programas COBOL.

Entonces, aprendiendo de los primeros errores, ALGOL eligió un terminador específico que permitiría que una declaración fluyera por varias líneas, y eligió uno que fuera visible y fácilmente notado por los lectores humanos. El punto y coma es lo suficientemente grande e inusual en inglés común como para no ser procesado inconscientemente.

Entendí que se eligió porque había una necesidad de un terminador de declaración explícito que no fuera un retorno de carro / nueva línea. En los días de las pantallas de 80 columnas, tener una sola línea de ajuste de código en varias líneas era lo suficientemente común como para que usar \ r o \ n para el terminador de la declaración no funcionara.

Los puntos y comas eran simplemente convenientes porque no se usan en declaraciones lógicas / matemáticas. Como tal, no entran en conflicto con el contenido real de las declaraciones en ningún grado significativo.

Personalmente, creo que el uso continuo del punto y coma, junto con los requisitos de estilo para mantener líneas de menos de 80 caracteres, es francamente estúpido y anacrónico. Los lenguajes como Python han demostrado ampliamente que puede escribir códigos concisos fáciles de entender más fácilmente sin ellos. Además, si tiene problemas con líneas que son más largas que 80 caracteres, necesita un monitor más grande.

Aquí hay dos preguntas: ¿Por qué ALGOL obtuvo punto y coma y por qué otros idiomas fueron después?

La primera pregunta ya está respondida de muchas maneras aquí.

Como el segundo, ALGOL fue muy utilizado como un lenguaje de pseudocódigo para la escritura de algoritmos. Entonces, los puntos y comas pronto se volvieron naturales para los usuarios de diferentes idiomas. Y, naturalmente, fueron tomadas para los idiomas más jóvenes.

Podría estar equivocado, pero creo que esto tiene algo que ver con el hecho de que en muchos ensambladores se utilizó un punto y coma para comenzar un comentario, generalmente colocado después de una instrucción. Todo después de un ;fue un comentario, y ya no es parte de la instrucción en sí.

Entonces es necesario terminar las instrucciones cuando las está escribiendo en un intérprete. Las instrucciones breves (p. Ej., Expresiones matemáticas) podrían terminarse simplemente presionando la tecla Intro, diciéndole al intérprete que la expresión está lista para ser calculada y que produjo un resultado. Pero a veces uno quería ingresar múltiples líneas de código para la instrucción, por lo que una forma de lograrlo era usar algún carácter especial como terminador de la instrucción en lugar de depender solo de la tecla Intro. De esta forma, el usuario podría ingresar más líneas de código a la vez, porque Enter aún no lo envió al intérprete. Solo cuando el intérprete encuentra el carácter final en una línea ingresada con Enter, finalmente lo ejecuta y calcula su resultado.

Ahora combine estas dos cosas juntas, y el punto y coma parece ser una opción obvia para el carácter final: indica dónde termina la parte de instrucción y comienza la parte de comentario, de modo que cuando el intérprete la encuentra en una línea, sabe que puede enrasarse todas las líneas de la expresión almacenadas hasta ahora y ejecutarlas, porque la instrucción acaba de terminar, ahora estamos en un comentario (bueno, al menos hasta el final de esta línea, porque la siguiente línea comenzará en el código modo nuevamente, comenzando una nueva expresión / instrucción).

Esto supone, por supuesto, que fue realmente el punto y coma que la persona que utilizó esta idea de reutilizar como terminadores de instrucciones ha utilizado para comentarios. Habiendo sido cualquier otro personaje, podríamos haber terminado con un terminador de instrucciones diferente.

Inb4: No, esta no es una cuenta histórica. No tengo ninguna evidencia de que esta sea la forma real en que los puntos y comas cobraron vida. Así es como me imagino que podría haber sucedido.

La mayoría de los idiomas tomaron el punto y coma porque ya se usaba ampliamente para ese propósito y el cambio no tenía sentido.

Y teniendo en cuenta los primeros idiomas para hacer esa elección, tendrá que considerar cuáles son las alternativas. Al diseñar un idioma, desea que los caracteres necesarios estén disponibles, y los juegos de caracteres en este momento se codificaron en 6 bits, a menudo con algunos patrones reservados, a menudo con algunos caracteres no definidos firmemente (para una ocurrencia posterior de esto, piense en el variantes nacionales de ISO-646 - la variante de Estados Unidos es muy conocida bajo el nombre de ASCII - el cual reutilizar los códigos de caracteres "comunes" como [, #o $, y ver el efecto en un contexto donde no es sólo la mitad de posiciones de código disponible y letras y dígitos reservando más de la mitad de esos).

Probablemente no haya otro personaje que pueda usarse como separador de enunciados de manera intuitiva ( .probablemente ya sea el único contendiente serio para ese criterio) y sin introducir dificultades de lexing o parsing en un momento en que la teoría de parsing y lexing todavía estaba en elaboración ( .ahora fuera de cuestión debido a su uso en números reales).

Otra razón por la cual usar punto y coma es porque es uno de los caracteres que no requerimos o usamos con más frecuencia.

Supongamos que lo usamos más a menudo como un nombre de variable o algo así y si el punto y coma se hubiera utilizado como una palabra clave o como un operador, habría sido un conflicto de símbolos para el compilador, por lo tanto, era importante usar un símbolo que no sea de uso frecuente en la codificación.

Creo que los lenguajes de programación de estilo C lo hicieron popular y luego los autores de nuevos lenguajes de programación no querían reinventar la rueda y continuaron usándola, hasta ahora.