Андрій Єршов: «Два вигляду програмування»

Ця замітка з'явилася на світло при міркуванні про розробку програмного забезпечення як людської діяльності. Якщо в цьому плані розглядати роботу програміста, то потрібно розрізняти два, як мені здається, досить різних її види: до однієї з них програміст відноситься як слуга, а до іншої — як господар.



Розвинемо цю тезу детальніше.

Коли я думаю про програміста як про господаря, я маю на увазі, що він програмує для себе. Маючи всі ресурси, всі кошти (віртуально або фізично — неважливо!) у своєму розпорядженні, він є єдиним і остаточним суддею своїх дій та їх результату.

Коли я думаю про програміста-слузі, то він мені уявляється насамперед у вигляді каналу зв'язку, що сприймає пред'явлену йому специфікацію завдання. Відповідальність програміста за правильність специфікації вельми обмежена, з іншого боку, він приймає на себе зобов'язання старанно реалізувати прийняті специфікації та видати клієнту програму-продукт (для разового рахунку або постійного застосування— неважливо!).

Природно, що це розходження помічалося багатьма. Ф. Л. Бауер [1] називає роботу програміста-слуги програмуванням за контрактом. Відповідно можна назвати роботу програміста-господаря програмування для себе. Е. Сандевал [2] розвиває близький підхід, виділяючи групу «кінцевих» програмістів. Іноді це розходження проводять, вживаючи для слуги і господаря терміни професійного і непрофесійного програмування відповідно. Таке трактування допустима, якщо ми будемо досліджувати соціальну сторону програмування як, наприклад, його професійну етику. Якщо ж говорити про програмування, маючи на увазі його внутрішній зміст, то в цьому випадку погляд на програміста-господаря як на непрофесіонала може призвести до непорозумінь.

Програміст-слуга, в деякому (дуже глибокому) сенсі, не знає, чого хоче замовник, і покладається виключно на формулювання проблеми. Звичайно, він не безграмотний, і може знати купу речей про предметної області. Він може надати замовнику неоціненні послуги, виявивши багато невідповідності в його специфікаціях. Однак, все це понад плану. Його головне і єдине діло — перетворити специфікацію надійний і ефективний результат: програму або дані.

Це той вигляд програмування, над яким працювали найбільше і який домінував у період становлення програмування. Ця праця призвів до можливості строго обґрунтувати кожен крок побудови програми, і ця можливість, без сумніву, є найбільшим досягненням обчислювальної науки. Методологічний принцип абстрагування від змістовного знання програмованої завдання виявився дуже плідною: він привів до розробки загальнозначущих і потужних методів маніпулювання програмами і міркування про них, спираючись на схемне представлення програми у неинтерпретируемой сигнатурі елементарних операцій і предикатів.

Інший вигляд програмування, тим не менш, теж існував все це час. Будучи повернений у бік задвірок програмування, однак він набирає «друге дихання» у зв'язку з появою і розвитком персональних ЕОМ. Мало того, системний програміст на своїй кухні, уставленою інструментальними машинами, часто поводиться як господар. В цьому господарстві вже накопичилися такі засоби, як розширювані мови, макропроцессоры, переписують системи, операції періоду компіляції, універсальні редактори і багато іншого. Цей асортимент, однак, склався випадково і не впорядкований ні гарною теорією, ні надійної методології. Тільки недавно з'явився збірний термін, під який, як під прапор, збираються бессапожные системні програмісти, — програмна обстановка (programming environment), або, більш розгорнуто, але зате більш точно для російської мови — операційна обстановка для побудови програм. Перетворити це модне слововживання в струнку методологію з солідним теоретичним обґрунтуванням — важлива і захоплююча завдання теоретичного і системного програмування 80-х років.

Програміст-господар знає, що йому треба.

У цьому корінна методологічна різниця між програмуванням за контрактом і програмуванням для себе. Цей принцип емпірично намацали розробники експериментальних персональних ЕОМ, які без вагань віддали пріоритет дії перед планом.

Як висловився Дж.Аттарди [3]: «бачити і діяти, а не запам'ятовувати і писати». Природно, що адепти суворого підходу сприймають це як єресь, проте насправді — це нове явище в програмуванні, яке потребує теоретичного осмислення та опрацювання.

Мета цієї статті — викласти варіант теоретичної моделі програмної обстановки, в якій працює програміст-господар. Цю модель я називаю трансформаційної машиною (ТМ). Машина підтримує різні перетворення (трансформації) пар «програма-дані» пари«програм а-дані». Правильно влаштована ТМ зберігає функціональний інваріант перетворюються пар, тобто якщо (p', d') = t(p, d), де t — трансформація, виконана машиною, то p'(d') = p(d).

Іншою важливою властивістю трансформаційної машини є те, що вона будується самим програмістом. Її побудова є ієрархічною конструкцією, і виділений рівень цієї ієрархії я, слідуючи Е. Сандевалу, А. А. Берсу і П. К. Леонову, буду називати контекстом.

