El primer compilador fue escrito por Grace Hopper en 1952, mientras que el intérprete Lisp fue escrito en 1958 por Steve Russell, estudiante de John McCarthy. Escribir un compilador parece ser un problema mucho más difícil que un intérprete. Si es así, ¿por qué el primer compilador se escribió seis años antes del primer intérprete?
Escribir un compilador parece ser un problema mucho más difícil que un intérprete.
Eso podría ser cierto hoy, pero diría que no fue el caso hace unos 60 años. Algunas razones por las que:
El punto fundamental es que el entorno de hardware de computación de la década de 1950 lo hizo tal que solo era posible un compilador dado el procesamiento por lotes de las computadoras en ese entonces.
En ese momento, las mejores interfaces de usuario se limitaban principalmente a las tarjetas perforadas y las impresoras de teletipo . En 1961, el SAGE system se convirtió en el primer Pantalla de tubo de rayos catódicos (CRT) en una computadora. Por lo tanto, la naturaleza interactiva de un intérprete no era preferible o natural hasta mucho más tarde.
En la década de 1950, muchas computadoras usaban interruptores en el panel frontal para cargar instrucciones, y la salida era simplemente filas de lámparas / LED, y los aficionados incluso usaban interruptores en el panel frontal y amp; LEDs en la década de 1970. Tal vez esté familiarizado con la infame Altair 8800 .
Otras limitaciones de hardware también hicieron que los intérpretes no fueran factibles. Hubo una disponibilidad limitada extrema de memoria primaria (por ejemplo, RAM) en las computadoras en la década de 1950. Antes del circuito integrado de semiconductores (que no llegó hasta 1958), la memoria se limitaba a memoria de núcleo magnético o memoria de línea de retardo que se midió en bits o palabras , sin prefijo Combinado con la lentitud de la memoria de almacenamiento secundario (por ejemplo, un disco o una cinta), se consideraría un desperdicio, si no fuera imposible tener gran parte de la memoria utilizada para el intérprete, incluso antes de que se cargara el programa que se está interpretando.
Las limitaciones de memoria aún eran un factor importante cuando el líder del equipo de John Backus en IBM creó el compilador FORTRAN en 1954-57. Este innovador compilador tuvo éxito solo porque era un compilador de optimización .
La mayoría de las computadoras en la década de 1950 apenas tenían un Sistema Operativo , por no mencionar las características modernas como el enlace dinámico y la gestión de memoria virtual, por lo que la idea de un intérprete era demasiado radical e impráctica en ese momento .
Addendum
Los idiomas de la década de 1950 eran primitivos. Incluyeron solo un puñado de operaciones pequeñas , a menudo influenciadas por las instrucciones del hardware subyacente o la definición del problema de su uso específico.
En ese momento, las computadoras rara vez eran computadoras de propósito general en el sentido en que pensamos en las computadoras de hoy. El hecho de que fueran reprogramables sin tener que ser reconstruidos se consideraba un concepto revolucionario: anteriormente, las personas utilizaban máquinas electromecánicas (normalmente calculadoras) para calcular o calcular respuestas (la mayoría de las aplicaciones en la década de 1950 eran numéricas en naturaleza).
Desde el punto de vista de Ciencias de la computación, los compiladores e intérpretes son traductores , y su complejidad es aproximadamente igual a la de implementar.
Los primeros lenguajes de programación fueron bastante simples (sin recursión para ejemplo) y cerca de la arquitectura de la máquina que era en sí sencillo. La traducción fue entonces un proceso sencillo .
Un compilador era más simple como un programa que un intérprete que Tendría que mantener juntos tanto los datos para la ejecución del programa y Las tablas para interpretar el código fuente. Y el intérprete lo haría tome más espacio , por sí mismo, para el código fuente del programa y para el código simbólico tablas.
La memoria podría ser tan escasa (tanto por su costo como por motivos arquitectónicos) que los compiladores podrían ser programas independientes que sobrescribieron la Sistema operativo (utilicé uno de estos). El sistema operativo tuvo que ser recargado Después de compilar para ejecutar el programa compilado. ... lo que hace deje claro que ejecutar un intérprete para un trabajo real simplemente no era una opción .
Para ser verdad, la simplicidad requerida de los compiladores era tal que los compiladores no eran muy buenos (la optimización del código todavía estaba en la infancia, cuando se consideraba en absoluto). El código de máquina escrito a mano tenía, al menos Hasta finales de los sesenta, en algunos lugares, la reputación de ser Mucho más eficiente que el código generado por compilador. Incluso había un concepto de relación de expansión de código , que comparaba el tamaño De código compilado al trabajo de un muy buen programador. Por lo general era mayor que 1 para la mayoría de los compiladores (¿todos?), lo que significa programas más lentos, y Mucho más importante, programas más grandes que requieren más memoria. Esto era sigue siendo un problema en los años sesenta.
El interés del compilador estaba en la facilidad de programación, especialmente para los usuarios que no eran especialistas en computación, tales como científicos en varios campos. Este interés no fue el rendimiento del código. Pero aun así, programador. El tiempo entonces fue considerado un recurso barato. El costo fue en computadora. hasta 1975-1980, cuando el costo pasó de hardware a software. Lo que significa que incluso el compilador no fue tomado en serio por algunos profesionales .
El alto costo del tiempo de computadora fue otra razón para descalificando intérpretes , hasta el punto de que la idea misma tendría ha sido ridículo para la mayoría de las personas.
El caso de Lisp es muy especial, porque era extremadamente simple. lenguaje que lo hizo viable (y la computadora se había convertido en un poco más grande en 58). Más importante aún, el intérprete Lisp fue una prueba de concepto con respecto a la autodefinición de Lisp ( meta-circularity ), independientemente de cualquier cuestión de usabilidad.
El éxito de Lisp se debe en gran parte al hecho de que esta autodefinición lo convirtió en un Excelente banco de pruebas para estudiar estructuras de programación y diseño nuevo. idiomas (y también por su comodidad para el cálculo simbólico).
No estoy de acuerdo con la premisa de la pregunta.
Adm. El primer compilador de Hopper (el A-0) era más como un enlazador o un lenguaje de macros. Ella almacenó las subrutinas en una cinta (cada una asignó un número) y sus programas se escribirían como una lista de subrutinas y argumentos. El compilador copiaría las subrutinas solicitadas de la cinta y las reordenaría en un programa completo.
Utilizó la palabra "compilar" en el mismo sentido en que compila una antología de poemas: recopila varios artículos en un solo volumen.
El primer compilador no tenía un lexer o un analizador, por lo que puedo decir, lo que lo convierte en un antepasado lejano de un compilador moderno. Más tarde, creó otro compilador (el B-0, también conocido como FLOW-MATIC) con el objetivo de una sintaxis similar a la del inglés, pero no se completó hasta 1958 o 1959, casi al mismo tiempo que el intérprete Lisp. p>
Por lo tanto, creo que la pregunta en sí es un poco errónea. Parece que los compiladores e intérpretes evolucionaron casi exactamente al mismo tiempo, sin duda debido al intercambio de ideas que habrían tenido muchos científicos pensando en la misma línea en esos días.
Una mejor respuesta con citas aquí: enlace .
La otra parte de la ecuación es que los compiladores eran una abstracción de pasos sobre un ensamblador. Primero tuvimos un código de máquina codificado. "Nosotros" fuimos los ensambladores. Cada salto y desplazamiento, etc., se calcularon a mano en hexadecimal (u octal) y luego se insertaron en cinta de papel o tarjetas. Así que cuando los ensambladores aparecieron en escena, fue un gran ahorro de tiempo. El siguiente paso fueron los ensambladores de macros. Eso le dio la capacidad de escribir una macro que se expandiría en un conjunto de instrucciones de la máquina. Así que Fortran y Cobol fueron un gran paso adelante. La falta de recursos (almacenamiento, memoria y ciclos de CPU) significaba que los intérpretes de propósito general tenían que esperar a que la tecnología creciera. La mayoría de los primeros intérpretes fueron motores de código de bytes (como Java o CLR de hoy, pero con mucha menos capacidad). UCSD Pascal era un lenguaje muy popular (y rápido). MS Basic era un motor de código byte debajo del capó. Así que la "compilación" fue realmente para generar un flujo de código de bytes que realmente fue ejecutado por el tiempo de ejecución.
En términos de sobrecarga de instrucción, dependía totalmente de qué procesador se estaba ejecutando. La industria pasó por una gran crisis de RISC vs CISC por un tiempo. Personalmente escribí el ensamblador para IBM, Data General, Motorola, Intel (cuando aparecieron), TI y varios más. Hubo una diferencia bastante significativa en los conjuntos de instrucciones, registros, etc. que influirían en lo que se requería para "interpretar" un código p.
Como referencia temporal, comencé a programar en la compañía telefónica alrededor de 1972.
Si no tiene todo en la memoria, el código compilado es mucho más rápido. No olvide que en estos tiempos las funciones se unieron al código compilado. Si no está compilando, no sabe qué funciones necesitará. Entonces, estás llamando a funciones desde ... Oh, no desde el disco todavía, ¡estamos en los primeros 50 empates, pero desde las tarjetas! En tiempo de ejecución!
Por supuesto, es posible encontrar soluciones alternativas, pero aún no se encontraron, ya que los idiomas son muy simples y no están muy lejos del código de máquina. Y compilar fue fácil y suficiente.
Antes de que se escribiera el primer compilador, la gente escribía un código de ensamblador que fue un gran progreso en comparación con el código binario simple. En ese momento, había un fuerte argumento de que el código compilado por un compilador sería menos eficiente que el código del ensamblador; en ese momento, la relación de (costo de la computadora) con (costo del programador) era muy, muy diferente a la actual. Así que hubo una fuerte resistencia contra los compiladores desde ese punto de vista.
Pero los compiladores son muchísimo más eficientes que los intérpretes. Si hubieras sugerido escribir un intérprete en ese momento, la gente pensaría que estás loco. ¿Te imaginas comprar una computadora de un millón de dólares y luego perder el 90% de su poder para interpretar el código?
Antes de que se pueda interpretar un programa en bucle, se debe almacenar en un medio que se pueda leer repetidamente. En la mayoría de los casos, el único medio adecuado sería RAM. Dado que el código normalmente se ingresará en tarjetas perforadas que, en el caso de los idiomas legibles por humanos, es probable que estén prácticamente vacías, se debe realizar algún tipo de procesamiento en el código antes de almacenarlo en la RAM. En muchos casos, procesar el texto de la tarjeta perforada en una forma adecuada para la ejecución directa por parte del procesador no es realmente más difícil que procesarlo en una forma que se pueda manejar de manera eficiente a través de un intérprete.
Tenga en cuenta que el objetivo de los primeros compiladores no era producir un archivo en lenguaje de ensamblador o código de objeto en el disco, sino terminar con el código en la RAM que estaba listo para ejecutarse. En realidad, esto es sorprendentemente fácil cuando no hay un sistema operativo que interfiera. Un compilador puede generar código a partir de un extremo de la memoria y asignar variables y objetivos de rama a partir del otro. Si una declaración está marcada con la etiqueta "1234", el compilador almacenará en la variable llamada "1234" una instrucción para saltar a la dirección de generación de código actual, creando esa variable si no existe. Una declaración "goto 1234" creará una variable "1234" si no existe, y luego saltará a esa variable [que se espera que tenga un salto a la ubicación correcta almacenada en ella antes de que se ejecute esa declaración]. Tenga en cuenta que el compilador no tiene que hacer nada especial para permitir que el código a goto una etiqueta que aún no se haya definido, ya que sabe cuándo compila% co_de donde va a saltar a una variable. Puede que esa no sea la forma más eficiente de generar código, pero es adecuada para el tamaño de los programas que se espera que las computadoras manejen.
Porque los intérpretes necesitan compiladores para poder trabajar.
La afirmación anterior no es realmente cierta. Estrictamente hablando, usted puede hacer un intérprete sin utilizar ni interactuar con un compilador. Pero los resultados de hacer esto no se parecerían mucho a lo que creo que quieres decir con esos términos.
En el sentido estricto, los compiladores e intérpretes hacen cosas completamente diferentes. Un compilador lee el texto de alguna fuente y lo transforma en otro formato: lenguaje ensamblador, código de máquina, otro lenguaje de alto nivel, una estructura de datos o cualquier otra cosa. Mientras tanto, un intérprete toma una estructura de datos de algún tipo y realiza instrucciones basadas en él.
Lo que solemos considerar como un "compilador" hoy en día es en realidad un compilador que se ha emparejado con un código generador : un programa que toma datos de algunos fuente y código de salida en algún formato basado en lo que ve. Este es un uso bastante intuitivo para los compiladores, y fue una de las primeras cosas para las que se crearon los compiladores. Pero si lo miras de otra manera, esto parece muy similar a lo que hace un intérprete. Siempre genera código en lugar de realizar operaciones más generales, pero el principio es el mismo.
Si lo vemos desde el otro lado, un intérprete necesita obtener sus datos de algún lugar . Esto solo son datos, por lo que puede acumularlos de la misma forma que lo haría con cualquier otro tipo de datos. Ya que estamos hablando de interpretación, parece natural que pueda construir sus datos basándose en las instrucciones de un archivo de texto. Pero para hacer eso, necesitarías algo para leer el texto y crear tu estructura de datos, y eso es un compilador . Está conectado al intérprete en lugar de a un generador de código, pero es un compilador de todos modos.
Es por eso que los compiladores fueron escritos primero. La idea de interpretar las estructuras de datos no era nueva incluso cuando se concebían los compiladores, pero los compiladores eran el "eslabón perdido" que permitía a los programadores construir esas estructuras con texto.
Otro factor: cuando se escribieron los primeros compiladores, el costo del tiempo de la máquina era mucho más alto de lo que es ahora. Los intérpretes utilizan mucho más tiempo de máquina.
Lea otras preguntas en las etiquetas history compiler interpreters