egorius: (Default)

А. Флорес, «Внешние устройства ЭВМ» (1977)

Внезапно захотелось почитать про перфоленты и перфокарты, магнитные ленты и барабаны и прочие древности.

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

Долго думал, как Ivan Flores превратился в А. Флореса. Оказалось, Айван.

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

egorius: (Default)

Подумалось тут. Раньше, когда компьютеры еще были большими, но интернет уже появился, он был набором протоколов. Telnet, smtp, nntp, ftp... Ну и позже http, как один_из.

Потом паутина окончательно захватила мир, и синонимом интернета для обычного пользователя стал браузер. В него интегрировалась почта, поддержка news, ftp, новомодных rss и чего там еще было.

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

А сейчас все подрастающее поколение денно и нощно сидит в ВК. Там они знакомятся, общаются, ссорятся, мирятся, читают новости и слушают музыку. Для них интернет — это ВК. Надо что-то найти в интернете? Они ищут в поисковой строке ВК. Недавно ребенке надо было отправить задание олдскульной учительнице по почте. И ребенка справилась. Как? — удивился я. — У тебя наконец-то появился адрес? Щаз. Просто ВК умеет и с почтой работать, и показывает это как обычную беседу. Только у собеседника странное@имя и аватарки нет.

Чудны пути.

egorius: (Default)

Владимир Плунгян, «Почему языки такие разные»

Началось все с того, что каким-то образом я набрел на лекции известного лингвиста Андрея Анатольевича Зализняка на «Элементах». Скажем, об истории русского языка (там внизу есть ссылки и на другие его лекции). Оказалось на удивление интересно.

Например, выяснилось, что с начала истории русского языка (где-то X век) использовались и собственно русский — как разговорный и деловой, — и вместе с ним — в качестве литературного — церковнославянский (древноболгарский). Отсюда такие формы, как

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

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

  • на руце — на руке,
  • у сестре — у сестры,
  • в земле — в земли,
  • помоги — помози.
Постепенно эти диалекты слились; примерно половина вариантов осталась от одного, а половина — от другого. И только после этого произошло разделение общего языка на великорусский, белорусский и украинский.

Про двойственное число уж и молчу.

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

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

Frank Herbert, «Dune»

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

Теперь такое хорошо читать на английском — вроде как не ерундой занимаешься, а пользы для.

egorius: (Default)

Михай Чиксентмихайи, «Поток: психология оптимального переживания»

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

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

В целом, «Поток» — очень хорошая книга с правильными установками. Но.

Дело в том, что чем дальше я читал Михая, тем четче понимал, что его Поток и Качество Пирсига — по сути одно и то же. Скажем так: для меня Поток — это состояние, в котором рождается Качество.

Вот только один пример: Михай рассуждает о даосской концепции Ю:

Одним из наиболее интересных примеров того, каким образом великие мыслители прошлого трактовали явление потока, является концепция Ю, возникшая в трудах даосского философа Чжуан-цзы, жившего около 2300 лет назад. ... Чжуан-цзы считал, что Ю — это единственно правильный способ жизни: действовать спонтанно, не думая о внешней выгоде, полностью сливаясь с миром — то есть, пользуясь нашими терминами, постоянно пребывать в потоке.

...

Для достижения мистических высот Ю не требуется каких-то сверхчеловеческих качеств. Нужно просто научиться фокусировать свое внимание на возможностях для действия, предлагаемых окружением, что позволит совершенствовать навыки, которые со временем станут настолько автоматизированными, что будут производить впечатление спонтанных и сверхъестественных. ... Если моя интерпретация верна, то состояние потока, или Ю, — это та точка, где встречаются Восток и Запад: в обоих культурах экстаз имеет одно и то же происхождение.

Заглянем в Пирсига:

Потом Федр, сам не зная зачем, подошел к книжной полке и вытащил синюю книжицу в картонном переплете. Он сам переписал и переплел ее много лет назад, когда не смог найти в продаже. Ей было 2400 лет — «Дао дэ цзин» Лао Цзы. Федр вчитывался в строки, читанные уже множество раз, но сейчас изучал их, чтобы понять, сработает ли некая подстановка. Читал и интерпретировал прочитанное одновременно.

Он читал:

Качество, которое может быть выражено словами, не есть Абсолютное Качество.

И он то же самое говорил.

...

Он разгадал код.

Федр читал дальше. Строку за строкой. Страницу за страницей. Ни единого несоответствия. Он все время твердил о Качестве — здесь это было Дао, великая творящая сила всех религий, восточных и западных, прошлых и настоящих, всего знания, всего.

Занятно, что у Михая нет ссылки на «Дзен и искусство ухода за мотоциклом» Пирсига. Хотя это и логично, ведь тогда ему пришлось бы признать, что Поток невозможно определить, и его «N элементов и M правил», неизменно присутствующие в современных американских книгах, звучат фальшиво.

Тем не менее смело рекомендую книгу всем, кто не осилит Пирсига.

P. S. Не могу не процитировать (про созерцание):

Фотограф смотрит на небо и говорит: «Кодахромовое небо. Неплохо, Господи. Ты почти так же хорошо, как Кодак».

Roger Kaufman, «A Fortran Coloring Book» (1981)

Видимо, одна из первых книг о серьезных вещах «в комиксах». Доктор Кауфман от руки нарисовал почти три сотни страниц («The author personally dotted every i and crossed every t») и сумел нескучно и на пальцах рассказать о Фортране и вычислительных методах на уровне «переменные — это ящички в комоде вашей мамочки».

Редкий пример компьютерной книги, предмет которой (Фортран 66) безнадежно устарел, но сама она до сих пор интересна, уже как арт-объект.

egorius: (Default)

Бен Шнейдерман, «Психология программирования» (1984 год)

Такие книги интересны тем, что в них, как в термопаре, соединяются материалы с разными свойствами. Что еще меняется так быстро, как программирование, и так медленно, как люди? На страницах книги еще идет спор о том, надо ли писать GOTO и следует ли делать отступы в коде, а люди — люди все те же:

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

Хороший администратор [имеется в виду менеджер — язык меняется!] должен быть достаточно требовательным, чтобы обеспечить высокую интенсивность работы и деловую обстановку, но и достаточно располагать к себе, чтобы не расхолаживать работников и не быть им неприятным. Идеальный администратор должен быть технически компетентен, но более необходимым и редким качеством является административная проницательность. Хороший руководитель обеспечит соответствующий уровень требований, наладит хорошую обратную связь, отдаст должное хорошо сделанной работе и будет по необходимости строг к промахам сотрудников.

Руководство — это искусство, которым трудно овладеть. Хороший программист может и не быть хорошим руководителем. Программисты, которых предполагается выдвинуть на руководящие позиции, должны пройти соответствующую тренировку и находится под тщательным наблюдением.

Из забавного: в качестве эпиграфов есть цитаты и из Ершова, и из Пирсига. Тесен мир, узка прослойка.

В целом — книга для любителей-археологов; на полку рядом с Барри Боэмом.

Финн, «Здравствуйте, мистер Бог, это Анна»

Старшая ребенка взяла почитать в библиотеке, проглотила за день, «очень понравилось, но не все поймут».

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

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

egorius: (Default)

Г. М. Адельсон-Вельский, В. Л. Арлазаров, А. Р. Битман, М. В. Донской, «Машина играет в шахматы» (1983 г.)

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

