Шеркало 05.07: любимые системы программирования (Другие)

 - Шеркало, Шеркало, на окне лежало, под кровать упало,

О порог споткнулось, испугалось, и сразу убежало! Ты где?

- А говорят, что один Ёж как-то раз шёл, шёл, потом споткнулся,

Потом сразу забыл, как дышать. и внезапно задохнулся! Ты как себя чувствуешь?

- Сейчас, кажется, пока ещё нормально. Рассказать тебе чего-нибудь ещё, про любовь?

- Что ты всё про любовь, да про любовь? А вот были у тебя измены твоим любимым языкам?

- Ну ты и вопросы задаёшь! Тема прямо-таки даже на удивление по-людски выглядит. Только языки и стили программирования, это же не любимые люди. Они бесчувственны (хотя и далеко не безличностны!), боли и терзаний не испытывают. Изменять языкам - нормально, и даже, временами, хорошо - сообществом программистов измена одному языку в пользу другого даже часто морально поощряется, называется это: "профессионально-личностный рост". Давай, попробую рассказать.

Начать, наверное нужно с моей измены Паскалю, о котором я говорил в предыдущих двух частях. Дело в том, что уже в первой половине 1990-х годов я вынужден был перейти с учебно-научной работы на более бухгалтерскую, а в середине 90-х и вовсе на чисто банковскую работу. На тот момент Delphi только ещё планировалась к разработке (в прошлом тексте я сознательно забежал чуть вперёд), а чистые IDE Pascal, что в варианте TP/BP для DOS, что в эксклюзивном варианте TPforWindows, для быстрой и успешной реализации офисных-бухгалтерских программ не слишком подходили. Было то самое несоответствие предметной области. Паскаль, он безусловно очень универсален и очень логичен, но для бухгалтерии требуется что-то более готовое к употреблению, что-то более высокоуровневое, с формами, таблицами, отчётами, файлами, базами данных, многопользовательским доступом в одном флаконе.

FoxPro

А вот тут, хочу на минуту отвлечься. Про FoxPro я уже и раньше говорил, и позже чуть ниже ещё скажу. Но FoxPro ведь был не совсем оригинальной системой. Изначально, ещё до эпохи Microsoft, под популярную тогда операционную систему CP/M разработали одну из первых эффективных персональных баз данных dBase II. Позже, с появлением революционного компьютера IBM PC с операционкой MS-DOS, успешную базу данных доработали. Версию популярной уже СУБД под новую систему MS-DOS (она же PC-DOS) выпустила молодая, перспективная фирма Ashton-Tate, её назвали dBase III, чуть позже dBase III+.

В конце 1980-х, начале 90-х, база данных dBase III была абсолютным эталоном СУБД для персональных компьютеров. Конечно же наш продвинутый Университет не мог пропустить мимо своих образовательных программ такое заметное на всемирном уровне приложение. Вот только... среди преподавателей, кажется, не оказалось никого, кто хоть чего-нибудь в этой самой dBase понимал, хотя бы на самом начальном уровне. Там вообще-то (как я понял чуть-чуть позже) не было АБСОЛЮТНО ничего сложного. Стоило лишь мельком, по-диагонали, прочитать прилагаемые readme-файлы. Правда... Правда на английском языке. И вот тут-то большинство наших университетских преподавателей почему-то втихушку заткнулись. Хотя, казалось бы, все образованные люди были? Но ведь всегда проще промолчать, чем взять на себя личную ответственность за перевод для студентов коротенькой примитивной брошюрки на английском языке? Так что dBase III нам упоминали в начале профильного курса... и дальше забывали о нём.

Была и другая, альтернативная ветка преподавания теории СУБД. Именно под неё я и попал. Там вообще не рассматривались БД ориентированные на персональные компьютеры. Настоящие БД могли работать только на огромных мейнфреймах и супер-ЭВМ! Мне долго что-то вдалбливали в мозги про какую-то математически-теоретическую реляционность модели баз данных, про то, что реляционную модель не следует путать с плоским табличным представлением, даже, если оно индексировано, которое является лишь практическим приближением теоретически-идеальной структуры, и требует, как минимум, пяти уровней нормализации, перед тем, как с ним можно будет правильно работать. Правильно написал, не ошибся? Чёрт знает, скорее неправильно. Впрочем, это уже неважно.

Ах да, при этом ещё нужно было помнить разницу между прямыми, косвенными, виртуально-базисными, индексно-последовательными и блочно-распределенными методами доступа (могу ошибаться в конкретных терминах;)), к файловой структуре БД конкретной используемой модели ЕС ЭВМ. Я честно просил преподавателей, показать мне, как это всё на практике работает, хотя бы на примере простейшей БД вида: (школьники Маша, Вася, Петя, изучают Алгебру, Русский, Физику, получают оценки 2,3,4,5). Ведь у нас же ЕСТЬ в университете работающая ЕС ЭВМ!!! Ответ был разочаровывающим: не доросли вы ещё до реализации своих студенческих СУБД на нашей университетской ЕС ЭВМ! Её, болезную, итак непрерывно 100500+ умных инженеров чинят, и починить никак не могут! Она дольше 2-х минут непрерывно работать не может! Так что рисуйте свои СУБД карандашами в тетрадке!

Однако, постепенно ситуация в ИТ-мире менялась. У очень коммерчески успешной СУБД dBase III стали появляться менее лицензионные клоны, некоторые из которых становились очень успешными продуктами. В свою очередь, компьютерные классы университета постепенно стали к началу 1990-х годов наполняться персоналками уровня IBM PC XT (сначала болгарскими Правец-16, а позже и "родными" IBM PS/2). И преподаватели, прежде всего продвинутая молодёжь, понемногу стали обращать внимание в том числе и на персональные СУБД.

Для обучения обычно выбирали самых старательных девочек-отличниц-старшекурсниц. Считалось, что именно они наиболее способны к освоению подобной коммерчески-ориентированной технологии. Я сам ни к категории девочек, ни к категории отличниц разумеется не принадлежал, поэтому начало процесса прошло совсем мимо меня. Однако даже я стал замечать, что некоторые мои однокурсницы на лабораторных работах отсаживаются отдельно и делают что-то своё на таинственно-чёрных экранах, периодически перешёптываясь с аспирантами. Я, из любопытства, попытался узнать, чем они занимаются. В ответ всегда звучали таинственные слова: "Работаем на Клиппере!" Кто такой этот "клиппер" я понять не мог (Интернета-то тогда не было, гуглить было негде!). Но название само по себе звучало очень красиво и романтично. В конце-концов я всё-таки уговорил одну из однокурсниц показать мне ближе свою лабораторную на экране. Увидел я примерно вот это:

- Вот видишь, поясняла однокурсница, - я написала на Клиппере программу: ввожу своё имя Лена, а она меня запоминает в своей базе данных и со мной здоровается. А потом спрашивает, хочу ли я завершить работу. Причём ответ "Yes" специально выделен одним цветом, а ответ "No" - другим, в этой системе даже так можно. И она ждёт какую клавишу я потом нажму, вот!
Я несколько секунд тупо смотрел на экран (кстати, прошу корректность кода программы с картинки оставить на совести той Лены, а ко мне претензии не предъявлять. Я и сам отлично знаю, что эта программа на самом деле работает не совсем так, как её автор заявляет!). 

- Так это же обычный dBase! - констатировал я после недолгой паузы и попытки найти, в чём состоит скрытый подвох.

- Сам ты dBase! - обиделась однокурсница, - это совсем другая система! Это "Клиппер". "CLIPPER", я говорю, слышишь?! Клиппер, в отличии от dBase, позволяет компилировать программы, а не просто набирать их на клавиатуре. Поэтому Клиппер - настоящая профессиональная система! Сейчас на Клиппере весь новый модный софт пишут, и для экономики, и для всяких банков, и для коммерческих фирм! А ты говоришь - dBase...

Так я тогда толком и не понял, что такое "Clipper" и чем он отличается от простого dBase III с подключенными библиотеками run-time исполнения псевдокода. Но некоторый осадочек зависти в душе отложился - вот эта дурочка, которая пять строчек с трёх раз без ошибок написать не может, работает на каком-то модном "профессиональном" Клиппере, а мне вместо этого предлагают какие-то Prolog, Smalltalk и прочие мутные экспертные системы. Может быть это потому, что я - не дурочка?

А потом был у меня другой клон того же dBase III+ - назывался FoxBase. Тоже, как и Clipper, не совсем лицензионный клон (поэтому и более распространённый в СССР, чем оригинал), но очень качественный клон, имеющий к тому же чуть более приятный интерфейс, чем исходный dBase, чуть быстрее работающий. Эпизодически использовал его, когда необходимость в СУБД возникала. Но так... Ничего особо интересного, любить там было нечего. Клон старенькой программы, только и всего. А вот следующая версия FoxBase, которая стала заслуженно называться FoxPro... Вот там уже совершенно другое! Полноценный оконный интерфейс, визуальная среда с конструкторами окон, реально профессиональный доступ к базам данных, в том числе по локальной сети. Это уже была совершенно иная среда исполнения, совершенно другой уровень разработки программ.

FoxPro

Пришлось изменить Паскалю. Я об этом уже писал, система FoxPro 2.x for DOS на тот момент идеально подходила для создания бухгалтерско-офисных приложений. Там было всё желаемое: и формы, и отчёты, и таблицы, и менюшки, и диалоги, и списки, и файлы, и базы данных со всей возможной на тот момент инфраструктурой, и с просто сетевым многопользовательским доступом, и даже с зачатками клиент-серверной архитектуре. И всё это объединено под полнофункциональной IDE/RAD средой быстрой разработки программ (хоть и в псевдографике под DOS).

Повторять (включая картинки) не хочу. Это было. Это было ПОТРЯСАЮЩЕе соитие моих собственных чувств с идеями разработчиков системы! Я не понимаю, почему в эпоху MS DOS FoxPro не стала офисной системой-доминантом?! Причина только лишь в том, что Fox появилась позже, и формально была лишь клоном более ранней dBase? Вероятно так, и это вызывает сожаление.

