MS-DOS и Word

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, — пишет Джоэль, и действительно, так оно и есть. Не обманул.

В стиле SQL - 5 (сортировка)

Нередки случаи, когда сама постановка задачи подталкивает разработчика к процедурному решению. Вот пример из практики. В кадровый отчет по сотруднику требуется выводить тип родства, ФИО и дату рождения ближайшего родственника (например: «Отец — Эпиктетов Полуэкт Полуэктович, 01.04.1900»).

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

create table people(
  person_id         number,
  employee_flag     varchar2(1) check(   employee_flag = 'Y' -- yes
                                      or employee_flag = 'N' -- no
                                     ),
  full_name         varchar2(240),
  marital_status    varchar2(1) check(   marital_status = 'M' -- married (or null)
                                     ),
  sex               varchar2(1) check(   sex = 'M' -- male
                                      or sex = 'F' -- female
                                     ),
  date_of_birth     date
);

И есть таблица, связывающая людей с родственниками (связь односторонняя):

create table contact_relationships(
  person_id         number,
  contact_person_id number,
  contact_type      varchar2(1) check(   contact_type = 'C' -- child
                                      or contact_type = 'P' -- parent
                                      or contact_type = 'S' -- spouse
                                     ) 
);

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

Если в поле «Статус» = Состоит в зарегистрированном браке и Отношение = Супруг(а), то выводить данные супруга\супруги.
Если в поле «Статус» значение отличное от значения «Состоит в зарегистрированном браке», то выводим в отчет родственника в зависимости от приоритета.
Сначала проверяется наличие детей (Тип отношения = ребенок), причем если детей несколько, то выводить самого старшего.
Если детей нет, то выводить мать (тип отношения = родитель, пол = жен.)
Если матери нет, то выводить отца (тип отношения = родитель, пол = муж.).

Алгоритм определения ближайшего родственника сформулирован в терминах «если-то» и напрашивается процедурное решение. Напишем функцию, получающую person_id сотрудника и возвращающую... что? Логично было бы вернуть запись из трех полей (тип родства, ФИО и дата рождения), но что с ней потом делать в запросе? Можно написать три отдельных функции, а чтобы не ухудшать в три раза производительность, приделать кэширование. Но не будем усложнять: пусть функция будет одна и пусть она возвращает конкатенацию полей. Она могла бы выглядеть следующим образом:

( запасаемся тухлыми помидорами )