Любопытно, что про альфа-бета-отсечение нам на ВМК рассказывали, но имя Александра Брудно при этом не упоминалось, хотя авторы утверждают, что это его изобретение (есть мнение, что к нему причастны многие). Ну или взять программирование в содержательных обозначениях того же Брудно: не помню, чтобы об этом хоть что-то говорилось, хотя идея сугубо практичная и полезная. Зато говорили про операторный метод Ляпунова, а кто применял его на практике? Говорили про историю вычислительной техники, но не затрагивали Бессонова с его релейной машиной. Такое ощущение, что разные школы и разные миры, и железный занавес между ними. А может, мне просто кажется.

Пара вырезок на память:

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

Здесь хотелось бы сделать лирическое отступление о том, что такое отлаженная программа. Принято считать, что она правильно реализует задуманный алгоритм. Однако в теории алгоритмов, наоборот, для определения, что такое алгоритм, используется понятие программы, и с такими определениями мы попадаем в порочный круг. Выход из него состоит в том, чтобы отказаться от понятия отлаженной программы, постулировав наличие в ней ошибок и определяя отладку программы, как процесс изучения ее поведения, поиска ошибок программиста или неверных представлений о том, что программа должна делать.

...

Наш опыт показывает, как часто поиск ошибок в программе приводит к признанию ее правоты: просто то, что на первый взгляд кажется ошибкой, при внимательном изучении оказывается необходимым следствием установок программистов, которые они собирались реализовать. Известным примером служит партия «Дачесс»—«Каисса»... «Каисса» сыграла..., отдавая ладью, после чего, естественно, проиграла партию. После часа исследования в поисках ошибки она сумела доказать, что была права, показав в ответ на другие ходы мат при помощи красивой комбинации...

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

Если не ошибаюсь, Кайт писал, что всевозможные средства трассировки Оракла съедают чуть не 10 % времени его работы. Но без них «последняя была бы невозможной».

Александр Марков, «Рождение сложности»

Берем картину мироздания, да! И тупо смотрим, что к чему. (вместо эпиграфа)

Книга про реалии современной биологии. Без знаний в органической химии и генетике читать сложно, но все равно безумно интересно. Все оказалась намного хитрее и забавнее, чем мне дилетантски представлялось. Вот и автор признается:

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

...

Это характерный «почерк» эволюции, совсем не похожий на разумное проектирование, а похожий скорее на самосборку чего получится из чего попало.

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

egorius: (Default)

А дядюшка, ракетчик-офицер,
Расскажет про язык военный Ada.
«От C к C++»

 

Из каких-то соображений Oracle хранит молчание про появление и развитие языка PL/SQL. Редкие источники, в которых можно найти что-то вразумительное про технологическую историю компании, обходят этот вопрос стороной. Особенно это огорчает на фоне неплохо документированной истории языка SQL.

Достоверно известно немногое. Язык впервые появился в версии 6 (1988 год); в версии 7 (1992 год) с реализацией хранимых процедур его поддержка стала полноценной:

Ken Jacobs: In Oracle 6, we dealt with stored procedures. The kernel, the engine, would execute a PL/SQL procedure, but it didn’t have the ability to store it. So, you would have client side programs that would create these packages of multiple statements with procedure logic around them and submit it to the database as an executable unit. And, so stored procedures came in version 7, but PL/SQL was in version 6.
RDBMS workshop: Oracle, p. 26

Прообразом для PL/SQL послужила Ада — «официальный» язык МО США. Почему? Возможно, таково было пожелание госзаказчиков, однако точной информации на этот счет нет. Сам факт родственных связей очевиден и из простого сравнения двух языков, и заявлен в PL/SQL Language Reference, Appendix C:

PL/SQL is based on the programming language Ada. As a result, PL/SQL uses a variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), a tree-structured intermediate language. It is defined using a metanotation called Interface Definition Language (IDL). DIANA is used internally by compilers and other tools.

Как видим, языки похоже не только внешне: транслятор PL/SQL переводит код в промежуточное представление DIANA — атрибутированное синтаксическое дерево, — которое было разработано в начале 1980-х для использования компиляторами Ады. Это наводит на мысль, что в основу реализации PL/SQL был положен уже готовый компилятор Ады.

 

Другой артефакт, позволяющий строить догадки, хорошо спрятан на самом видном месте — пакет standard. Кажется, первым на него обратил внимание Пит Финниган: он заметил, что булевский тип объявлен в standard как

type BOOLEAN is (FALSE, TRUE);

В PL/SQL такой конструкции нет, зато она есть в Аде. Пит сделал вывод о том, что Oracle реализовал перечислимые типы «невзаправду»:

Why do Oracle use syntax available to them only in the STANDARD package and not available to us? — well, my educated guess would be that they have only implemented this syntax in a very narrow way, i. e. to fulfill a  particular case and not much more. They must have made sure it compiles the BOOLEAN correctly but not tested or implemented much else hence we cannot use it.
Undocumented Oracle — Using ENUM's in PL/SQL

На мой взгляд, Пит ошибается. На самом деле это еще один аргумент в пользу того, что разработчики PL/SQL имели на руках готовый компилятор Ады: какой смысл в поддержке перечислимых типов ради одного только boolean? Хватило бы числового типа и немного хардкода.

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

type color is (red, green, blue);

В обычном пакете получим PLS-00505: User Defined Types may only be defined as PLSQL Tables or Records, а внутри standard это компилируется и потом прекрасно работает, включая (как и полагается в Аде) функции сравнения и вхождения:

SQL> set serveroutput on
SQL> declare
   2    c color;
   3  begin
   4    c := red;
   5    dbms_output.put_line(case when c < green then 'yes' else 'no' end);
   6    dbms_output.put_line(case when c in (blue,green) then 'yes' else 'no' end);
   7  end;
   8  /
yes
no

PL/SQL procedure successfully completed.

К слову, скомпилировать standard просто так не получится: полезут блокировки и внутренние ошибки, в результате чего база загнется чуть менее, чем насмерть. Для 9i (и, по слухам, 10g) можно поднять базу в режиме migrate (это отключает триггеры), скомпилировать пакет и перекомпилировать инвалидные объекты:

$ sqlplus / as sysdba
SQL> shutdown abort
SQL> startup migrate
SQL> @stdspec
SQL> @?/rdbms/admin/utlrp

Для 11g это уже не прокатило, как обходиться с ней — не знаю.

Итак, зачем Ораклу поддержка перечислимых типов? Напомню, что в версии 6 была переписана примерно половина СУБД:

Jacobs: Version 5 was pretty successful but it had some serious problems. It still had table-level locking. It had no real scalability. You didn’t need it with table locking. You couldn’t do much anyway. So we set out in about 1986 and made a fundamental decision to rewrite half of the product. We threw away, and literally deleted the directories for the lower half of the database. We kept the SQL layer but re-architected the process model, the storage format, the logging, the locking, the multi-threadedness.
RDBMS workshop: Oracle, p. 19

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

 

Ну хорошо, реализация перечислимых типов не выглядит очень сложной, могли и сделать. Однако заглянем внутрь standard чуть глубже:

type VARCHAR2 is NEW CHAR_BASE;

Что такое new? В PL/SQL такого нет, он будет ругаться PLS-00504: type CHAR_BASE may not be used outside of package STANDARD, а если заменить тип, скажем, на number, то PLS-00103: Encountered the symbol "NUMBER" when expecting one of the following...

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

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