Однако, факт: она не стала общепринятой. Варианты систем dBase. Clipper, даже Clarion, на мой взгляд все, хотя и были на порядок слабее, чем FoxPro, получали гораздо бОльшую, совсем не заслуженную популярность. Ну, а потом, началась эпоха Windows. FoxPro, купленная к тому времени Microsoft, никаких чудес уже не показывала (Microsoft и не пыталась эту систему развивать, Fox не укладывалась в фирменную линейку продуктов). Пробовал её версию под Windows - ничего реально интересного не увидел  Под DOS, там таки да, там до самого конца 1990-х FoxPro людей впечатляла. Особенно возможностью буквально мгновенно, из буквально дерьма и палок, собрать прямо на коленке действительно вкусную конфетку. Но время DOS прошло, как GUI, так и развивающиеся сетевые технологии потребовали иных парадигм разработки программ. К началу 2000-х FoxPro объективно устарела, причём по нескольким направлениям сразу.

Ассемблер

Наверное, Шеркало, для популярного текста мне нужно рассказать, что такое "ассемблер". Само слово "ассемблер" переводится как "собиратель" и скорее запутывает людей, чем что-то поясняет (просто так исторически сложилось, придётся объяснять). Дело в том, что любой цифровой компьютер на своём компьютерном уровне работает с сигналами (обычно электрическими, но не будем углубляться в ненужные тонкости). У сигналов есть два уровня (условно): единица = есть сигнал, и ноль = нет сигнала. Все команды для компьютера в конечном итоге представляют из себя последовательность сигналов = строчку из нулей и единиц, вроде "0100000000010000010000110110". А компьютер, прочитав эту строчку электрических сигналов, понимает, что ему нужно сделать. Вот эти строчки нулей и единиц, имеющие смысл в рамках системы команд (архитектуры) конкретного компьютера, называются "машинный язык" 

Разумеется, никакой нормальный человек навскидку не может понимать, что эти длинные-предлинные наборы нулей с единицами обозначают. Это только в кино (The Matrix, первая Матрица) один из героев (Сайфер), показывая другому герою фильма (Нео) на ряды непонятных зелёных значков, падающих по экрану компьютера, мог самодовольно говорить: "Я уже даже не вижу код. Я вижу здесь блондинку, брюнетку и рыжую..."

НЕТ! Это у людей так не работает.  Нормальные люди даже после долгих тренировок, воспринимают длинные ряды одинаковых цифр не слишком адекватно. Нормальным людям гораздо понятнее вменяемый алфавитно-цифровой текст. Ну так и в машинном коде каждая 0-1-длинная-цифровая команда разделяется на отдельные смысловые части:

- код операции (ЧТО нужно сделать);

- адреса операндов (откуда брать данные);

- адрес результата (куда сохранить результат выполнения);

- адрес следующей операции (что делать дальше).

Разумеется. не в каждой команде все части нужны одновременно, некоторые или совсем не требуются, или подразумеваются заранее известными по умолчанию. Например, редко требуется адрес следующей команды, часто нужно просто перейти к следующей по порядку операции, а её адрес заранее известен - это +1 относительно выполняемой команды Так же и адрес результата может изначально подразумеваться совпадающим с одним из адресов входных операндов. Но в любом случае, записать (а важнее - прочитать!) машинную команду в "нормальных" буквенных выражениях, структурированную заранее на логические части, это для человека НАМНОГО понятнее. чем. думать, как та же команда запишется нулями и единицами! Там дополнительную прелесть даёт сложная адресация операндов и результатов. Она бывает регистровой (операнд лежит (например) в нулевом регистре компьютера), прямой (операнд лежит в ячейке памяти, указанной явно в команде компьютера), косвенно-регистровой (операнд лежит в ячейке памяти, адрес которой записан в регистре компьютера, который указан в команде), бывает индексной (операнд лежит в ячейке, адрес которой вычисляется, как сумма адресной базы, которая указана в команде явно, и значения индексного регистра, которое умножается на размер элемента дан...

- Ёж, ПРЕКРАТИ!!!

- А... Что? Я что-то не-то сказал?

- Заткнись! Просто заткнись на эту тему! Тебя всё равно никто не слушает.

...

- Понял, извини пожалуйста. Так вот, язык ассемблера, это просто язык, символьный такой язык, на котором машинные команды компьютера записывают в нормальном читабельном виде, словами и цифрами, а не сплошной строкой бит. Но при этом от машинных команд значительно не удаляются - такая вот, условно говоря, запись чисто машинного языка, но вполне человеческими буквами. И обо всех особенностях адресации между кусочками программы тоже заботится транслятор (поэтому и называется "ассемблер" - он собирает единую программу из кусочков-библиотек по разным адресам, взаимно увязывая эти кусочки), человек вручную адреса команд и переменных пересчитывать не обязан. Ещё нужно бы упомянуть понятие макро-ассемблер, но я уже тебя понял, лучше этого не делать.

А вот чего я не могу не подчеркнуть, несмотря на твои предостережения, Шеркало, так это важности использования ассемблера при адресации внутри программы, по сравнению с машинным кодом. Пусть у нас есть простейшая задача:

"Если A>B то выполняем следующую команду, а если нет, то минуя следующую команду, переходим сразу на команду номер 1535". 

Пусть мы это как-то (не важно как, на самом деле не слишком сложно и вручную сделать) самостоятельно написали прямо в машинных кодах. Соответственно и адрес перехода "1535" прямо в машинный код в явном виде забили. А позже вдруг выяснилось, что, если A > B, то нужно выполнить не одну команду, как сначала предполагали, а две, или три, или даже целых 6 команд. Соответственно, переход по условию ИНАЧЕ (A<=B) должен выполняться не на адрес 1535, как ранее задумывали, а на адрес 1536, или на адрес 1540, или вообще на какой-то иной адрес. Ну и вообще, все адреса переходов в программе, которые идут позже нашего упомянутого сравнения A>B, должны быть пересчитаны на совершенно другие ячейки, поскольку размер вышележащей области программы изменился, всё расположение команд по ячейкам сдвинулось. А таких адресов переходов ниже по программе может оказаться много сотен, или даже тысяч. А ещё и ячейки с данными, если они расположены в том же адресном пространстве ниже кода программы (такое не всегда, но бывает), тоже изменят свои адреса. И все места этих переходов и места адресации сместившихся ячеек памяти нужно теперь вручную найти прямо посреди цифрового машинного кода (нужно вычленить команды перехода и адресации, которые меняются, из кучи других команд, которые меняться не должны), пересчитать в них адреса, и вручную их все исправить!

Вот где настоящая собака-то зарыта!!! Только представьте себе, единичное добавление или удаление команды в программе, влечёт за собой сотни или тысячи исправлений в машинном коде этой программы, причём не в каждой команде, а только в выборочных местах! Фактически, при единичном исправлении (добавлении) одного машинного слова, едва ли не всю программу в машинном коде нужно переписывать заново с нуля!!! Каково? Вот! Вот именно для решения ЭТОЙ ситуации с адресацией, а отнюдь не для красивых буквенных мнемоник вместо 0 и 1, и разрабатывали языки Ассемблера. В Ассемблере каждый адрес перехода или адрес ячейки задаётся символической меткой. Конкретное значение этой метке присваивается самим Ассемблером при компиляции программы, программист знать конкретный адрес метки, как правило, совершенно не обязан. Изменили что-то в программе - следовательно фактические значения всех меток в физические адреса внутри машинных команд автоматически пересчитались заново. Автоматически пересчитались все адреса переходов и используемых данных! Вот в этом и есть главная помощь от применения Ассемблера.

Но обязательно требуется упомянуть, что для каждого типа компьютеров (это сейчас называется "архитектурой") языки ассемблера различные. Первым ассемблером, на котором я писал учебные программы был ассемблер IBM/360. Сначала не хотел картинку с ним прикладывать - всё-таки у меня от него почти и не осталось воспоминаний, но потом решил для красоты присобачить вот эту иллюстрацию из учебника 1970 года: 

Тут как раз хорошо виден расчерченный на клеточки типичный IBMовский бланк, отдаваемый операторам для пробивки колоды перфокарт. Точно такие же бланки применялись для ЛЮБЫХ языков на машинах IBM/360, эти же бланки были и для COBOL, и для FORTRAN. Каждая клеточка - один символ большими печатными буквами, каждая строка - один оператор (или команда/псевдокоманда), в строке отдельные поля для меток, операций, операндов и комментария. Я о таких бланках в рассказе про Фортран упоминал, а здесь вот - реальный пример. Хотя сама программа и бессмысленная (точнее исключительно учебно-демонстрационная), но текст весьма похожий на настоящий, он даже откомпилировался бы без ошибок. 

Я с этим ассемблером познакомился на редкой машинке АСВТ М4030 в ИОА (в мой школьный период), которая была совместима по системе машинных команд с IBM/360, хотя к семейству ЕС ЭВМ напрямую и не принадлежала. Никаких интересных программ я на этом ассемблере не писал, в моей памяти ничего не осталось, но после него желание углубляться в программирование резко усилилось - ужасно понравилось!

Вторым моим языком ассемблера был ассемблер PDP-11 (оно же семейство СМ ЭВМ). А вот это уже без всяких скидок была настоящая любовь (третья по счёту?) и измена Паскалю! Правда, измена явно вынужденная. Моими основными домашними компьютерами в студенческий период были БК-0010/0011(М). У этих машин под программы выделялось в общем случае 16 кБ оперативной памяти (точнее даже не 16, а 15.5, и это для домашнего персонального компьютера ОЧЕНЬ МАЛО!). Если хочется (а таки очень даже ДА!) писать собственные программы, то нужно либо довольствоваться Бэйсиком или Фокалом в ПЗУ (и то, и другое - полная лажа), либо использовать ассемблер PDP-11. Компиляторы более-менее нормальных языков высокого уровня (включая обычно предлагаемые "минимально" требовательные Си и PL/M) в таких условиях (там ещё и файловая система для долговременной записи программ и данных на бытовом кассетном магнитофоне с ручным управлением "на слух" изначально была, в сочетании с мизерной оперативной памятью - вообще полная жопа катастрофа) реально задействовать не получалось.

С другой стороны, откат с языков высокого уровня обратно на "низкий" ассемблер в случае с архитектурой PDP-11 ничем "постыдным" не являлся. Большинство людей, которые активно работали с ассемблером PDP-11, позже высказывались примерно в таком духе: "А зачем там вообще нужны эти языки высокого уровня? На PDP-11 и ассемблер ничем не хуже!" Я принадлежу к числу этих людей. Архитектура PDP-11 просто уникальна своей красотой, симметричностью, изяществом. Ни до, ни после ничего подобного не делали (делали конечно, в том числе и прямо по образцу PDP-11 делали, но уже не так здорово получалось). Обычно архитектура компьютера - это ясно видимый мучительный компромисс между техническими особенностями реализации железа и стремлением программистов к собственному удобству. Так вот PDP-11 - это редчайший случай, когда очевидная красота затмевает собой лежащий где-то там глубоко под ней какой-то там несущественный, никому не интересный компромисс с реальностью. Как там А.Миронов/О.Бендер пел? "Замрите ангелы, смотрите - я играю! Моих грехов разбор оставьте до поры, вы оцените красоту игры!"

Выглядело как-то вот так, как сверху, но эта картинка стороннему человеку ничего не скажет. Ассемблер, и есть ассемблер - по одной команде на строку, метки, операции, операнды, комментарии. Всё, вроде бы, как и у остальных. Только окунувшись в такое с головой, начинаешь ощущать скрытую внутри красоту.

На ассемблере PDP-11 (на компьютерах БК-0010/0011(М)) я написал несколько реально используемых прикладных программ, пару курсовых работ, частично свой диплом в Университете. Текст моей дипломной работы я печатал на БК-0011М из текстового редактора собственной разработки, снабжённого драйверами собственной разработки для принтеров Электроника МС6313 и Robotron СМ6329 (компилированных тем же ассемблером PDP-11, разумеется). Очень активное и для своего времени успешное использование языка у меня было, плюс самые тёплые воспоминания о том периоде.

Алгол-68

Очень мало что могу сказать. Язык должен был стать прорывной, прекрасной, впечатляющей весь мир заменой ранним версиям языка Алгол (Алгол-60 и т.п.). На него возлагались очень большие надежды. Все видные учёные-компьютерщики старались привнести в Алгол-68 всё самое лучшее, что успели придумать к тому времени (число 68 в названии языка - это год разработки, если что). В итоге получилось...

Я не знаю, что получилось. Неоднократно мной ранее мной упомянутый гениальный профессор Н.Вирт, который с неизменным энтузиазмом участвовал в разработке и совершенствовании предыдущих версий Алгола, из состава разработчиков языка Алгол-68 выбежал, при этом дико вращая глазами, крутя у своих висков указательными пальцами обеих рук одновременно, и громко хлопая по пути всеми попавшимися под носок ботинка дверями. Однако, поскольку Алгол-68 считался в наших сибирских краях весьма перспективным, я очень хотел его изучить. У меня даже была толстая книжка под названием "Пересмотренное сообщение по языку Алгол-68", в таком жёлтеньком переплёте. И даже с автографом одного из авторов - академика Ершова, вот! Вот только куда она при переездах делась? Шеркало, ты не в курсе?

- Нашёл у кого спросить! Ты ещё к белой берёзе за окошком обратись... Ну, или к ясеню с месяцем, тоже полезно будет.

- Ну, ладно, ладно. Там и без книжки ничего не складывалось. Работающие (скорее всего работающие, кто ж их проверял на серьёзных проектах?) трансляторы Алгола-68 я видел только на больших мэйнфреймах серии ЕС ЭВМ, один раз в ИОА и один раз в Университете ТГУ Ни там, ни там, этот язык никто реально не использовал. Попробовать было негде. Ни любви, ни измены не вышло. Ни одной программы на Алгол-68, даже самой коротенькой, я не написал.

Всё, продолжение в следующем сеансе связи.

Шеркало 05.06: любимые системы программирования (Паскаль ч. 2)

 - Эй, Шеркало, что замолчало? Заснуло что ли?

- Я не заснуло, я только хорька давило! Здоровый такой хорь попался, долго его давить пришлось!

- Ничёсебе! Ты где таких выражений нахваталось, "хорька давить"?!

- Так от тебя же, от кого же ещё?

- Так я ж про того "хорька" уже лет тридцать с лишним не вспоминал!

- Ага, ага... Ты вспомни, Ёж, как буквально сегодня утром вышел погулять на мороз. И кого ты там сразу же у подъезда поймал? А?! Да ещё и не один раз поймал, кажется?

- Нет, прекрати!!! Это ДРУГОЕ! Так интеллигентным людям говорить нельзя! Ты простых человеческих хорьков с нецензурными эфемерными зимними животными не путай, пожалуйста!

- А? Эээ? Ну тогда расскажи, что там у тебя дальше с Паскалем произошло? Ведь наверняка же простого превосходства в прямизне логики над Алголом было мало?

- Да. конечно, я вчерашний день потратил на то, чтобы перечитать статью Кернигана (он один из разработчиков языка Си) "Почему Паскаль - не мой любимый язык (1981)". Ничего особо нового для себя не увидел, хотя читать пришлось на английском - все русские переводы уже забанены, кажется. Но, неважно. Прочитал на английском. И увидел ровно то, о чём читал и раньше, ещё на русском: 

а) есть, немного, реально грамотные претензии (чрезмерная зацикленность Паскаля  на строгой типизации, особенно их видно в границах массивов при передачи параметров функций);