Контексту доступні перетворюються пари (p, d) і набір базових перетворень, кожне з яких здійснює елементарне (на цьому рівні) перетворення пари (p, d) в іншу пару (p', d') зі збереженням функціонального інваріанта. Базові перетворення поділяються на три категорії — редукції, розкриття і конверсії. Редукції мають справу з інтерпретацією елементарних (на цьому рівні) операцій і предикатів, розкриття розкривають складові конструкції, а конверсії носять схемно-комбінаторний характер. Прикладами редукції є, наприклад, заміна конструкції якщо іст то А інакше все на А або 3+5 на 8. Приклад розкриття — реалізація виклику процедури шляхом її відкритою підстановки, а приклад конверсії — перерозподіл пам'яті або економія співпадаючих подвираженій.

Що важливо?
Важливо, що базові трансформації можуть бути застосовані вільно. Їх застосування в довільній послідовності не порушує функціонального інваріанта перетворюваної пари. Це дозволяє головну трудність: програміст може зробити те, що хоче, не боячись помилитися. Цього мало. Редукції з розкриття і конверсії володіють певним властивістю повноти. Повнота редукций і розкриттів дозволяє знаходити єдиним чином нормальні форми пар (p, d), отримуючи їх як нерухомі точки базових трансформацій.

Якщо функціональним інваріантної пари (p, d) є константа c = p(d), то тоді нормальною формою цієї пари пари (0, c) з повністю редукованої програмою і з обчисленим результатом в поле даних. Якщо інваріантної пари (p, d) є
деяка функція ϕ(y), то тоді нормальною формою (p, d) буде пара, програмна компонента якої містить деяку
залишкову програму для ϕ, а компонента даних містить ім'я аргументу y і (може бути) деякі константи і імена проміжних величин.

Конверсії теж можуть володіти властивістю повноти по відношенню до деякого схемного инварианту або канонічній формі програми і її даних.

Ієрархія контекстів досягається тим, що знаходження нерухомих точок редукций або канонічних форм конверсій трактується як атомарний акт у контексті наступного рівня, а базові трансформації контексту розкриваються засобами внутрішніх контекстів. Додамо також, що трансформаційна машина представляється зручним концепцією для реалізації абстрактних типів даних, у яких опису типів і операцій реалізуються розкриття, а редукції і конверсії відповідають аксіомам.

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

Звичайно, правила перетворень, придумані програмістами, не можуть бути довільними. Монітор програмної обстановки повинен втілювати і підтримувати деяке знання про функціональної залежності, загальні правила композиційної ієрархії, іменуванні, керуючих та інформаційних зв'язках. Це загальне знання дозволить на будь-якому рівні підтримувати абстрактні інваріанти, що гарантують збереження функціональних інваріантів.

Викладені в цій замітці міркування розвивають вихідний теза в руслі трансформаційного підходу до програмування. Його особливість полягає в тому, що напрям маніпуляцій з програмами не стільки вимагає предпланирования, скільки визначається складається обстановкою.

Програміст-господар, однак, тільки тоді зможе добре розпорядитися наданою йому свободою дій, якщо буде добре бачити поле для їх застосування. Великий і чіткий екран дисплея потрібен програмісту так само, як широке і чисте вітрове скло автомобілісту. Але якщо за вітровим склом дійсність сама підставляє водієві дорожні знаки і ситуації, то для системного програміста потрібно ще багато попрацювати, щоб перетворити підсліпуваті літери алфавітно-цифрових дисплеїв в компактне і наочне зображення програм і даних. Хотілося б звернути увагу читача на деякі нові принципи взаємодії людини з машиною, висунуті так званими об'єктно-орієнтованими мовами, з яких в першу чергу треба виділити мова Смолток [5].

Повертаючись ще раз до розрізнення дух зовнішностей програмування, слід визнати, що, спираючись в кінці-кінців на одне і те ж пристрій — ЕОМ, обидві форми програмування математично цілком перекладаються один в одного. Тим не менш, як практичне, так і теоретичне їх розрізнення допомагатиме справі, дозволивши забезпечити обидві категорії програмістів адекватними операційними засобами, методологічними установками і математичними теоріями.

1. Bauer F. L. Programing as fulfilment of a contract. — In: «Infotech state of the art reports, Series 9, No.6. System Design». — Maidenhead: Pergamon Infotech, 1981, p. 167-174.
2. E. Sandewall. An environment for development and use of executable application models. — In: Records of the 2nd Software Technology Seminar, Capri, May 3-7, 1982, p. 12+43p
3. Attardi G. Office information systems desing and implementation. — (Technical report) Cnet No.47. Instituto di Scienze-Informazione Univers. di Pisa, Pisa, 1980, 44p.+ii.
4. Єршов А. П. Змішані обчислення: потенційні застосування і проблеми дослідження. — У кн.: Методи Математичної логіки в проблемах штучного інтелекту і систематичне програмування. Тези доповідей і повідомлень. Частина 2. У надзаг.: Ін-т математики і кібернетики АНЛитССР. Вільнюс, 1980, с. 26–55.
5. Ingalls D. H. The Smalltalk-76 programming system: design and implementation. — In: Proceedings of the 5th Annual ACM Symposium on Principles of Programming Languages, 1978.

1982
З Архіву Єршова [источник]

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.