Кстати, попытка объявить аналогичный тип varchar3 внутри standard не увенчалась успехом. Standard компилируется без проблем, но использовать новый тип невозможно:

SQL> declare
   2    v3 varchar3(100);
   3  begin
   4    null;
   5  end;
   6  /
   v3 varchar3(100);
      *
ERROR at line 2:
ORA-06550: line 2, column 6:
PLS-00566: type name "VARCHAR3" cannot be constrained

Если же не указывать ограничение, то код компилируется, но с грохотом падает при выполнении:

SQL> declare
   2    v3 varchar3;
   3  begin
   4    null;
   5  end;
   6  /
declare
*
ERROR at line 1:
ORA-06550: line 0, column 0:
PLS-00801: internal error [74402]

 

Самый убойный аргумент нашелся почти случайно в форуме. В 9i (а судя по написанному, и в 10g) без ошибок компилируется такой код:

SQL> create or replace package test as
  2    procedure set_n(x number);
  3  private
  4    n number;
  5  end;
  6  /

Package created.

Что такое private в спецификации? В Аде это слово позволяет описать данные, к которым нельзя обратиться непосредственно — это механизм для создания абстрактных типов. А вот в PL/SQL развесистую систему типов Ады существенно упростили и в нем слово private лишено всякого смысла.

Вообще система типов — тема для отдельного поста, но откуда private попал в PL/SQL, как не из компилятора Ады? Если бы язык писали с нуля, в него не стали бы добавлять абсолютно ненужную конструкцию.

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

SQL> create or replace package body test as
  2    procedure set_n(x number)
  3    is
  4    begin
  5      n := x;
  6    end;
  7  end;
  8  /

Package body created.

SQL> begin
  2    test.set_n(42);
  3  end;
  4  /
begin
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

Возможно, внутренняя ошибка возникает из-за конфликта старой и новой модели сокрытия данных, а из парсера private просто забыли убрать (в 11g это уже подчистили).

 

Итак, мое мнение состоит в том, что для PL/SQL изначально был взят код компилятора Ады. Часть возможностей вырубили топором, часть присыпали листвой (из-под которой, как мы видели, кое-что просвечивает), и уже на этом готовом фундаменте вырастили новый транслятор.

 

P. S. для пытливых умов. С Адой у Oracle также связаны такие продукты, как Ada*Precompiler (в седьмой версии) и SQL*Module (в восьмой). Оба они, по всей видимости, успешно загнулись, однако идея использовать Аду для доступа к данным не умирает.

egorius: (Default)

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

Возвращаясь к теме. Я-то думал, что Школьный Алгоритмический Язык им. А. П. Ершова давно предан забвению, ан нет! Ребенка пришла с просьбой установить некий «КуМир», по которому информатик дает задания. Так вот это тот самый ШАЯ и есть.

И выделывают с ним бедные школьники такие фигуры, как на картинке, ежесекундно переключая раскладку, чтобы набрать если б/2 = int(б/2) то.

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

кон

egorius: (Default)

Microsoft открыла исходные коды MS-DOS версий 1.1 и 2.0 и Word for Windows 1.1a.

MS-DOS, понятно, на ассемблере, там особо ничего не углядишь. Для меня интересно было почитать про Тима Патерсона, автора этой системы. Сразу вспомнилось, что у нас на Ямахах был MSX-DOS (такой гибрид MS-DOS и CP/M), и там при хитром нажатии на какие-то кнопки появлялось имя Патерсона. Тогда мы были не в курсе, кто это такой, а сейчас погуглил и пожалуйста: вот интервью с Тимом про историю создания MSX-DOS, в котором он вспоминает про свой easter egg, а вот видео, как это выглядело.

Word интереснее, он в основном на C. Можно живьем посмотреть на старорежимную венгерскую нотацию, воспетую Джоэлем Спольски. In Word, I’m told, you see a lot of xl and xw, — пишет Джоэль, и действительно, так оно и есть. Не обманул.

egorius: (Default)

Развлекался тут с Advanced Queueing и нашел чудесную окаменелость.

Dequeue Options

navigation
The navigation attribute specifies the position of the dequeued message. If FIRST_MESSAGE is specified, then the first available message matching the search criteria is dequeued. If NEXT_MESSAGE is specified, then the next available message matching the search criteria is dequeued (the default).

Проявляется это, например, если пытаться выбирать сообщения из очереди, прикидываясь разными подписчиками:

ORA-25242: cannot change subscriber name from SUBSCRIBER1 to SUBSCRIBER2 without FIRST_MESSAGE option
*Cause:    An attempt was made to change the subscriber name while using the
           NEXT_MESSAGE or NEXT_TRANSACTION option for dequeuing.
*Action:   To use a subscriber name that is different from the previous
           dequeue call, reset the dequeuing position by using the
           FIRST_MESSAGE navigation option.

Ведь что получается? В недрах реляционки сидит, особо не скрываясь, пережиток навигационных баз данных и заставляет нас думать в терминах FIND FIRST, FIND NEXT!

Будь я постарше, мог бы испытать примерно то же, что испытал однажды, сохраняя файл на КПК. А так просто в тихом шоке.

пощупать исходный код )
egorius: (Default)

Николай Бусленко, Владимир Бусленко, «Беседы о поколениях ЭВМ» (1977 год)

— Книга из другого Мира, кто бы мог подумать... Да, это гораздо лучше, чем все, что могло найтись в старой библиотеке!
— Не обязательно. — Я пожал плечами. — Вообще-то, я никогда ее не читал и автора этого не знаю, так что ничего не могу гарантировать.
— Знаешь, я думаю, что это неважно. Я еще никогда не читал книг, написанных в другом Мире, сам понимаешь, так что мне совершенно все равно, хорошая она или плохая. Просто потому, что это больше чем книга...

— Макс Фрай, «Тень Гугимагона»

Книга, тем не менее, оказалась интересной, внятно (хотя временами и чересчур эмоционально) написанной. Достаточно полно охвачена история развития ЭВМ, да и перспективы нарисованы вполне адекватные, без чрезмерных фантазий. Разве что веселят разговоры про систему общегосударственного планирования и управления — эдакий ERP на всю страну. Самое смешное, что препятствием к реализации такого проекта является вовсе не дефицит вычислительной мощности, как можно заключить из книги, а человеческий фактор и организационный хаос.

Ну и картинки тоже красивые.

Несколько цитат:

  • Да, программист весьма дефицитная специальность... Имеющиеся же программисты — люди исключительно капризные. Если ты внес мелкое изменение в задачу, они заявляют, что на исправление уйдут недели, что почти готовую программу придется переделывать, писать заново.
    Кроме того, они страшно медлительные. Посудите сами, опытные программисты способны «сделать» в среднем всего несколько команд за рабочий день. Если программа состоит, например, из 700 команд, а это, вообще говоря, программа не очень сложной задачи, то один программист будет ее разрабатывать три месяца! А что, если привлечь пятнадцать программистов? Можно ли запрограммировать эту задачу за неделю? Оказывается, нет.
  • В США разработчики ЭВМ даже придумали специальные юмористические термины. На своем профессиональном жаргоне они говорят «хард вэр» (так в нефтяной промышленности обозначают тяжелые продукты перегонки — мазут, битум и т. п.), и все понимают, что имеются в виду технические средства ЭВМ; «софт вэр» (так называют легкие нефтепродукты: бензин, керосин, солярка) — и ясно, что речь пойдет о математическом обеспечении.