б) есть откровенный бред, из серии "лично мне так было бы удобнее, поэтому я = Д'Артаньян, а все остальные = бяки-буки, по определению" (статические переменные);

в) есть едва ли не единственная оправданная претензия к Паскалю, которая никак не может быть логически обоснована принципами языка, это отсутствие у оператора выбора "Case" варианта "иначе\else\otherwise". Вот реально не понимаю, почему Никлаус Вирт в своё время не включил эту опцию в оператор "Case", и почему упорствовал в её исключении и в дальнейшем? Ведь никаких принципиальных парадигм языка это ничуть не нарушало. И было легко и беспроблемно включено в новые версии языков на базе Паскаля. Что такое принципиальное Вирт здесь защищал?! Не понимаю!

г) множество менее важных недостатков, которые были (почти) общими для абсолютно всех языков высокого уровня своего времени: отсутствие модульности, проблемы с начальной инициализацией памяти, проблемы с организацией ввода/вывода и взаимодействием с внешними устройствами разнообразных компьютеров, и т.п.

е) ничто вышеперечисленное НЕ МОЖЕТ быть исправлено, потому что у языка Паскаль структура вот такая вот кривая = горбатого только могила исправит, а Паскаль изначально учебным пособием сделан. 

Что могу сказать? Почему он тогда так писал, совершенно понятно - всё-таки самолично есть автор альтернативного подхода. Почти все слабости Паскаля, на которые упирал тогда Керниган, были тогда либо уже (именно уже исправлены(!), к моменту выхода его статьи) исправлены, либо находились прямо в процессе исправления. 

- Ну а у меня, Шеркало, тем временем закончилась школа, миновала служба в армии (где о программировании не приходилось даже заикаться), было обучение в Университете, потом (не только потом, но и во время учёбы тоже) началась работа. И пришлось активно заниматься Паскалем. И чем больше на нём писал, тем больше убеждался, что Паскаль - очень гибкий и удобный язык.

Например, в том же ИОА, Паскаль для DEC PDP-11 (СМ ЭВМ, ДВК) транслировал программу не в машинные коды, а в текст на макроассемблере, который потом компилировался уже собственно ассемблером (кстати, не знаю, было ли это обязательной стадией обработки программы, или же только дополнительной опцией, но очень полезно и, кажется, красиво). В результате, в программу высокого уровня можно было совершенно свободно вставлять ассемблерные вставки, в которых, в свою очередь, можно было обращаться к переменным паскалевской программы прямо по их именам. Мечта системного программиста! Примерно вот так:

VAR SIMB :INTEGER;

PROCEDURE TTYIN; 
BEGIN
  (*$C
    NEXT:    EMT   ^O340
                    BCS   NEXT
                    MOV   %0, SIMB(%5)
  *)
END; (* результат машинной команды EMT 340 записывается в переменную SIMB для дальнейшей обработки в Паскале*)

Не знаю, насколько понятным получился пример. Здесь приведена очень простая (но синтаксически правильная) процедура на Паскале, основная часть которой реализована на языке Ассемблера (технически - это как бы комментарий к программе на Паскале, который якобы должен игнорироваться, но на самом деле не игнорируется, а после компиляции передаётся на вход следующему этапу трансляции, макроассемблеру), причём ассемблерная и паскалевская части свободно обмениваются данными друг с другом, имеют доступ к общим переменным, к регистрам, к прерываниям процессора и т.п.. 

Свобода - программистам! Высокоуровневую часть пишу на Паскале, низкоуровневую часть - на ассемблере. Где между ними граница? А нет никакой границы, у нас тут программирование без границ! 

Я мог бы и более интересные и бОльшие по размеру, и по разнообразию низкоуровневых команд, примеры привести. Я сам лично, писал на Паскале программу, обрабатывающую на низком аппаратном уровне (по сути драйвер устройства) команды графопостроителя, рисовавшего графики фломастерами на планшете под управлением одного из компьютеров СМ-ЭВМ-клонов PDP-11. Там как раз основа программы на Паскале писалась, а аппаратные вызовы через регистры ввода/вывода - на ассемблерных вставках. Графопостроитель в ответ на мои команды шустро вытаскивал механической лапкой один из четырёх доступных фломастеров, бегал своей кареткой вдоль и поперёк листа А3, рисовал красивый график по заданному массиву точек, потом возвращал фломастер в своё гнездо  планшета. Вот только, углубляться в дебри архитектуры PDP-11 в контексте языка Паскаль, совсем даже не нужно (как минимум, мне сейчас - не хочется).

- Чуть позже у нас в стране стали повсеместно использоваться "ПК" - Персональные Компьютеры. Многочисленные клоны клонов клонов IBM PC, PC XT, PC AT, PC 386 и далее, и далее, и далее (и до сих пор, если что). Эти машины уже работали не сами по себе, каждая со своими программами. Для их нормального запуска требовалась целая единая для всей серии разношёрстных компьютеров Операционная Система! Все мы помним, какую роль изначально играла MS DOS. Так вот, чтобы писать программы под "самую распространённую" в тот момент операционную систему (MS DOS) компилятор с языка Паскаль уже был!

