Resumen

  • LAP6 mostraba un manuscrito largo como un rollo móvil: el usuario añadía o borraba una línea en la posición actual y veía integrado el nuevo estado del texto.
  • Guardar el manuscrito actualizaba una entrada con nombre en LINCtape; convertir, cargar, ejecutar y validar un experimento seguían siendo operaciones posteriores y distintas.
  • Wilkes escribió LAP6, pero el registro también atribuye la técnica de edición sobre cinta a Mishell J. Stucki y Severo M. Ornstein, el contexto del LINC a Wesley Clark y su equipo, y parte de los requisitos y las pruebas a usuarios y colegas de Washington University.

Una línea de código aparece en la pantalla del LINC. La operadora llega hasta ella, la elimina y teclea otra. Las líneas siguientes se desplazan; su numeración cambia; la corrección queda visible dentro del manuscrito. En una máquina con apenas 2.048 palabras de 12 bits, aquello no era un adorno de interfaz. Era el centro del entorno de trabajo.

Mary Allen Wilkes describió en 1970, en «Conversational Access to a 2048-Word Machine», un sistema en línea para editar texto, archivar automáticamente, mantener ficheros, preparar programas y ensamblarlos. El logro consistió en conectar todas esas tareas sin afirmar que producían la misma clase de evidencia.

El manuscrito era un objeto de trabajo visible

Un manuscrito en LAP6 podía ser cualquier colección útil de caracteres de teclado. Lo normal era el código fuente, aunque el sistema no imponía ese formato. El rollo estándar ocupaba 45 bloques de cinta, o 23.040 caracteres, mientras que solo una pequeña porción necesitaba permanecer en memoria.

El texto avanzaba a medida que se escribía. Un potenciómetro ajustaba cuántas líneas se mostraban. Los números de línea eran referencias relativas y se recomponían después de una modificación. Para un salto amplio se indicaba una línea; cerca del destino, combinaciones de teclas desplazaban el rollo una imagen o una línea en cualquier dirección. La edición no exigía un lenguaje aparte: se añadía o se borraba una línea en el punto actual y la pantalla incorporaba el cambio.

El artículo de Wilkes dedicado a la edición por desplazamiento explica la mecánica. El texto seguía siendo una cadena continua en direcciones fijas de la cinta. Una zona de trabajo de 512 caracteres en el punto de corte absorbía inserciones y supresiones; el material volvía a empalmarse cuando el rollo se movía. El algoritmo modificaba el texto mismo, en lugar de acumular una lista oculta de cambios pendiente de reconciliación.

La pantalla demostraba un hecho limitado: el manuscrito actual había cambiado. No probaba que otra copia con nombre hubiera sido escrita en la cinta, que el texto pudiera ensamblarse o que el programa resultante se comportara según lo previsto.

Archivar introducía otro estado y otra frontera de fallo

Los ficheros LAP6 se regían por un índice de dos bloques. Una entrada podía ser un manuscrito o un programa binario. Eran tipos diferentes y podían compartir nombre sin ser el mismo objeto. La orden de guardado copiaba el manuscrito actual, o un tramo seleccionado, a una entrada. Otras órdenes trasladaban entre dos cintas manuscritos, binarios o todas las entradas no duplicadas.

El sistema buscaba bloques libres y contiguos cerca del índice. Al reemplazar, no garantizaba reutilizar la ubicación física anterior. Si ya existía el nombre, mostraba REPLACE? y esperaba una tecla de decisión. La pregunta evitaba un reemplazo accidental; no certificaba una transacción atómica.

El LAP6 Handbook expone el límite sin ambigüedad. Después de actualizar el índice, una interrupción ya no cancela el archivo. Además, LAP6 escribe el índice antes de la entrada correspondiente. Un problema de cinta entre ambas acciones puede dejar un índice que describe una entrada inexistente. El índice carecía de respaldo.

Una operación de guardado establecía algo más fuerte que una pantalla editada: LAP6 había actuado sobre una entrada con nombre. Aun así, el uso fiable dependía de que cinta, índice y contenido permanecieran coherentes. Las instrucciones de recuperación del manual existen porque esa coherencia podía romperse.

Ensamblar y ejecutar no eran sinónimos de archivar

Para programas fuente, CONVERT ensamblaba el manuscrito actual en forma binaria. LAP6 podía presentar errores de definición de símbolos con números de línea, el intervalo de memoria requerido y la tabla de asignación de símbolos. Si aparecían errores, el usuario regresaba al manuscrito, corregía y convertía otra vez.

LOAD era una acción distinta: llevaba a memoria el binario actual o uno ya archivado y lo iniciaba bajo la convención documentada. Mantener montada la cinta de LAP6 facilitaba volver enseguida al texto, consultar la tabla, corregir y ensamblar de nuevo. La rapidez reducía la necesidad de parchear el binario, pero no convertía una edición de fuente en un resultado de ejecución.

La cadena de evidencia seguía una secuencia: la pantalla mostraba el estado de la fuente; el archivo registraba una entrada con nombre; la conversión producía un binario y diagnósticos; la carga colocaba un binario concreto en memoria; la comprobación observaba su conducta. Todavía hacía falta un protocolo externo para decidir si el instrumento conectado y el experimento habían generado un resultado válido.

También importa la frontera de autoría

Según su historia oral para el Computer History Museum, Wilkes escribió la mayor parte de LAP6 durante 1965 en un LINC instalado en el salón de la casa de sus padres en Baltimore. Recordó haberlo desarrollado en gran medida desde cero, reutilizando algunas rutinas anteriores, y haber enviado la versión LAP5 a San Luis para varios meses de uso antes de la distribución general.

Es una prueba sólida de autoría, no un permiso para borrar al equipo. Wesley Clark dirigió el proyecto LINC y firmó con Wilkes «Programming the LINC». El manual da crédito expreso a Mishell J. Stucki y Severo M. Ornstein por la técnica de manejo de cinta empleada en la edición. Colegas de Washington University pusieron a prueba las versiones previas; las visitas a laboratorios LINC influyeron en la especificación. MIT Lincoln Laboratory había proporcionado el entorno anterior del LINC y su simulador.

Algunos relatos secundarios mezclan nombres además de funciones. Los documentos primarios revisados identifican a Mishell J. Stucki y Severo M. Ornstein. No acreditan contribuciones separadas a LAP6 de personas llamadas «Philip Mishell» o «Ted Severo». Una historia rigurosa conserva la discrepancia en vez de inventar identidades o reasignar méritos.

Fuentes