egorius: (Default)

Владимир Кричевский, «Идеальный дизайн»

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

Джо Селко, «Стиль программирования на SQL»

C одной стороны, любой труд, призывающий мыслить на SQL в терминах множеств, а не циклов, и обращающий внимание на важность типографики в программировании — безусловное благо.

C другой — слишком во многом мы расходимся с автором, чтобы безоговорочно рекомендовать эту книгу. Например, мне совершенно не близка мотивация писать переносимый код; здесь я принимаю сторону Тома Кайта: если уж заплатили за СУБД, глупо не пользоваться всеми ее возможностями. Тем более, что наезды автора на Оракл выдают в нем человека, с Ораклом не работавшего (а наезжает он и на другие коммерческие системы тоже).

В общем, читать можно, но осторожно.

Карл Левитин, «Прощание с Алголом» (1989)

Вот академик Андрей Петрович Ершов. Как же, каюсь, не любил я в детстве эту фамилию! Во-первых, из-за школьного алгоритмического языка. Не понимал тогда, да и сейчас не понимаю, зачем переводить Паскаль на русский язык. Были и до этого попытки, вот скажем Эль-76, автокод Эльбруса, тоже базируется на русском, но то были другие времена и нам было еще чем гордиться. Во-вторых, из-за информатики, с 1985 года усилиями Ершова введенной в школьную программу. Не понимал тогда, да и сейчас не понимаю, зачем понадобилось это слово. Вот передо мной три учебника информатики 1988–91 годов. Один объявляет, что компьютерная грамотность — это умение читать и писать, считать и рисовать, а также искать информацию, применяя для этого ЭВМ, после чего обрушивает на бедного школьника материал, по широте охвата не уступающий программе ВМК, от p-n-переходов до программирования на Прологе. Другой не мудрствует: вот блок-схемы, вот расчет на калькуляторе, а вот — на Бейсике. Третий пытается быть авторитетным и школьник узнает из него, что кэш-память — это разновидность стека, а Паскаль — Philips Automatic Sequence CALculator. Хаос, полный хаос царит в голове горе-информатиков. Они понимают, что уметь программировать нужно не всем, но что такое компьютерная грамотность без программирования — не понимают. А что понимают современные учителя информатики, это мне страшно даже представить.

Вот конференция «Диалог человек — ЭВМ», которая проводилась в 1983 году у нас в Протвино. А ведь у меня на полочке стоит сборник материалов, папа принес в свое время из Института. Кого только не было на этой конференции, не считая «компьютерщиков»: дизайнеры, социологи, биологи, психологи... Тихомиров из Универа: Существенным является разделение потребностей пользователя на предусмотренные разработчиком и непредусмотренные... Ко второму классу относятся многие разновидности потребностей в общении: потребность в соревновании с другими пользователями..., потребность в уважении коллег..., потребность быть членом социальной общности. Нынешние веб-разработки эксплуатируют это наблюдение по полной. Но ведь в целом концепция диалога с ЭВМ как обмена сообщениями на естественном языке полностью провалилась. Ершов предполагал, что удастся осилить хотя бы деловую переписку, канцелярит, но и это не удалось. Вместо этого диалог превратился в клацанье мышью — интересно, в Xerox PARC психологи тоже работали? Приведу еще цитату из книги Льва Николаевича Королева: Стремление упростить взаимоотношения пользователя с PC привело к созданию ... оболочки, в которой текстовое меню в основном заменено графическими символами... Вообще, наблюдающийся переход от текстов к иероглифам весьма симптоматичен и интересен с философской точки зрения.

Вот всплывают разные знакомые имена. В 1979 году в Узбекистане, на родине Аль-Хорезми, проводился симпозиум «Алгоритм в современной математике и ее приложениях». Инициатива принадлежит Ершову и... Дональду Кнуту — оказывается, они были знакомы. А на заре вычислительной техники к компьютерам Ершова привел Евгений Андреевич Жоголев — он вел у на курс технологий программирования. Или промелькнул Виктор Брябрин — а на полочке стоит его «Программное обеспечение персональных ЭВМ».

Казалось бы, небольшая старая книга, а какой пласт воспоминаний!

Из Ершова:

  • У меня есть одно существенное свойство — доводить дело до конца и стараться его исчерпать.
  • У меня обязательно бывает такой период времени, когда видимой цели работы нет. Мысли начинают растекаться... именно в это время рождаются непредвзятые идеи.
  • Сегодня оценка степени достоверности программы — личное дело каждого программиста. А нынешние правила приемки результатов их труда, при всей их кажущейся строгости, носят поверхностный характер, не затрагивающий существа самого программного продукта, да при этом еще постоянно выхолащиваются формальными требованиями соблюдения плановых сроков... — знакомо, да? Это 1983 год.
  • — Какова главная опасность нашего труда?
    — Потеря интереса к своему делу, ибо профессию программиста менять не на что.
  • Настоящий, врожденный, истинный программист — это тот, кто не сможет успокоиться, пока дело рук его не примет вполне завершенный вид. Контраст между почти сделанной и полностью сделанной работой для него непереносим чисто физически. Эта стопроцентная закономерность — источник трудности и в то же время глубочайшего удовлетворения...
  • Мне посчастливилось в жизни встретить нескольких программистов, обладающих поистине исключительным набором качеств. Это люди, как правило, резко выраженной индивидуальности и даже экстравагантности, но они вносили огромный вклад в общее дело, особенно в трудных ситуациях. Поэтому когда я слышу нередко раздающиеся призывы, что надо кончать с «примадоннами» в программировании, то никогда не поддерживаю эту ошибочную, на мой взгляд, точку зрения.
  • ...стоит ему [программисту] всерьез задуматься о философии своей профессии, как он сразу же начинает чувствовать себя мамонтом, которому грозит неизбежное, хотя, быть может, и не немедленное вымирание.

Photoshop

Mar. 9th, 2013 02:06 am
egorius: (Default)

Computer History Museum опубликовал исходные коды первой версии Фотошопа, сообщает нам DPReview.

Сотня тысяч строк кода на Паскале (!) и двадцать тысяч — на ассемблере. По первому впечатлению написано аккуратно, интересно было бы полистать на досуге.

egorius: (Default)

Не в силах вынести искажения исторической действительности, задал Кайту вопрос:

Tom,
you said that the first Oracle version was written in Fortran.
In “The 1995 SQL Reunion” paper I found the following words of Roger Bamford: Version 2 had been written in assembly language for PDP-11.
I'm sure you have access to information about early days of Oracle. Could you please clarify this point?

Через пару дней пришел ответ:

I went back and checked some notes....
....While much of the system was written in PDP-11 assembler language, parts were developed in the emerging new language C....
so, I’ve updated my slide—it was pdp-11 assember and C and was from there ported to VAX.
thanks for the followup on that detail!

Я считаю, это большой успех отечественной археологии.

egorius: (Default)

В минувший вторник в Москву приезжал Том Кайт, и как-то почти случайно вышло, что вслед за [livejournal.com profile] hardsign и я попал на этот семинар. Кайт рассказывал про новые фичи грядущего 12c (а их немало и среди них есть занятные), ну и кое-то из интересного про Оракл вообще. Не то, чтобы какие-то уникальные знания — про многое я читал или слышал раньше — но всегда приятно послушать действительно умного человека, тем более «в подлиннике». Теперь-то я знаю, як вони наш варчар вимовляють: вэркэр.