И он не подводил. Чего ещё можно желать?! Очень изящный, быстрый, удобный, эффективный компилятор. Встроенная среда разработки IDE (Integrated Development Environment) - невероятно удобно, тут же и редактор (да ещё с цветовым выделением синтаксиса), тут же и компилятор, тут же и отладчик, тут же среда тестирования. Речь, разумеется, идёт о знаменитых средах разработки TurboPasal/BorlandPascal.  Это было впечатляющее качество, потрясающая эффективность. Среды разработки от фирмы Борланд временами превосходили конкурентов (в том числе "профессиональные" компиляторы языка Си) по большинству объективных показателей (размер результирующей программы, скорость выполнения программы, скорость компиляции), не говоря уже о субъективных, вроде удобства редактирования текста. Что ты там, Шеркало, говорило про любовь?!

- Я пока молчу, Ёж, я молчу, как морской ёжик в аквариуме с соляной кислотой, продолжай, пожалуйста.

- Не знаю, нужно ли сюда выкладывать картинку с видом среды разработки Borland Pascal 7.0, уж слишком она всем известна? Всё-таки выложу, для полноты повествования:

BP 7.0 был венцом развития Паскаля для операционной системы MS DOS. И это уже был совершенно другой язык, не просто Паскаль от Н.Вирта, а Object Pascal со всеми (почти) преимуществами современной Объектно-ориентированной парадигмы программирования (она сокращается, как "ООП"). Причём внутренне TP/BP остался всё тем же прежним, уютным, изящным и в меру строгим виртовским Паскалем, объектные расширения добавились в язык очень естественным образом, не нарушая сложившийся порядок. Впрочем, подробности парадигмы ООП я здесь расписывать не буду.

А ещё у меня был опыт работы с очень редким Паскалем - Turbo Pascal for Windows. Это такое временное промежуточное звено, когда уже требовалось переходить от DOS к Windows (на тот момент актуальна Windows 3.0), но ничего походящего разработчики придумать ещё не успели. Вот и появился TPfW. Внутри - тот же самый компилятор TP/BP 7.0, но среда разработки переписана с псевдографики на родной интерфейс Windows, и добавлены утилиты для разработки (рисования) частей интерфейса Windows - редактор иконок, дизайнер оконных формочек, генератор ресурсов. Выглядело внешне примерно вот так:

Кстати, самая верхняя функция на той картинке показывает, что работа напрямую с ассемблером никуда не делась, хотя Windows вроде бы и поощряет "высокоуровневое" программирование вместо машинно-зависимого ассемблера. Почему слово "высокоуровневое" я взял в кавычки? А потому что тот самый "высокий" уровень изначально реализовывался через вызовы функций WindowsAPI, которые с точки зрения прикладной программы были максимально низкоуровневыми, ниже просто уже некуда! Вот, для примера, ещё одна картинка с TPfW:

На этой картинке я специально оранжевыми стрелочками выделил сакраментальные функции GetDC/ReleaseDC. О, Шеркало, сколько несчётных раз я вынужден был в своих программах вызывать эту пару функций! Каждый раз, как в очередном окошке Windows требовалось что-то новое вывести (кнопочку "Я - Ёжик" с ёжиком там нарисовать или просто комментарий рамочкой обвести), так нужно было для начала получить Контекст Устройства вывода (Device Context = DC) через функцию GetDC. А закончил рисовать свою кнопочку-рамочку, так изволь тут же немедленно освободить контекст через функцию ReleaseDC. А если ReleaseDC почему-то осталась без вызова, то в следующий раз ты в том же окошке уже ничего не нарисуешь - контекст-то всё ещё занят. И в другом окошке тоже скорее всего ничего не нарисуешь - число свободных контекстов устройств в системе очень сильно ограничено, а кнопочки и закорючки в окошках рисовать не только одна лишь твоя программа желает! И такая вот ерундень повторялась сквозь весь WindowsAPI - хочешь что-то вывести/убрать/передвинуть в окошках, пиши целые листы вызовов функций с маловразумительными списками параметров, плюс функции отлавливания CallBak'ов, которые должны вернуть тебе управление в исключительных ситуациях, и внимательно следи, чтобы они вызывались строго в нужном порядке, несмотря на общую нелинейную схему вызовов с прерываниями по инициативе пользователя.

Честно, если бы Паскаль остановился на уровне TPforWindows с его "чистым" незамутнённым WindowsAPI, вряд ли этот язык остался бы в списке моих любимых. Но разработчики фирмы Борланд сравнительно оперативно предложили новую интегрированную среду разработки (IDE, а так же средство Rapid Application Development = RAD) под названием Delphi, мгновенно ставшую знаменитой. Не то, чтобы Delphi была самой первой IDE/RAD, нет, были интересные системы и раньше, в том числе и под Windows (хотя именно под Windows до Delphi реально было очень мало адекватных сред разработки). Но по совокупности свойств Delphi стала прорывом и образцом для подражаний. Картинку попробую приложить, чтобы два раза не вставать, хотя вряд ли кто-то не видел подобных картинок:

Вот тут реально все возможные прелести собраны в одну кучу! Доведённый почти до совершенства язык Object Pascal (в каком далёком прошлом остались претензии Кернигана к бесполезному "учебному" языку, на котором ничего работающего написать невозможно?!). Нормальная разработка программ под Windows - все ужасы WindowsAPI полностью скрыты "под капотом", а наружу выставлена довольно разумная, и уж точно высокоуровневая библиотека Visual Component Library = VCL. Разработка программы на базе готовых компонентов в рамках модели ООП. Встроенная разработка форм с полноценным интерфейсом Windows, готовый доступ к базам данных, удобный доступ ко многим системным ресурсам... 

- Достаточно, Шеркало? Может быть хватит на сегодня? Может мне тоже пойти, хорька подавить?

- Кажется давно пора.

Шеркало 05.05: любимые системы программирования (Паскаль)

 - Ну так вот, Шеркало, после Фортрана, который мне не слишком понравился, особых вкусностей по сравнению с Алголом не давал, я увлёкся языком Паскаль. Сейчас уже точно не помню, не то это опять была моя личная инициатива, попробовать новый язык, не то моя учительница мне продвинутое обучение запланировала. Скорее всего было и то и другое одновременно - я захотел (уже сознательно, без влияния болезненно-высокой температуры), а учительница изо всех своих возможностей мне содействовала.

Тем более, что никаких проблем с Паскалем там и не было. Трансляторы этого языка имелись практически на всех компьютерах института, причём вполне рабочие трансляторы, вполне качественно исполняющие программы в рамках утверждённого стандарта языка. В том числе и на БЭСМ-6 компилятор работал. Вот только большинство сотрудников ИОА Паскаль в грош не ставили, оценивали его исключительно "детско-учебным" языком программирования. Писать на нём программы в среде учёных считалось как бы слегка дурным тоном для приличного взрослого человека, примерно как куличики лепить в песочнице детского сада.

Я закономерно спрашивал: "Почему?" Мне в ответ показывали книжки от умных зарубежных авторов, которые язык Паскаль разгромно критиковали за его подчёркнутую "ограниченность". Дескать, в языке не предусмотрена модульность (возможность компоновать единую программу из независимо написанных модулей), не предусмотрен сложный интерфейс ввода-вывода для современных каналов мэйнфреймов, нет возможности вызывать низкоуровневые операции различных компьютеров. Ах, да из-за строгой типизации нельзя (якобы) передавать параметром процедуры массив заранее неизвестного размера (вот уж совсем жестокое ограничение в языке, надо же, какое свинство лично от Никлауса Вирта!). Ну и тому подобное.

 Критика была с виду вполне справедливая, авторы были весьма именитые. Только что-то странно покалывало мне глаза при чтении. Почему-то казалось, что "родные" Алгол-60 и Фортран-IV точно так же не выдерживают той самой критики, как и Паскаль. А те положительные примеры, на которые ссылались умные авторы, были либо гораздо более современными разработками, либо вообще сугубо умозрительны. Захотелось попробовать самостоятельно. Здесь, кажется уместно привести картинки с текстом программы на Паскале:

- Здесь, правда, картинки слегка анахроничные - сделаны в TurboPascal 4.0, который появился только после 1987 года, спустя пятилетку после описываемого процесса моей школьной учёбы. Но это неважно, сам текст программы вполне аутентичен на то давнее время (кстати, прогонял эту же программу и в более ранних реализациях языка, доступных на сегодня в режиме эмуляции - успешно работает везде, но скриншоты хуже получаются). 

- Эээ, Ёж... С каким там тембром голоса принято у людей изображать скучающе-вопросительную интонацию? Ну и как там дальше было-то с любовью?

- Не подкалывай, Шеркало! Не мешай, дай рассказать!

Что видно при взгляде на паскалевскую программу? Да, в общем, всё то же самое, что и в Алголе-60. Та же структура. Те же вложенные BEGIN - END. Те же описания переменных, те же массивы ARRAY, те же процедуры PROCEDURE с параметрами. Операторы очень похожие. Ничего особенного и не поменялось. Отличаются, вроде бы, только нюансы.

Да, раздражающий лес апострофов из текста исчез. Описания переменных немного упорядочились, сосредоточились в начале процедур, отдельные блоки и операторы самостоятельность потеряли, параметры в процедурах упорядочились, со строками чуть-чуть интереснее стало, константы появились, типы свои опять же. Но... Это всё - мелочи, вроде бы  Реально поразило меня другое.

- Знаешь, Шеркало, была у меня на тот момент одна школьно-учебная задача. Сама по себе не слишком сложная, вполне учебная, вполне с виду, мне посильная. Но и не совсем тривиальная, там нужно было какую-то продуманную структуру из нескольких вложенных процедур с несколькими циклами под системой условий реализовать. Суть задачи уже абсолютно не помню! Помню только, что сходу решить не смог - несколько попыток (на Алголе-60), всё время то ошибки, то зацикливания в результате. Взял паузу. На пару недель отвлёкся, делал другие задания. Потом снова вернулся к этой задаче. Переписал всё заново, на свежую голову. Снова - ошибка на ошибке, никакого приближения к работающей версии.

