>> Да, именно про это и я писал, с объяснением причин. Посмотрите ещё
>> старые версии Fortran, где тип переменной определялся по начальному символу имени
>> и пробелы не учитывались.
> Одним глазом смотрел, и мне померещилось что там использовали несколько выходных потоков.

Потоки при запуске оттранслированной программы? Как их увязать с фактом экономии размера исходного текста?

>> Где? На 8ми битных компах? Хотеть посмотреть. Помню "графический редактор" Artstudio, и
>> ещё музыкальный, сам писал.
> Я и сам хотел узнать. Но факт в том, что они должны
> были быть. Не в таком виде, как ты представляешь.

Вот про такой "калькулятор" https://ru.wikipedia.org/wiki/МИР читал. Инженер мог его самолично использовать, аппаратно поддерживались числа произвольной длины. Теперь нужна bignum библиотека и пять программистов.

> Не для
> красоты же компы покупали. Никто не запрещал подключать несколько шкафов-накопителей на
> магнитной ленте или устройств на перфоленте для входных потоков и выходных.
> И обрабатывать данные в несколько проходов. Вспомни те же многопроходные ассемблеры.
> Но ты же мыслишь только умещением исходника целиком в ОЗУ.

В данном случае "многопроходный" означает возможности ассемблера, а не количество чтений исходного файла. Дополнительные проходы нужны, когда метка определяется после использования. При ассемблировании команды на первом проходе не ясно, что размещать в операнде. Потому вместо размещения в опкоде актуальных данных из таких команд формировалось "дерево синтаксического разбора" и второй и последующие проходы шли по нему, а не по исходному тексту. Соотношение размеров исходного кода к объектному где-то 5 к 1, значит последний может размещаться поверх исходника без затирания неразобранной части первого. Размер дерева зависит от количества меток, которых не так много. Часть меток (имена подпрограмм) разрешается на этапе связывания. Вот как-то так я мыслю, говоря про размещение в ОЗУ.