На вопрос из зала «В чем вы видите основную проблему баз данных» Кайт подумал и сказал: «Вы знаете, основная проблема не в технологиях, а в людях...». Порадовало.

Единственное, в чем Том заблуждается, так это в том, что первая версия Оракла была написана на Фортране. На ассемблере она была написана, это я вам как археолог заявляю.

egorius: (Default)

Robert Glass, «In the Beginning: Recollections of Software Pioneers»

Воспоминания людей, стоявших у истоков вычислительной техники, собранные Робертом Глассом. Книга получилась очень интересная, позволяет заглянуть в эпоху пионеров программирования (примерно 1955-65 года) под совершенно разными углами глазами совершенно разных людей.

Как обычно, выясняется, что все новое — хорошо забытое старое.

I remember one man who held a master’s degree in aeronautical engineering; he had written his masters thesis on wing tip design. ... Since aircraft were on the wane (at that time) and missiles on the rise, no one needed better wing tips designed. He sought technical employment in the computer field. Since no computer classes were available, he was as well prepared as anyone. As to accounting, he would often muse, «Some day I just have to take some accounting classes.»

Вот еще кусочек. Пишет человек, рассказывавший всем, как использование инвариантов позволяет писать безошибочные программы:

At our first meeting, the director of this company and I discussed the seminar, its contents, and its relationship with and possible implications for the company’s business. He pointed out that although reducing the error rate in their software output was in principle of interest, their goal was not to reduce it to zero. The presence of a few residual errors ensured the opportunity to remain in contact with the customer and, in addition to correcting the errors, to add desirable new features to the programs and to develop new software, that is, to sell follow-on business.

А. Г. Абинов, «Человек или машина?» (1989 г.)

Я размышлял. Тощие брошюрки общества «Знание» приучили меня к мысли, что разговаривать животные не способны. Сказки с детства убеждали в обратном.
— А. и Б. Стругацкие, «Понедельник начинается в субботу»

Попалась в руки одна из тех самых брошюрок общества «Знание». Действительно тощая и такая, научно-популярненькая. Местами забавная:

Вместе с компьютерными «вирусами» в настоящее время получили распространение и некоторые виды программ-разрушителей. Условно их можно подразделить на три основные категории: «троянские кони» — т. е. такие, которые под видом доброкачественных программ на самом деле разрушают заложенную в ЭВМ информацию; «черви» — программы, которые медленно, но верно подтачивают память ЭВМ, вызывая в один не очень прекрасный день полную парализацию компьютера, и наконец, «бомбы замедленного действия» — программы, ждущие своего часа, чтобы стереть записанные на диске данные.

Страшно жить. Зато картинки тоже хорошие.

Александр Брудно, «Программирование в содержательных обозначениях» (1968 г.)

Рассказывает о методе программирования, придуманном и применявшемся с середины 50-х в Институте электронных управляющих машин и Институте теоретической физики (это такие люди, как Брудно, Кронрод, Адельсон-Вельский, Арлазаров и другие; они, помимо прочего, причастны к созданию знаменитой шахматной программы Каисса).

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

egorius: (Default)

Начало: 1. Необходимая предыстория, назад: История SQL. 9. System R, Phase Two.

На протяжении всей серии я вольно обращался с темой «история SQL», то и дело отвлекаясь на соседние, интересные мне темы. Отвлекусь и сейчас, потому что история Оракла занятно переплетается с историей System R.

Вообще техническую информацию о ранних годах Оракла найти неизмеримо сложнее. Это не удивительно, ведь System R была исследовательским проектом и до 1979 года никаких ограничений на публикацию статей не имелось, а Оракл — изначально фирма коммерческая и закрытая. Что-то знают все, какие-то сведения менее известны, а некоторые еще ждут своего археолога. Пойдем, однако, по порядку.

В 1977 году Ларри Эллисон, имевший опыт работы над навигационной базой данных (для ЦРУ, проект назывался ORACL), прочитал статью Кодда и проникся реляционной идеей. Он основал компанию Software Development Laboratories вместе с Эдом Оатсом и Бобом Майнером, а вскоре к ним еще присоединился Брюс Скотт. Прочитав статьи про System R и язык Sequel (вспомним, что в статьях было все, вплоть до БНФ-синтаксиса), коллеги решили, что смогут достаточно быстро сделать свою реализацию реляционной СУБД. Ларри хотел сделать это раньше, чем IBM выпустит свою коммерческую реализацию, но при этом быть совместимым. Вспоминает Дон Чемберлин:

Он узнал о System R и хотел, чтобы его продукт был полностью совместим, вплоть до кодов ошибок. Мы спросили Франка [Кинга]: «Можем ли мы дать коды ошибок этому Эллисону?», но он сказал: «Нет, это конфиденциальная информация».

Тут я нарушу ход истории своим изысканием. Задумывались ли вы когда-нибудь, почему в Оракле исключение no_data_found имеет код +100, в то время, как остальным исключениям присвоен отрицательный номер? Фейерштейн пишет, что это, дескать, ANSI standard error number, но первый стандарт появился только в 1986 году! А теперь посмотрим внимательно на упоминавшийся ранее отчет «Support for Repetitive Transactions and Ad-hoc Query in System R» 1979 года. В нем промелькнул следующий фрагмент кода:

$SELECT DESCRIP,QOH,QOO INTO $DESCRIP,$QOH,$QOO
     FROM PARTS WHERE PARTNO=$PARTNO;
IF SYR_CODE = 0 THEN
     Write DESCRIP, QOH, QOO on terminal;
ELSE IF SYR_CODE = 100 THEN
     Write 'THERE IS NO SUCH PART' on terminal;
ELSE CALL TROUBLE('SELECT');

Полагаю, что дело было так. Ларри, очевидно, читал все материалы по System R и видел этот фрагмент. Пусть ему не удалось получить все коды System R, но +100 ему ничего не могло помешать использовать. А уже потом стандарт «узаконил» получившуюся странность. В одном документе есть фрагмент диалога о трудностях стандартизации между Доном Чемберлином от IBM и Кеном Якобсом от Оракл (оба входили в комитет ANSI):

Чемберлин: — У нас также были проблемы с кодами ошибок.
Якобс: — Стало быть, они были не только у Оракла?

Кстати, вот такое определение кодам ошибок дается в ANSI SQL-1992 (на Аде):

type SQLCODE-TYPE is range bsc .. tsc;
subtype SQL_ERROR is SQLCODE-TYPE range SQL-TYPE'FIRST .. -1;
subtype NOT_FOUND is SQLCODE-TYPE range 100 .. 100;

В тему будет привести слова Роджера Бэмфорда, участнику команды System R, перешедшему затем в Оракл:

Насчет влияния System R на Оракл: некоторые идеи пришли из Esvel, некоторые из System R. Но исходный код выглядел так, словно они прочитали статью, описывавшую язык, сели за компьютер и начали программировать. И было понятно, как писали код: все структуры данных напрямую отображали язык в аппаратуру безо всяких промежуточных слоев. «Так, вот у нас блок запроса, вот у него часть select, а вот то-то и то-то».

Однако возвратимся к повествованию. Спустя два года, в 1979-м, фирма изменила название на Relational Software, Inc и выпустила первый релиз системы. Он получил название Oracle version 2, поскольку Ларри полагал, что первую версию никто не купит. Система была написана на ассемблере DEC PDP-11 и занимала порядка 100 КБ оперативной памяти (из 128).