Самое обидное, что я суть задачи - прекрасно понимаю, никаких неясностей нет! Все инструменты - у меня под рукой, ничего необычного не требуется, всё решается знакомыми средствами. А вот - ПУТАЮСЬ постоянно, то в одном месте, то в другом!!! Один узел распутаю, в другой части алгоритма ошибка вылезает. Опять бросил задачу. перешёл к другим темам.

А тут как раз начал пробовать Паскаль. Ну и ту, неподдающуюся, путанную задачу переписал уже в третий раз ради шутки на Паскале. Программа выполнилась без ошибок с ПЕРВОЙ попытки!

- Серьёзно?

- Именно так, Шеркало! Все места, где я в Алголе путался, в Паскале оказались плоскими и прозрачными. Вроде бы никакой существенной разницы, кроме нюансов и апострофов, а вот за теми нюансами виден только тёмный лес, а вот за этими - чистое поле для любых твоих действий.

Алгол-60 вдруг начал выглядеть передо мной в образе человека рассеянного с улицы Бассейной - из стихов Маршака: вроде бы умный, но тем не менее "...вместо шапки на ходу он надел сковороду, .. направился в буфет покупать себе билет..." В противоположность Паскалю, автором которого был Никлаус Вирт. 

Вирт сбежал из комитета по разработке Алгола далеко не сразу. Он очень активно участвовал в разработке Алгола-60. Активно критиковал этот стандарт (большей частью именно за нелогичную шизофрению), надеялся на то, что следующая версия Алгола (а никто и не сомневался, что будет новая версия, прежний Алгол-60 всем вменяемым учёным казался лишь промежуточным вариантом) будет намного более ясной и чистой. Вошёл в комитет по разработке новой версии языка Алгол-68.

И вот, когда Вирт убедился, что новый Алгол-68 получается лишь немного менее шизофреничным, чем Алгол-60, причём небольшое уменьшение шизофрении компенсируется огромным увеличением веса и сложности языка и трансляторов с него, вот в этот момент Никлаус Вирт окончательно разругался с "алгольщиками" и сбежал из этой группы разработчиков. И в пику им он создал Паскаль. Показал собственное видение успешного алгоритмического языка, а заодно и возможность его успешной реализации на современных компьютерах.

Нужно добавить, что Вирт терпеть не мог СЛОЖНЫХ компиляторов. В то время, оперативной памяти у компьютеров было крайне мало (десятки, очень редко сотни килобайт на современный счёт). Написать транслятор со сколь-нибудь сложного языка высокого уровня в машинный язык было достаточно трудно. Вопрос решался созданием много-проходных трансляторов. Они на первом этапе читали исходный текст программы, преобразуя его в набор промежуточных таблиц  - результат записывался в долговременную память, на ленты, барабаны, диски. Потом запускался второй прогон, который читал из файловой системы таблицы первого этапа, делал некие преобразования, на выходе писал в файлы новый комплект промежуточных таблиц, который читал компилирующий этап третьего прогона...

"... Потерпевший случайно сам упал на нож, получил смертельное ранение, внезапно поднялся, и этот процесс, снова и снова, повторялся аж восемь раз..." (с = анекдот) 

"Нормальные" трансляторы с Алгола, Фортрана, Кобола и т.п. в то время делали от 5 до 15 проходов с записью в долговременную память промежуточных результатов, и с вызовом многочисленных новых программ "частичных обработчиков" этих промежуточных результатов, которые, в свою очередь, читали входные таблицы из файлов внешней памяти, и писали новые выходные таблицы во внешнюю память, чтобы в итоге всё-таки после N+1 го частичного прохода компилятора получить исполняемый на конкретной ЭВМ двоичный объектный код (Уффф, не утомил никого этим предложением?). Для более громоздких языков (PL/1 на IBM/360) или для менее мощных (мини-)ЭВМ делали компиляторы и с бОльшим числом проходов, там и за двадцать-тридцать проходов, бывало, сильно зашкаливало. Аааа, забыл, извиняюсь, потом полученный объектный код ещё дополнительно линковать с внешними библиотеками и резидентными модулями Операционной Системы требовалось, это ещё от 1 до 5 прогонов программ-линковщиков, но это уже второстепенные издержки..

Большая сложность и много-проходность трансляторов обосновывалась объективной сложностью языков программирования: "Наш язык высокого уровня достаточно сложен и хорош, поэтому для него и требуется компилятор в N -проходов, а если меньше - будет сильно хуже!"

Вирт взялся доказать, что можно построить очень качественный и пригодный для реального программирования язык высокого уровня с компилятором, работающим в ОДИН проход. У него получилось!

Паскаль весь насквозь построен так, чтобы по первому же читаемому компилятором из входной строки символу было бы понятно, какая лексема далее ожидается, и чтобы никакая штуковина не использовалась бы в программе раньше, чем её интерфейс будет полностью известен. Компилятор Паскаля реально можно написать в однопроходном варианте Это - фантастика для тех времён! 

И одновременно... Реакция программистского сообщества: "Нуу.. И зачем вам такой однопроходный компилятор? Просто ради прикола? Стопяти-проходный транслятор у нас вышел бы ничуть не хужее, если бы мы только его вчерась дописали. И вообще, этот Вирт - просто академический теоретик, ничего сам не сделал, только по своим Швейцариям шлялся". 

- А ты, Ёж?

- Так я уже сказал, Шеркало! В Алголе - я откровенно запутался. А вот логика Паскаля - сразу мой мозг распрямила. Дальше учебные программы писал почти только на Паскале.

Шеркало 05.04: любимые системы программирования (Алгол-60 ч.3, Фортран-IV)

 - Так вот, я и говорю: Алгол, на котором нас учили писать учебные программы, стал мне постепенно надоедать...

- ОЙ!!! КТО здесь?!!

- Тихо, Шеркало, чего ты испугалось? Это же я, Ёж.

- Ааа, Ёж... А то я спросонья напугалось было. Несколько дней мочал, как попугай об лёд, а тут, вдруг, опять... Ну, ладно,  рассказывай, я уже проснулось.

- Ближе к концу 9-го класса школы, в 3-й четверти, я чем-то, уж не помню чем, серьёзно заболел. Меня целую неделю с хвостиком, может даже полторы недели, не выпускали из дома в школу, да и температура около 39-40 градусов держалась. Мне было очень скучно лежать большую часть времени под одеялом, да и мозги при температурах, близких к точке свёртываемости крови, работают совсем иначе, чем в прохладе. В итоге, я схватил попавшийся под руку учебник по языку Фортран-IV - это весьма древняя версия Фортрана, примерно начало 1960-х годов, но именно она тогда чаще всего использовалась учёными в ИОА. 

Я очень внимательно изучил этот учебник насквозь. Компьютера у меня дома возле кровати под рукой никакого конечно не было, даже программируемого микрокалькулятора не было, но возбуждённое повышенной температурой состояние мозга, на которое ещё накладывалось то, что в качестве жаропонижающих мне давали не только обычный парацетамол, но и, для разнообразия, димедрол с молоком (тогда - общепринятая практика), позволяло мне писать достаточно сложные программы (для начального учебного уровня конечно, "сложные") прямо в уме, в собственной памяти, даже без записи в тетрадь. Позже, после выздоровления, я в ИОА получил возможность реально набрать (или заказать на перфокартах) некоторые из моих "бредовых" фортрановских программ, и запустить их на БЭСМ-6 или на М4030. После исправления незначительных ошибок, они оказались вполне работоспособными.

- Ну и какое было впечатление о "настоящем, промышленном" языке программирования?

- Какое моё основное впечатление о Фортране (подчеркну, о ранних версиях Фортрана, до конца 70-х годов)? Впечатление очень простое: Фортран - очень IBMовский язык! Фирма IBM изначально ведь делала не компьютеры! Она прежде всего прославилась своими табуляторами и сопутствующим перфокарточным оборудованием. Как в анекдоте: "Что бы не делали в СССР, гречневую кашу или, например, туалетную бумагу, а всё равно на выходе автомат Калашникова получается". 

Так вот, что бы не делала фирма IBM, вплоть до почти середины 1970-х годов, у неё всё равно в итоге получался табулятор, ориентированный на работу с перфокартами. Язык Фортран - он исходно весь сплошь перфокарточный. Там единица языка отнюдь не оператор. Единица языка - строка в 80 символов, разбитая на зоны колонок (читай - ПЕРФОКАРТА!). я даже не хочу здесь картинку типичной фортрановской программы приводить. 5 колонок отведено под метку (она же - тупо номер строки). Одна колонка - признак строки-продолжения предыдущей. Далее идёт сам оператор (или информация), в идеале - один оператор = одна перфокарта. Последние 8 символов строки(карты) транслятор игнорирует - теоретически это место предназначено для маааленького комментария, но на практике, некоторые ранние модели перфосчитывателей/перфораторов просто часто допускали сбои чтения/записи в этих колонках (карта на выходе из тракта механически плохо удерживалась, вихлялась) проще было эти колонки тупо принудительно пропустить, чем потом ошибки ввода/вывода отлавливать. 

Весь ввод и вывод такой же - таблицы, представляющие собой отформатированные по колонкам перфокарты. Многочисленные операторы FORMAT, определяющие форму ввода/вывода отдельных строк в общей структуре таблицы. Отдельные извращения с текстовыми константами в этих форматах - константы Холлерита, ага, прекрасный решение костыль.

Структура программы? Что? Какая структура? А ЗАЧЕМ она?! Зачем какая-то структура, если вся программа построчно УЖЕ заранее пронумерована (ну, или она МОЖЕТ быть вся пронумерована, поскольку каждая перфокарта в колоде заведомо уже имеет свой уникальный номер по определению). Просто говорим, какой номер строки будет следующим оператором, и всё, без особых изысков. Типичное наследие ранних компьютеров с 3-х адресной системой команд - там третий адрес как раз был адресом следующей выполняемой операции...

- Ой, Ёж, я заслушалось. прости. Так какой вывод? Традиционный вопрос, что там у тебя было к Фортрану насчёт любви?

