- Шеркало, Шеркало, на окне лежало, под кровать упало,
О порог споткнулось, испугалось, и сразу убежало! Ты где?
- А говорят, что один Ёж как-то раз шёл, шёл, потом споткнулся,
Потом сразу забыл, как дышать. и внезапно задохнулся! Ты как себя чувствуешь?
- Сейчас, кажется, пока ещё нормально. Рассказать тебе чего-нибудь ещё, про любовь?
- Что ты всё про любовь, да про любовь? А вот были у тебя измены твоим любимым языкам?
- Ну ты и вопросы задаёшь! Тема прямо-таки даже на удивление по-людски выглядит. Только языки и стили программирования, это же не любимые люди. Они бесчувственны (хотя и далеко не безличностны!), боли и терзаний не испытывают. Изменять языкам - нормально, и даже, временами, хорошо - сообществом программистов измена одному языку в пользу другого даже часто морально поощряется, называется это: "профессионально-личностный рост". Давай, попробую рассказать.
Начать, наверное нужно с моей измены Паскалю, о котором я говорил в предыдущих двух частях. Дело в том, что уже в первой половине 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). И преподаватели, прежде всего продвинутая молодёжь, понемногу стали обращать внимание в том числе и на персональные СУБД.
Для обучения обычно выбирали самых старательных девочек-отличниц-старшекурсниц. Считалось, что именно они наиболее способны к освоению подобной коммерчески-ориентированной технологии. Я сам ни к категории девочек, ни к категории отличниц разумеется не принадлежал, поэтому начало процесса прошло совсем мимо меня. Однако даже я стал замечать, что некоторые мои однокурсницы на лабораторных работах отсаживаются отдельно и делают что-то своё на таинственно-чёрных экранах, периодически перешёптываясь с аспирантами. Я, из любопытства, попытался узнать, чем они занимаются. В ответ всегда звучали таинственные слова: "Работаем на Клиппере!" Кто такой этот "клиппер" я понять не мог (Интернета-то тогда не было, гуглить было негде!). Но название само по себе звучало очень красиво и романтично. В конце-концов я всё-таки уговорил одну из однокурсниц показать мне ближе свою лабораторную на экране. Увидел я примерно вот это:
Я несколько секунд тупо смотрел на экран (кстати, прошу корректность кода программы с картинки оставить на совести той Лены, а ко мне претензии не предъявлять. Я и сам отлично знаю, что эта программа на самом деле работает не совсем так, как её автор заявляет!).
- Так это же обычный 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, даже самой коротенькой, я не написал.
Всё, продолжение в следующем сеансе связи.
Комментариев нет:
Отправить комментарий