В 1982 году компания переименовалась в Oracle Systems Corporation, и с тех пор, несмотря на последующие изменения названия, слово Oracle уже не покидало ее имя.

Третья версия появилась в 1983 году. Чтобы облегчить портирование СУБД на другую аппаратуру, весь код был переписан на C, тогда еще не слишком популярном языке. Выбор оказался правильным и с тех пор доступность базы на разных платформах стала одним из коньков Оракла. Версия 3 была написана преимущественно Брюсом Скоттом. Правда, он ушел из Оракла до выпуска релиза, так что часть работы доделывал Боб Майнер. Слово Роджеру Бэмфорду:

Когда я пришел, они были на третьей версии, практически завершенной парнем по имени Брюс Скотт... Он переписал ее и создал действительно красивый, компактный и хорошо структурированный код; многое из этого кода сохранилось и сейчас.

Кстати, Роджер — не единственный из System R, кого Ларри звал в свою команду (Дон Слац не принял предложения, а Франко Путцолу присоединился позже).

Система во времена версии 3 была нестабильной. Снова Роджер:

В то время использовать Оракл можно было единственным образом: каждый день экспортировать все данные, ждать, пока база накроется, и загружать данные обратно. И все были довольны. То есть, конечно заказчики были не в восторге, но не придавали этому большого значения, потому что СУБД не использовалась как транзакционная система.

Примерно тогда же был написан командный интерпретатор, который не долго думая назвали так же, как в System R: UFI — User Friendly Interface. Позже его переименовали в SQL*Plus.

Уйдя из Оракла, Брюс довольно оригинально увековечил память о себе: все знают аккаунт scott/tiger (правда, не все догадываются, что это тот самый Брюс Скотт).

В 1984 году была выпущена четвертая версия, интересная прежде всего появлением согласованных чтений.

Пятую пропустим (заметив в скобках, что в 1987 году в Оракле началась работа над Applications, ныне OEBS), зато остановимся на шестой, увидевшей свет в 1988 году. Ее ведущим архитектором был Роджер Бэмфорд и в этом релизе была переписана часть, отвечавшая за доступ к данным, а это грубо говоря половина всей системы. Был полностью изменен низкоуровневый формат данных и механизм согласованный чтений, появились журнализация, восстановление, блокировки уровня строк:

Строки в версиях 3, 4, 5 были просто конкатенированы в блоках, байт за байтом, безо всяких индексов или указателей. Если вам надо было попасть на строку 12, вы начинали с начала блока и сканировали столбцы, строки... и да, со временем попадали именно туда, куда вам было нужно. А как изменять строку, если значение в столбце увеличивается? Ну, вы брали и сдвигали остаток блока вправо. Поэтому в версии 6 мы все это поменяли. ... С тех пор оно и работает без кардинальных изменений.

До этого Оракл обеспечивал согласованные чтения без механизма мультиверсионности, сохраняя при изменениях образ всего блока (past image). Интересно, что похожая техника используется сейчас для Flashback Database.

Еще версия 6 интересна тем, что в ней впервые появился процедурный язык поверх SQL. PL/SQL основан на синтаксисе языка Ада. Ада была современным языком на пике популярности и к тому же поддерживалась на государственном уровне, так что в целом выбор выглядит логичным, вот только мне не удалось найти никакой достоверной информации о том, как принималось это решение. По-видимому, для PL/SQL был разработан свой собственный компилятор, хотя и в строгом соответствии с имевшимися опубликованными наработками (так же, как было и с SQL). К этому заключению приводят две мысли. Во-первых, многие идеи, заложенные в Аду, в PL/SQL не попали, хотя специально выбрасывать их поддержку было бы странно (особенно это коснулось типизации данных). Во-вторых, от Ады все-таки был унаследован не только синтаксис, но и внутреннее устройство компилятора. Вот что сообщает нам PL/SQL User’s Guide and Reference:

PL/SQL is based on the programming language Ada. As a result, PL/SQL uses a variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), a tree-structured intermediate language. It is defined using a meta-notation called Interface Definition Language (IDL). DIANA is used internally by compilers and other tools.
At compile time, PL/SQL source code is translated into machine-readable m-code. Both the DIANA and m-code for a procedure or package are stored in the database. At run time, they are loaded into the shared memory pool. The DIANA is used to compile dependent procedures; the m-code is simply executed.

То есть, код PL/SQL компилируется в то же внутреннее представление, что и Ада (DIANA), а затем в m-код, исполняемый PL/SQL-машиной. DIANA представляет собой атрибутированное дерево разбора и записывается в виде IDL (в базе это представление можно увидеть в таблицах sys.idl_%$).

Ну что ж, на этом археология уступает место новейшей истории, а мой рассказ заканчиваются.

Почитать и посмотреть:

egorius: (Default)

Начало: 1. Необходимая предыстория, назад: История SQL. 8. System R, Phase One (RDS).

Несмотря на то, что System R была исследовательским проектом, она использовалась и в реальной работе. Этот период эксплуатации системы — Фаза 2 — продолжался с 1978 по примерно 1979 год.

Первая установка системы произошла в Pratt & Whitney Aircraft. Для производства реактивных двигателей компании требовалась система учета деталей и поставок. Затем систему установили в Upjoin Pharmaceuticals для хранения результатов клинических испытаний медикаментов. Несколько позже система стала применяться в Boeing Aircraft. Кроме внешних заказчиков, System R весьма активно использовалась и внутри IBM для самых разных нужд.

По воспоминаниям участников, основная польза таких внедрений была не столько в отзывах пользователей (к завершению проекта накопилось 160 пожеланий, практически ни одно из которых не было реализовано), сколько в демонстрации IBM важности исследований в области реляционных баз данных. Здесь необходимо кое-что пояснить. Деятельность в IBM разделялась на промышленную (приносящую прибыль) и исследовательскую. Исследовательским проектам всегда было тяжело обратить на себя внимание и пробиться в промышленное производство. В то время, о котором мы говорим, флагманским продуктом IBM была иерархическая СУБД IMS, а основные силы разработки были брошены на очередной грандиозный проект, который должен был стать преемником IMS (имена его часто менялись: сначала VSS, потом DS/1, затем Eagle и, наконец, Ampersand). Попытки System R обратить на себя внимание привели лишь к тому, что поддержку реляционных баз данных добавили в спецификацию новой системы.

Помимо трудностей выхода на рынок, исследовательским проектам часто приходилось конкурировать и друг с другом. В этой связи интересно вспомнить эпизод, известный как «перестрелка в O.K. Corral». Одновременно с System R в IBM была другая команда, которая под руководством Мойше Злуфа также занималась реляционными базами. Они разработали визуальный язык запросов Query-by-Example, в котором пользователь показывал пример того, что он хочет получить, а система производила выборку данных по аналогии (те, кто знаком с Oracle Forms, имеют об этом некоторое представление, хотя QBE был существенно богаче). Периодически возникал вопрос, зачем нужны две группы, и в итоге было решено провести сравнение двух систем на производительность. На одной машине установили и System R, и QBE, затем одновременно запустили один и тот же запрос. Через некоторое время System R выдала результат, а QBE упала с ошибкой; это и решило исход перестрелки. А на дверь терминального зала повесили табличку «The O.K. Corral» в честь популярного в то время вестерна. Конечно, состязание было не вполне честным: System R изначально проектировалась для производительной многопользовательской работы, в то время как QBE был силен не этим, а своим графическим интерфейсом. Кроме того, на QBE было легко написать простой запрос, но сформулировать сложный запрос было практически невозможно.