- Нет, Шеркало, к Фортрану никакой любви у меня ни чуть-чуть не было. Да и программы я на нём почти не писал - не представлялось никакого смысла. А вот УВАЖЕНИЕ к этому языку, я получил на полную катушку. Ещё раз напомню, изначально выбор между двумя возможными языками обучения школьников, Алголом-60 и Фортраном-IV, для меня был очевиден: конечно же современный Алгол на порядок лучше заведомо устаревшего Фортрана! А вдруг оказалось, что всё не так очевидно.

Преимущества Алгол - современная структура программы, структурное программирование. Недостатки Алгол - да там же уши мартовского зайца-шизофреника из каждой строки торчат!!! Какое там структурное программирование, если в документации через абзац упоминаются переключатели и метки, если передачу параметров в процедуры проектировали те же шизофреники, если вместо внятной работы с арифметикой есть куча слабо определённых неявных преобразований?!

Преимущества Фортран - никакой шизофрении, всё чётко определено и предсказуемо (правда, только до следующей версии, но это же другое. не так ли?). Железная логика программы. Качественно прописанный (хотя и жутко тяжеловесный, ну, так поищите лучше!) табличный ввод/вывод. Куча готовых вычислительных подпрограмм на научную тематику. Недостатки Фортран - никакого структурного программирования! Забудьте о современных парадигмах программирования вообще!!! Только перфокарты  Если у вас вдруг уже есть терминалы для непосредственного доступа к компьютеру- значит эти ваши терминалы будут просто эмулировать устройства чтения или печати перфокарт. Забудьте о функциональном программировании, забудьте о рекурсиях вообще!

Ну, о работе с символьной информацией ещё более отдельный вопрос. Ни в Алголе, ни в Фортране этого не было совсем! Потом добавлялось, но опять же, смотри ниже итог... А символы и строки были реально нужны и интересны.

Итог? Ничья, 1:1. Алгол-60 и Фортран-IV оказались примерно шилом с мылом в одном мешке. То, что наши преподаватели предпочли Алгол - совершенно нормально. Структурное программирование в плане обучения школьников перевесило достоинства Фортрана. Однако, вряд ли такое решение было принято легко и единогласно. То, что учёные ИОА в большинстве тогда предпочитали Фортран - тоже абсолютно нормально. Им ведь формулы быстрее считать надо было и таблички рисовать, а не шашечки на полировке структурного программирования разглядывать. А готовых библиотек для расчёта разных формул у Фортрана было явно больше, да и табличный ввод/вывод - вполне развитОй.

Шеркало 05.03: любимые системы программирования (Алгол-60 ч.2)

 - Подъём в погранистических войсках! Давай, Ёж, просыпайся и рассказывай, чем тебя тогда Алгол-60 разочаровал? Все же его вроде всегда хвалили, говорили, что он на кучу современных языков программирования прямо чуть ли не решающее влияние оказал? Что, врали?

- Нет, конечно не врали, влияние точно оказал... Дело в том, что Алгол изначально создавался не как практически реализуемое на компьютерах средство написания реальных программ, а скорее как удобная форма обмена (на бумаге в первую очередь) алгоритмами между учёными-математиками разных стран мира. Такой, вроде, алгоритмический язык "Эсперанто", псевдо-код для интуитивного понимания. А его практическое использование конечно подразумевалось, но только во вторую очередь. Наверное надо привести для примера картинку с текстом программы на Алголе:

Это не реальный текст с компьютера, это картинка из книжки. Можно сразу обратить внимание на несколько моментов:

1. Некоторые слова выделены жирным шрифтом - это ключевые слова языка (служебные слова). Разработчики Алгола считали, что служебные слова всегда должны ЯВНО отличаться от остальных слов. При бумажных публикациях их выделяли шрифтом, как в этом примере. А на реальных компьютерах, где не предусмотрено несколько различных шрифтов?

2. Программа (точнее процедура) красиво оформлена пробелами. Каждый оператор, каждый блок, выделяется своим уровнем отступа от левого края текста - так легче читать.

3. Меня лично немного фрустрирует заголовок процедуры (первая строка). Я с первой (да и со второй тоже) попытки не могу понять, что в контексте процедуры означают слова "Absmax, Size, Result, Subscripts". В каких случаях и для чего каждое из этих слов можно использовать, почему они не разделены запятыми или другими знаками препинания, в каком отношении друг к другу состоят? Почему "(n,m)" следует после "Size" кажется вроде понятно, но почему тогда "(a)" следует именно за "Absmax"? В этом какой-то скрытый смысл или случайное совпадение? А пара "n, m" в описании повторяется аж три раза. Это важно? Можно было повторить больше или меньше раз? А если описания в другом порядке переставить, что-то сломается или нет?

А теперь приведу другой пример, уже не из книжки. Это пример реального текста программы на Алголе-60 для реального компьютера. Мы запускали на БЭСМ-6 примерно вот такие программы:

'PROCEDURE'EULER(FCT,SUM,EPS,TIM);'VALUE'EPS,TIM;'INTEGER'TIM;'REAL' 'PROCEDURE'FCT;'REAL'SUM,EPS;
'COMMENT' EULER COMPUTES THE SUM OF FCT (I) FOR I FROM ZERO UP TO INFINITY BY MEANS OF A SUITABLY REFINED EULER TRANSFORMATION;'BEGIN''INTEGER'

          I,K,N,T;'ARRAY' M(/0:15/); 'REAL'MN, MP, DS;        I:=N:=T:=0;M(/0/):=FCT(0);SUM:=M(/0/)/2;NEXTTERM:I:=I+1;MN:=FCT(1);'FOR' K:=0'STEP'1'UNTIL'N'DO''BEGIN'MP:=(MN+M(/K/))/2;M(/K/):=MN;

            MN:=MP'END'MEANS;
    'IF' (ABS(MN)'LESS' ABS (M(/N/))'AND'N'LESS'15)'THEN'
 'BEGIN'DS:=MN/2;N:=N+1;M(/N/):=MN'END'ACCEPT'ELSE' DS:=MN;SUM:=SUM+DS; 'IF'ABS(DS)'LESS'EPS'THEN'T:=T+1'ELSE'T:=0; 'IF'T'LESS'TIM'THEN''GOTO'NEXTTERM'END'EULER;

Что в этом тексте бросается в глаза, по сравнению с первой картинкой?

1. Нет никаких выделений жирным шрифтом, зато есть масса рассыпанных по тексту знаков апострофа ('BEGIN''END''FOR''INTEGER' и т.п.). Всё правильно. Выделение служебных слов в Алгол-60 никто не отменял, а раз не получается выделять их шрифтом (ну нет такой возможности у БЭСМ-6!), значит будем выделять чем-нибудь другим, например апострофами спереди и сзади. А то,  что от этого леса кавычек рябит в глазах, и текст становится крайне плохо читаемым, ну так это мелкие побочные эффекты. просто нужно немного привыкнуть.

2. Бросается в глаза полное отсутствие форматирования текста. Никаких отступов, операторы начинаются где попало, разрываются на строки как попало и т.д. Нет, вот это вовсе не есть обязательная фишечка. На реальных компьютерах нам никто, разумеется, не запрещал писать красиво структурированные тексты программ со всеми полагающимися отступами. Но вот...

Вот ты - неопытный школьник. Тебя посадили за терминал ЭВМ. Включили тебе простейший текстовый редактор. У тебя на ввод и прогон своей учебной программы есть ровно 30 минут! Через 30 минут тебя просто вышвырнут из терминального класса за шкирку, независимо от результата работы, а там жди неделю до следующего захода в класс. Текстовый редактор обеспечивать автоформатирование текста ещё не научился, а ты сам работаешь на клавиатуре пока ещё в "двухпальцевом" режиме. И что ты будешь делать? Будешь старательно ручками выравнивать каждый оператор по началу строки нужным количеством пробелов (считая пробелы в уме), или постараешься как можно быстрее ввести текст программы без всякого форматирования, "лишь бы заработало"?  По-моему, ответ очевиден. Плюс к тому, даже если и попытаешься сначала соблюдать отступы, то при первом же исправлении ошибок всё форматирование всё равно съедет вкривь. А исправлений (по неопытности) будет много, а терминального времени катастрофически не хватает.

3. По третьему пункту, я там на верхней картинке придрался к структуре заголовка процедуры. Это понимание приходило с опытом. Постепенно даже мне (школьнику) становилось ясно, что Алгол-60 в некоторых местах - это просто какая-то дичайшая шизофрения группы разработчиков под девизом "Лебедь+Рак+Щука=Поехали". Недаром многие нормальные люди, включая Никлауса Вирта, из этой группы быстро сбежали.

Могу просто привести цитаты из официальной документации на Алгол-60:

4.7.6 Метки в качестве параметров

 Метка может вызываться значением, несмотря на то, что не существует переменных типа метка.

4.7.7 Ограничители параметров

Все ограничители параметров считаются эквивалентными. Не устанавливается никакого соответствия, между ограничителями параметров, используемыми в операторе процедуры, и ограничителями, фигурирующими в заголовке процедуры, кроме того лишь, что их количество должно быть одинаковым. Таким образом, вся информация, которая вносится употреблением сложных ограничителей, полностью избыточна. 

Перевожу на русский с брюссельского:

"Мы тут придумали очень красивые заголовки для передачи параметров в процедуры, но вы на них не обращайте внимания, поскольку они в нашем языке полностью избыточны и реализованы никогда не будут. А ещё у нас есть метки, которые являются переменными, поэтому могут передаваться по своему значению, но переменных которые бы принимали значения меток у нас в языке нет и не будет. Что? Куда можно присвоить значение того, для чего нет переменной? Гусары молчать! Его можно присвоить параметру процедуры, а уж он как-нибудь там сам внутри процедуры разберется, как передать своему формальному параметру значение, которого у того просто не может быть. Неувязочка получается, говорите? А нам пофигу на эту неувязочку. Мы здесь СТРАТЕГИЕЙ развития науки программирования занимаемся, вотъ! А над неувязочками пусть потом конечные пользователи головы ломают, им жить с того веселее будет.".

Это, повторяю, не моя шизофрения, это - дословные цитаты из официальной (одобренной международным учёным комитетом) документации на Алгол-60.

Понятно, что такие подробности я никак не мог заметить сразу, при начале обучения. Но постепенно, начал на подобные "неувязочки" натыкаться. В первую очередь стало мешать обилие апострофов, щедро рассыпанных по всему тексту, застилающих смысл решаемой задачи. Потом свою роль сыграла и синтаксическая сложность деклараций, которые в Алголе распределены по нескольким строкам, и далеко не всегда взаимоувязаны между собою.

Проще говоря, я начал реально запутываться в тексте собственных программ. Очень неприятное ощущение - чувствуешь себя откровенным дураком на ровном месте. Ну, а что было дальше - следующий текст.

Шеркало 05.02: любимые системы программирования (Алгол-60)

 - Итак, Шеркало, не отвлекайся!

- Я внимательно внимаю, о, Ёж!

- Я вспоминал о своей школьной учёбе в старших классах на УПК (учебно-производственный комбинат) в НИИ ИОА (Институт Оптики Атмосферы). И нашими преподавателями были назначены простые нормальные сотрудники института, а школьного предмета "Информатика" тогда ещё не придумали, никаких учебных программ не было. Так вот, эти преподаватели собрались вместе и стали думать думу, как бы так нас получше выучить, когда никто не знает - как.

- Чего-чего?

- Ты, не отвлекайся! Это я просто так додумываю. Меня, школьника, никто на их совещания не приглашал. Но по результатам ведь можно попытаться угадать исходную задумку?

Основная идея была красивая и абсолютно правильная: "Наших детей нужно обучать программированию не в "бумажном" режиме (карандашом в тетрадке и мелом на доске), а на настоящей "взрослой", работающей ЭВМ!" А подходящая для обучения школьников ЭВМ в то время в институте была лишь одна - БЭСМ-6. Только она обладала и нужными вычислительными ресурсами, и достаточной надёжностью, и работающим терминальным залом с разделением времени. Все остальные компьютеры либо ломались и зависали через каждые 30 секунд (ЕС ЭВМ и другие клоны IBM/360), либо были слишком маломощны (ранние СМ ЭВМ и младшие клоны PDP-11), либо в институте не было ни единого специалиста, который бы знал, где у этой ЭВМ кнопка "ВКЛ/ВЫКЛ", и с какой стороны в неё программа вставляется (МИР-2). А персональных компьютеров тогда в городе вообще практически ни у кого и не было.

Итак, должна быть выбрана БЭСМ-6, плюс настоящий "взрослый" язык программирования. А вот таких языков в ИОА на БЭСМ-6 было в те времена ровно две штуки - Фортран и Алгол-60. Нет, в институте при желании и необходимости использовали и другие языки (например набирающий популярность на мини-ЭВМ минималистичный язык "С", или стремительно теряющий популярность ассемблер IBM/360, или слывущий исключительно учебным языком "Pascal", или даже совсем экзотический "Forth"), но мэйнстримом для научных сотрудников были именно Фортран (бОльшая доля), и Алгол-60 (меньшая часть). Так какому же языку учить детей, чтобы не ошибиться?!

Наши преподаватели вполне ожидаемо предпочли Алгол-60. На тот момент я с ними был полностью согласен. Фортран, хотя и активно использовался учёными, из-за наличия кучи готовых пакетов математических процедур, но для обучения программированию выглядел уж слишком архаично. Алгол всё-таки был практически современным, структурным языком. Вот так и получилось, что нас стали на УПК учить Алголу-60, в одной из реализаций на БЭСМ-6 (кажется, это был Алгол-ГДР, но могу ошибаться). Мы писали программы на Алголе в обоих доступных режимах: и сами вводили руками с клавиатуры терминала, тут же запуская на трансляцию и выполнение, получая через несколько секунд результат на экран, и, если программа предполагала сколь-нибудь длительный счёт, или вывод более 20-30 строк, то в пакетном режиме. 

О пакетном запуске, конечно нужно рассказывать отдельно, сейчас такое и не увидишь. Нам выдавали специальные типографские бланки, разбитые клеточками на строки по 80 клеточек в каждой строке. Мы писали текст программы обязательно заглавными латинскими буквами, обязательно по одному символу в каждой клеточке, обязательно строгим печатным шрифтом. Потом складывали бланки со своими программами каракулями в специальную картотеку с отдельными пронумерованными ячейками (как сумки на входе в супермаркет, только ячейки меньшего размера и ключиком не запираются). Бланки по очереди забирали из картотеки операторы клавишного ввода (они уже сидели в закрытой машинной зоне, куда никого постороннего не пускали). Операторы ввода печатали программы с наших бланков руками на клавиатуре перфоратора. 

К утру следующего дня в твою ячейку картотеки возвращали бланки с текстом, а вместе с ними колоду перфокарт, с пробитыми дырочками. Нужно сказать, что операторы (точнее операторши) ввода были профессионально-мстительны. Стоило лишь чуть-чуть неаккуратно написать на бланке какой-то символ, как они обязательно, старательно, пропечатывали на его месте другую, ошибочную букву, даже если сами по смыслу текста отлично догадывались, что там на самом деле должно быть напечатано. Ведь не идиотки, же, грамотные девушки, слова из букв умеют самостоятельно составлять! А вот вам, профессиональная аберрация: раз позволяете себе неаккуратный почерк, значит, из принципа, получите на выходе бракованную колоду перфокарт. Чтобы в следующий раз неповадно было как курица лапой писать или прописные буквы вместо заглавных печатных использовать! Никаких скидок на школьный возраст.

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

Собранную колоду перфокарт складывали "на выполнение" в свободную ячейку другой картотеки перед входом в машинный зал. А на утро следующего рабочего дня забирали из этой ячейки свою колоду с результатом работы - распечаткой на бумаге. Кстати, во времена БЭСМ-6 термин "принтер" для устройства распечатки текста у нас не применялся. Эта штуковина называлась АЦПУ (Алфавитно-Цифровое Печатающее Устройство), размером оно было с приличный комод (или целых два комода), грохотало, как слегка поломанный тяжёлый танк, жрало с огромной скоростью и в невероятных количествах ленту широкоформатных бумажных листов, с перфорацией (для равномерной протяжки бумаги) по бокам. Сами листы отделялись в ленте один от другого тоже перфорацией, поперечной и мелкой, как на рулоне туалетной бумаги.

До сих пор не могу забыть то невероятно острое чувство стыда, когда я пришёл забирать результаты прогона своей очередной учебной программы и обнаружил, что моя ячейка в картотеке пуста. Но тут же открылась дверь машинного зала, начальник дежурной смены обслуживания БЭСМ торжественно подошёл ко мне, держа в руках огромную стопку листов бумаги формата А3, сплошь испечатанную бесконечными строчками нулей: "Вот результат, выданный твоей программой! Это мы бесконечный цикл ещё по времени выполнения прервали, а то и больше могла бы напечатать". Пачка бумаги весила, кажется, немногим меньше 10 кг. Я буквально готов был "провалиться в ад", а вокруг стояли сотрудники института (большинство незнакомые), аплодировали. и, улыбаясь. поздравляли меня с установлением очередного месячного рекорда по бесполезному расходу бумаги. Никогда больше я не позволял себ...

- Ёж, ты кажется опять слишком увлёкся! Что там про Алгол-60? Что там про любовь, была или нет?

- Вот чёрт! Шеркало! Умеешь же прервать меня на самом интересном месте!

- Так это... Обработка прерываний - одна из базовых функций любого нормального компьютера. Учись, значит, прерываться!

- Чёрт, чёрт! Про какой ещё Алгол-60? Про какую ещё любовь?! Ах, да, там в заголовке текста так написано... Ладно, так и быть. Была у меня любовь к Алголу-60, была не спорю. Но она... самоликвидировалась, вот!

- Чтоооо?!

- Считай, что это была не любовь, а юношеская влюблённость. Мне действительно весь первый год моей учёбы (9-й класс школы) очень нравился Алгол. Изящный, быстрый, структурный. Да к тому же и "ты у меня ПЕРВЫЙ" (ну, почти первый). Но постепенно я начинал изучать (большей частью самостоятельно и по своей собственной инициативе) другие языки программирования. И тут-то моя любовь к Алголу начала так же постепенно меркнуть. Впрочем, об этом в следующем рассказике.

- Эй, стой! Ты хоть пример программы на Алголе-60 здесь выложи! По традиции, а?

- Не хочу. Постараюсь в следующем рассказе дать пример, чтобы стало понятно, из-за чего разочаровался.

Шеркало 05.01: любимые системы программирования (Рапира)

 - Миша, звал7

- Хм. Кажется звал. Хотя, это было в моём сне. Только не называй меня "Миша", пожалуйста, Шеркало.

- А как надо?

- Называй меня, например, Ёж!

- Вот нифигасе! Впрочем, как скажешь, Ёж. Так для чего ты меня звал? В прошлый раз, кажется, хотел что-то про язык Паскаль рассказать?

- Я уже передумал!

- А что, и так можно было, а, Ёж?!

- Не ёрничай, Шеркало! Я решил немного расширить тему. Просто молчи, слушай и отражай, если пожелаешь. Ты, знаешь, у людей есть такое понятие - "первая любовь". Это, когда то, что первый раз тебя впечатлило, становится потом идеалом на всю оставшуюся жизнь, даже, если объективно это вовсе и не идеал.

- Ну, Ёж, ты меня порадовал. Ты мне, своей зеркальной тени, пытаешься объяснять, что такое "импринтинг" (оно же "запечатление")?! И, кстати, ты ошибаешься, если полагаешь, что импринтинг свойственен лишь людям. Да, многие приматы эту фишечку при воспитании детей активно используют, но и другие млекопитающие тоже, и очень многие птицы. Да и рептилии тоже, хотя учёные это пока вроде бы не особо исследовали...Я уверено - у горгонопсов перед великим пермским вымиранием импринтинг уже заметную роль играл. Впрочем доказывать не берусь.

- Ладно, можешь не доказывать. Всё равно тебе не поверят. А я вообще о другом хотел вспомнить - о первом своём языке программирования.

- И что же это было? BASIC наверняка?

- Ошибаешься! Моим первым языком программирования была "Рапира". Выглядела она примерно вот так:

Вот только работала эта самая Рапира исключительно на компьютерах "Агат" (первый раз нам её показали на импортном компьютере "Apple II+" (с которого тот Агат и пытались тогда в СССР копировать)). А у нас в Томске ни Агатов, ни Apple'ов под рукой не было. Правда, там по ссылке в Википедии говорят, что существовал транслятор Рапиры для машины БЭСМ-6 (которая у нас как раз была), но вот я лично его не видел. В итоге, толком поработать на Рапире мне и не довелось. Но, кажется, сожалеть о том не нужно.

- Прям совсем уж примитивно было?

- Нет, Шеркало, не совсем. Рапира была по-сути студенческой разработкой в Новосибирском Университете (НГУ). Так тогда было модно. Для сравнения с западом скажу, что и язык Паскаль (и его развития Модула и Оберон), тоже были студенческими университетскими разработками, получившими популярность благодаря руководящей и направляющей руке Никлауса Вирта. И супер-популярный ныне Python - тоже изначально студенческая разработка. И Рапира была в том же ряду, ничуть не хуже! Если бы развивалась - могла бы стать в один ряд с Python, во всяком случае идеи там очень похожие (только отступов в Рапире не предусмотрели). Но разнице в уровне и в судьбе научных руководителей предопределила разницу в судьбе языков.

А амбиции были! Как тебе "Марш разработчиков Рапиры"?

Мы рождены, чтоб сказку сделать былью,
Чтоб мир забыл про Бейсик и Кобол.
Нас Крокодил вооружил Рапирой,
НИИ ВК дал каменный топор.

Все шире, и шире, и шире
Становится день ото дня
Любимая наша Рапира -
Система грядущего дня.

Рапиры штык вонзался в каждый атом,
Ее булат прочнее всех мечей.
И в нужный час монбланы из АГАТов
Переломаем в горы кирпичей.

Все реже, и реже, и реже
Развалы в системе у нас.
И каждая строчка содержит
Теперь вычислительный класс.

Швыряя ДОС и Бейсик в бокс позорный
И наблюдая плавный их полет,
Мы без гроша оставим Commodore'а,
А фирму Apple пустим на компот.

Все ближе, и ближе, и ближе
Побед и триумфов черед.
Пусть в Риме, Нью-Йорке, Париже
Увидят Рапиры восход !

- Мощно, Ёж! Это ты сочинил?

- Ну что ты! НЕТ конечно, это типичная студенческая песня, сочинена группой разработчиков Рапиры.

- А при чём тут НИИ ВК? И что такое крокодил?

- НИИ ВК - это контора, которая с переменным успехом разрабатывала компьютеры "Агат". Агаты предполагались для поставки в школы, в качестве учебных школьных компьютеров. И Рапира предполагалась одним из основных языков программирования для этих компьютеров. Кстати, более поздние версии языка Рапира (я их, к счастью, уже не застал, а то бы очень расстроился) сильно напоминали по синтаксису "Е-практикум", он же "Учебный алгоритмический язык" Ершова - псевдо язык программирования, для описания алгоритмов в школьных учебниках Информатики.

А Крокодил - не что, а кто. Это кличка, прозвище, Геннадия Анатольевича Звенигородского, человека, который как раз и руководил студенческой группой, создававшей Рапиру. К огромному сожалению, Г.А. Звенигородский скоропостижно умер в 1984 году, после чего развитие Рапиры было практически полностью свёрнуто. 

Но у нас в Томске, никаких Агатов тогда не было (их на тот момент - вторую половину 1983 года, если правильно помню - и 10 штук на весь СССР сложно было бы найти), как и уроков Информатики тоже не было, их ещё не придумали. У нас были стандартные для школ того времени уроки труда в старших классах - назывались "Учебно-производственный комбинат" (УПК), этакая якобы близкая к жизни трудовая практика на реальных предприятиях перед выпуском из школы. А поскольку наша школа располагалась в академгородке, то одним из предлагаемых вариантов УПК оказалось обучение программированию на реальных живых компьютерах в одном из НИИ - Институте Оптики Атмосферы (ИОА). Следует заметить, что школьного предмета "Информатика" в то время ещё НЕ существовало, мы занимались на компьютерах именно в рамках УПК, отнимая дефицитные вычислительные ресурсы у сотрудников НИИ. Преподавали нам тоже не профессиональные педагоги, а на "общественных началах" обычные научные сотрудники и инженеры ИОА, причём программу обучения они кажется тоже разрабатывали самостоятельно.

- Ёж, погоди, не уклоняйся от темы! Ты начал про "первую любовь", вроде? Так всё-таки Рапира была твоей любовью, или, как ты выразился, "толком на ней и не поработал"?

- Второе, точно. Рапира к числу моих любовей, пожалуй, не относится. Да и померла она слишком быстро, развития так и не получила. Хотя, повторюсь, перспектива у неё чисто теоретически была, уровень идей, как и уровень реализации, был круче раннего Python. А про любовь продолжим в следующий раз.

Продолжение от 2022 года.

Собственно, в этом месте я хотел закончить свой рассказ о языке Рапира. В самом деле, что я мог ещё сказать? Мой личный опыт использования Рапиры закончился в 1985. Сам язык смерти своего вдохновителя Г.А. "Крокодила" Звенигородского, очевидно тоже не пережил, и скончался тогда же, в середине 1980-х. Так о чём ещё говорить?

Но что-то странное продолжало меня беспокоить. Чем дальше, тем сильнее. Рапира давно мертва, на ней точно никто ничего не пишет, но почему же я вижу её следы в текстах программ моей дочки? И ведь чем дальше, тем более ясные и вовсе не призрачные следы! Прямо мистика, и мурашки по коже!!!

Ответ я нашёл, мистика исчезла. Всё оказалось очень прозаично. Наследник нашёлся. Это язык Python (даже упомянутый мной выше и раньше), на который я уже писал шуточную рецензию. Python вовсе не зомби, это вполне современный, очень популярный, весьма распространённый язык. Просто между началом популярности Python и концом Рапиры прошло больше десятилетия очень бурного развития отрасли ИТ. Сложно было сразу заметить явную связь между языками из разных эпох. А всё просто:

В Википедии, в статье про язык Рапира, говорится, что он основан на двух более ранних языках (цитата):

"... Язык построен на основе объединения возможностей языков Сетл и Поплан. Изначально был реализован как набор макрорасширений на базе языка Поплан — интерпретатора языка POP-2 ..."

В более раннем варианте вики-статьи Сетл кажется даже не упоминался (могу ошибаться, но меня именно отсутствие упоминания Сетл тогда удивило, поэтому и запомнилось!) - только Поплан. На самом деле в Рапире от Поплана нет почти ничего, разве лишь странное присваивание "слева-направо" - оно именно из Поплана взято. А вот Сетл - реальный духовный предшественник Рапиры.

А что мы знаем про Сетл? Ну понятно, есть статья в Вики, но гораздо интереснее воспоминания с новосибирской стороны из Компьютерного музея. Оказывается, Сетл был хорошо известен и высоко оценен в СССР в целом, и в Новосибирском Академгородке в частности. И было очень продуктивное международное сотрудничество по доработке, развитию и применению этого языка и положенных в его основу идей! Но в 1980 Брежнев приказал ввести войска в Афганистан. Всякое международное сотрудничество между программистами СССР и США с этого момента мгновенно прекратилось.

Что было дальше? Язык Сетл к тому моменту был большей частью БУМАЖНЫМ языком. Никаких промышленных реализаций не было, до них дело не дошло. Только чистые демонстраторы перспективных идей в форме алфа- бета- версий с крайне ограниченной функциональностью для подсветки светлого будущего. Развивать эти идеи на западе и в СССР продолжили независимыми путями.

Со стороны СССР осталась, в частности, новосибирская команда академика Ершова, в которую был приглашён лидером (не сразу лидером, сначала МНС, как водится) молодой перспективный Звенигородский. Эта команда, сначала формально следуя довольно шаблонно-традиционным рамкам системы Школьница, тем не менее рискнула выдвинуть к вниманию руководства абсолютно революционную на тот момент Рапиру.  Проблема была в технической базе - ну никак НЕ укладывалась Рапира (да и вся Школьница тоже) в технологии ВЦ на базе БЭСМ-6. Как манны небесной ждали появления персональных компьютеров, прежде всего надеялись на обещанные промышленностью Агаты. Агаты появились на пару лет позже, чем их в самом крайнем случае ожидали, при этом показали себя не только запоздалыми, но и зашкаливающе деьмовыми! Тем не менее, даже на фоне этого невменяемого дерьмищща, Рапира смотрелась, как яркий луч надежды. Даже на Агатах она блистала изящными возможностями - только дайте этой талантливейшей команде разработчиков чуть-чуть более надёжную и современную среду, вот там-то уж можно будет развернуться!

Смерть Звенигородского совпала с внедрением первых серийных Агатов. Страна шла к развалу. А тут ещё и смерть академика Ершова. Рапира больше никого не интересовала.

А что со стороны Запада? Коммерсанты там тоже Сетл не поддержали (впрочем, с самого начала и не собирались). Но Университетская среда Сетл оценила высоко. В том числе, планировали использовать идеи Сетл в системах обучения студентов. Для этого, в частности, разработали специальный язык программирования ABC. Вы, возможно, несколько удивитесь, но в разработке языка ABC на младших ролях активно участвовал некто по имени Гвидо ван Россум. ABC, в отличие от Сетла был отнюдь не бумажным языком, его вполне реализовывали силами студенческих команд. Другой вопрос, что и функциональность реализуемого языка была более-менее близка к учебной, а не к промышленной.

Ну а потом была опять же учебная ОС Амёба, где тоже приложил руку ван Россум. А ещё позже, понадобился новый скриптовый интерпретируемый язык, но уже промышленного уровня. И этот самый Гвидо ван Россум предложил такой язык, благо он подобные штуки проходил к тому времени уже не раз и не два....

Вот и имеем результат. Python известен повсеместно. Рапиру не знает никто. Кстати, Сетл тоже никто не знает, но это и справедливо - Сетл никогда не был реализован в приемлемой конфигурации. А вот Рапира - таки была реализована.

Только Геннадий Анатольевич "Крокодил" Звенигородский, родился не совсем в том месте и не совсем в нужное время. Ещё хуже, умер он совсем уж точно не в нужное время.

А Гвидо ван Россум, вероятно, родился когда и где надо. Поэтому все учат Python, но никто не помнит Рапиру.