Однако реляционная база данных была востребована заказчиками IBM. Причем многие были не готовы покупать самое передовое (и дорогое) оборудование, и были не готовы ждать появления новой реинкарнации IMS. Их вполне устроила бы «небольшая» реляционная СУБД, работающая на мейнфремах средней ценовой категории. Дальше события развивались так. В подразделении IBM в Эндикотте образовалась свободная группа разработчиков, которая не была знакома с базами данных, но — надо же чем-то заниматься — взялась реализовать СУБД. После некоторых колебаний было решено не начинать с нуля, а взять код System R и довести его до промышленного уровня. Вот, например, что вспоминает Брюс Линдсей: Они переписали RDS на PL/S и переименовали модули в соответствии со своими правилами... Помнится, я работал над кодом авторизации на PL/1 и PL/S. C PL/S приходилось тяжеловато, потому что они использовали мнемонические имена — как минимум три символа на мнемонику — и решили, что подходящими будут 01, 02, 03, 04. Хоть они и не добрались до 10, но... В те времена правила именования в IBM были те еще.

Сделаю небольшое отступление о PL/1. В шестидесятых годах число доступных языков программирования уже подбиралось к сотне, причем обычно они были приспособлены для решения задач в какой-то конкретной области. Многим тогда верилось в то, что можно придумать всеобъемлющий универсальный язык, на котором будет удобно решать любые задачи. И вот в 1964 году — угадайте где? конечно же, в IBM! — был придуман и стал активно продвигаться язык PL/1, сплав Фортрана, Кобола и Алгола. Он включал в себя препроцессор, обработчики исключений (например, перед чтением из файла можно сказать ON ENDFILE GO TO ...), множество умолчаний. Неудивительно, что PL/1 получился не только громоздким, но и сложным для понимания, так что со временем универсальный по задумке язык распался на отдельные предметно-ориентированные подмножества. PL/S как раз одно из них, предназначенное для системного программирования.

В программном отношении, при всех ее богатых возможностях, System R не была большой. Компонент RSS был написан на PL/1 и имел размер порядка 35000 строк; RDS состоял из 38000 строк кода на PL/1 и 9000 строк ассемблера. Замечу, что и команда разработчиков состояла в среднем всего из 15 человек, а о качестве их работы говорит хотя бы то, что за все время в системе была обнаружена только 251 ошибка. System R могла работать на IBM System/370 Model 145 с одним мегабайтом оперативной памяти (одна из средних моделей линейки 370).

Итак, компоненты RSS и RDS были взяты командой в Эндикотте практически без функциональных изменений. Получившийся продукт получил имя SQL/DS и был выпущен IBM в 1981 году. Он работал на операционных системах DOS/VSE и VM/CMS и обеспечивал поддержку базы данных размером примерно до гигабайта.

А что же преемник IMS? Как и практически все грандиозные начинания, его ждала неудача. Слово Джону Науману, одному из менеджеров проекта: Мы работали в Санта-Терезе примерно год и регулярно собирались для обсуждения спецификации. На самом деле мы работали над ней еще в Пало-Альто, так что прошло даже больше года. И собрания обычно проходили в обсуждении висячих строк. Вот была тема для разговоров: «На этой странице осталась висячая строка, надо бы поправить». Тут я и подумал, что так дело не пойдет, что проект обречен.

Стоит заметить, что в 1978 году System R заинтересовался Ларри Эллисон, благо все исследовательские материалы свободно публиковались и были доступны, а в следующем году уже был выпущен Оракл — первая коммерческая реализация реляционной СУБД. Майкл Блазген увидел Оракл на какой-то конференции и Ларри устроил для него небольшую демонстрацию: Оно работало быстро. Он загрузил базу данных, выполнил запрос, затем обновление, все за несколько секунд. Там было строк пятьсот, и база загружалась мгновенно... Больше всего меня поразило, что это работало на маленькой PDP-11 размером с картонную коробку. System R в то время работала на IBM 168. Сейчас-то 486DX2 сравнится с ней по мощности, а тогда это была огромная машина, занимавшая большую комнату... И я подумал: «Просто, быстро, дешево. Люди будут это покупать».

Такой интерес к реляционным технологиям подтолкнул IBM к действиям. Было принято решение выбросить все иерархическое наследие и заняться исключительно реляционной базой данных, но крупного масштаба, в отличие от среднеуровневой SQL/DS. На этот раз код был переписан с нуля, но вдохновение разработчики из Санта-Терезы черпали снова в System R. Если бы мы не имели код System R, я думаю, мы бы не выпустили DB2 Release 1 — вспоминает Жозефина Ченг. Первые заказчики увидели DB2 в 1982 году, а официальный релиз был объявлен в 1983. SQL/DS некоторое время существовал параллельно с DB2, а в 90-х годах был переименован в DB2 для платформ VSE и VM.

Таким образом, только код System R превратился в один продукт и оказал огромное влияние на другой, а уж на сколько СУБД оказали влияние идеи System R, наверное, никто не скажет.

Продолжение следует: 10. Oracle.

Почитать и посмотреть:

egorius: (Default)

Уильям Росс Эшби, «Введение в кибернетику»

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

Кстати, 1956 год. Теперь таких не делают.

egorius: (Default)

Начало: 1. Необходимая предыстория, назад: История SQL. 7. System R, Phase One (RSS).

Теперь поговорим о том, что происходило в Фазе 1 с высокоуровневой компонентой System R — Relational Data System.

SEQUEL продолжал развиваться под руководством Дона Чемберлина. Правда, в какой-то момент (1977 или 78 год) имя пришлось изменить, поскольку оно оказалось уже кем-то зарегистрированным. Недолго думая, из имени выбросили гласные; так и получился SQL. Но и сейчас это имя частенько произносят по-старому — «сиквел», — отдавая дань уважения System R.

Среди прочих изменений обрела свой современный вид фраза GROUP BY HAVING, появился привычный синтаксис табличных алиасов, была введена (нереляционная, но полезная) конструкция ORDER BY.

В язык были введены представления (view). С точки зрения реляционной теории все отношения равноправны вне зависимости от того, хранятся ли данные физически или отношение определяется выражением над другими отношениями. Представления являются попыткой приблизиться к этому идеалу, хотя на практике возникают трудности с изменением данных. Разработчикам это было понятно и в System R представления делились на обновляемые и необновляемые. С другой стороны, представления оказались удобным механизмом разграничения доступа. System R позволяла выдавать пользователям права (grant) на различные объекты, в том числе и на представления. Таким образом, вместо доступа к базовой таблице можно было разрешить пользователю обращаться только к ограничивающему представлению.

В Оракле все перечисленное сохранилось в первозданном виде.

Ограничения целостности в System R были представлены весьма широко, и коммерческие системы далеко не сразу смогли предоставить аналогичные возможности. Во-первых, были реализованы утверждения (assert). Таблицы можно было снабжать произвольными предикатами SQL; нарушение истинности предиката считалось нарушением целостности. Предикаты проверялись в конце каждой транзакции либо по специальной команде ENFORSE INTERGITY.

ASSERT ON UPDATE TO EMP:
  NEW SAL >= OLD SAL

Аналогом Оракла с некоторой натяжкой можно считать ограничение check (обратите внимание на слова old и new).

Во-вторых, имелся более общий и мощный механизм триггеров, перенятый Ораклом (в версии 7 в 1992 году) с небольшими синтаксическими изменениями. Вот пример:

DEFINE TRIGGER EMPINS
  ON INSERTION OF EMP:
    (UPDATE DEPT
     SET    NEMPS = NEMPS + 1
     WHERE  DNO = NEW EMP.DNO)

Интересно посмотреть на программный интерфейс курсоров, предоставляемый RSS, с точки зрения вызывающей стороны. Вот как могла бы выглядеть программа на PL/I, обращающаяся к БД:

CALL BIND('X',ADDR(X));
CALL BIND('Y',ADDR(Y));
CALL SEQUEL(C, 'SELECT NAME:X FROM EMP WHERE JOB=Y');
CALL FETCH(C);
CALL CLOSE(C);

Имелась также команда DESCRIBE, позволяющая получить описание возвращаемых полей. Есть ли сомнения, откуда растут ноги у Oracle Call Interface?

Однако использовать в программе команды RSS не слишком удобно, поэтому несколько позже был сделан препроцессор, заменявший более высокоуровневые команды на соответствующие низкоуровневые вызовы. Команды предварялись знаком доллара — этот символ выбрали, поскольку он не мог встречаться первым в командах PL/I и COBOL:

$LET C BE
  SELECT NAME INTO $X
  FROM EMP
  WHERE JOB = $Y;
$OPEN C;
$FETCH C;
$CLOSE C;

Кстати, в Оракл перекочевал и специальный предикат CURRENT TUPLE OF для ссылки на текущую позицию открытого курсора (только слово tuple подверглось чистке — наверное, как слишком академическое).

Выполнение запросов. Для каждой команды SQL выполнялся разбор (синтаксический и семантический — проверка используемых таблиц). Затем выполнялась оптимизация: выбирался порядок соединения, пути доступа и способы соединения так, чтобы минимизировать стоимость выполнения. Результатом работы оптимизатора являлся план выполнения на специальном «деревянном» языке Access Definition Language. План передавался генератору кода, который транслировал дерево плана в исполняемый (!) код с обращениями к RSS.

Идея компиляции принадлежит Раймонду Лори, который убедил команду, что такой подход позволит ускорить выполнение запросов. Пришлось переписать часть уже готового кода, но ведь одной из задач проекта было показать, что реляционная СУБД может сравниться в скорости с «традиционной». Для генерации использовался сравнительно небольшой (около 100 элементов) набор шаблонов в машинном коде IBM 370.

Общий принцип состоял в том, что подготовительная работа должна выполняться как можно раньше. Например, для конструкции LET CURSOR BE разбор, оптимизация и генерация кода производились еще на этапе компиляции. Сгенерированный модуль доступа сохранялся в базе данных и в дальнейшем использовался для выполнения запроса. При этом RDS автоматически отслеживала зависимости и инвалидировала подготовленный код при изменении структуры таблиц или путей доступа. В этом случае при обращении к запросу оптимизация производилась заново уже во время выполнения программы (прозрачно для приложения). Если же запрос не мог быть обработан заранее (например, во время компиляции могла отсутствовать таблица или сам запрос мог формироваться динамически с помощью команд PREPARE и EXECUTE), то разбор, оптимизация и генерация кода изначально откладывались на время выполнения.

Как видим, общая схема разбора запроса, включая механизм library cache, полностью унаследована Ораклом. Конечно, со временем в ней произошли изменения, но в целом процесс устроен точно так же. Мне даже кажется, что этап «Code Generation» System R проливает свет на происхождение туманного «Row Source Generation» Оракла (интересно, во что сейчас компилируют план?).

Оптимизатор — безусловно, наиболее интересный компонент RDS, поскольку в System R была придумана и реализована стоимостная оптимизация.

В прототипе Фазы 0 стоимость измерялась в обращениях к строкам данных. Но XRM не хранил кортежи как единый фрагмент данных; вместо этого отдельно хранились значения атрибутов и отдельно — объединяющие их ссылки. За счет этого экономилось место (можно было ставить ссылки на один раз записанное значение), но для считывания всего кортежа могло потребоваться много обращений к диску.

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

Оптимизатор имел дело с тремя составляющими пространства перебора:

  • Способ доступа к данным — либо полное сканирование сегмента, либо доступ по индексу.
  • Способ соединения таблиц — либо метод nested loops (так он и назывался), либо merging scans (аналог в Оракле — sort merge join). Хэш-соединение не было реализовано: при упоре на индексный доступ оно не давало особых преимуществ перед сортировкой-слиянием, которое эффективно использовало отсортированность данных, полученных по индексу.
  • Порядок соединения таблиц — уменьшение числа вариантов для перебора достигалось за счет эвристики, исключающей из рассмотрения декартово произведение, пока есть другие варианты.

Для каждого рассматриваемого оптимизатором плана по определенным формулам на основе статистики вычислялась стоимость; в итоге выбирался наименее затратный план. Для таблиц статистика была представлена общим числом строк (кардинальностью), числом страниц в сегменте и долей страниц сегмента, содержащих строки этой таблицы (для оценки полного сканирования), а также максимальным и минимальным значением каждого столбца. Для индексов статистика включала число уникальных ключей, занимаемое индексом число страниц и признак кластеризованности. Статистика собиралась при создании объекта, а затем время от времени обновлялась специальной командой UPDATE STATISTICS.

Формулы были основаны на тех же предположениях, что и сейчас в Оракле: на равномерности распределения данных (гистограмм в System R не было) и на некоррелированности предикатов. Сами формулы, конечно, отличаются, отражая разное внутреннее представление данных и упор System R на индексный доступ — пытливый ум может сам сравнить книгу Льюиса и статью Гриффитс. Тем не менее общность подхода налицо.

В System R в стоимости запроса дополнительно были учтены и затраты времени на вычисления. Они измерялись в количестве необходимых низкоуровневых вызовов RSS и пересчитывались в эквивалентное количество чтений страниц данных с помощью настраиваемого коэффициента.

И вновь обращу внимание на то, что современный Оракл пошел по тому же пути. Идеи System R заимствованы вплоть до того, что стоимость запроса в Оракле также выражается в количестве одноблочных чтений и процессорное время пересчитывается в эти единицы. Удивительно только, что в стоимостной оптимизатор в этой системе появился лишь в версии 7 в 1992 году, а учет времени — в версии 9i в 2001 году. А ведь все это работало в System R еще в конце 70-х.

Пришла пора сделать какие-то выводы из проведенного сравнения. Лично меня поражает то, как более 30 лет назад в ходе исследовательского проекта, когда ни у кого еще не было понимания, как надо строить реляционные СУБД, были нащупаны пути и решения, которые продолжают отлично работать в современных системах. Все, чем богат Оракл, так или иначе опирается на идеи System R. Единственное радикальное изменение заключается в механизме мультиверсионности; все остальное не заменило решения System R, а эволюционно улучшило их.

Продолжение следует: 9. System R, Phase Two.

Почитать и посмотреть )

Profile

egorius: (Default)
egorius

September 2017

M T W T F S S
     123
45678 910
1112131415 1617
18 19 2021222324
252627282930 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 09:17 am
Powered by Dreamwidth Studios