LP, BDD, AOP и другие

Литературное программирование (literate programming, LP), оказывается, столь интересная и, в частности, противоречивая концепция, что ее нельзя выразить неким формальным описанием. Проблемы начинаются уже с названия: по-русски корректным будет называть LP как «литературное», так и «грамотное» программирование (грамотное — в смысле, правильное, по делу). Однако эти оба определения несут весьма разный смысл. В частности, под литературным программированием часто понимают подробное документирование кода, которое потом автоматически компилируется в документацию. Причем сперва как правило пишется документация (что будем делать), и лишь потом код.

К грамотному программированию, наоборот, относят концепции из структурного программирования (которое, согласно Кнуту, как раз прямая противоположность LP!). То есть вроде как соблюдаем прозрачный стиль, пишем код предельно понятно, даем переменным очевидные названия и т. д.

LP — это совсем про другое. Пожалуй, ни одна из известных технологий/методологий/… программирования не сочетает в себе столь выраженно три аспекта разработки: инженерию, искусство и науку, как литературное программирование. Именно поэтому LP трудно определить каким-либо единым формальным способом.

Вот как, довольно абстрактно, определял LP сам его автор, Дональд Кнут, в 1983 году:

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

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

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

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

Немного более формальным будет такое слегка рекурсивное определение: «литературное программирование — это когда программа есть своя собственная документация». В LP невозможно без парадоксов!

Можно пойти от обратного — чем LP не является? Под LP нередко понимают, например, Behavior Driven Development, этакую неформализованного предтечу Type Driven Development. Но и BDD — это тоже совершенно иной подход. В BDD мы пишем «человекочитаемые» исполняемые тесты, которые прозрачно направляют процесс разработки «сверху вниз» и так же прозрачно контролируют продвижение к результату. В LP мы вообще никак не завязаны на тесты. Скорее, автор пишет понятный человекам документ, в котором объясняются проблемы и пути их решения, причем сам код (псевдо/макро код) интегрирован в такое объяснение — читаемое последовательно для человека и естественно для человека, а не для компьютера! Такой документ простыми утилитами конвертируется в исполняемый формат (или, конечно, в документацию).

Отмечу, что документация в LP — это описание реализации системы, а не пользовательская инструкция. И в тоже время это описание описывает не код как таковой, а то, что этот код делает в контексте всей системы.

LP — это и не аспектно-ориентированное программирование (Aspect-Oriented Programming), когда мы выделяем в системе «аспекты» — как бы размазанные по множеству частей кода единые с логической точки зрения функциональности. Например, логгирование, синхронизацию, обработка ошибок и т. п. — это все аспекты, каждый из которых естественно хранить в одном текстовом модуле. А прошиваются аспекты в системе с помощью специализированных инструментов. LP отличается от AOP тем, что хотя вроде бы в литературном программировании тоже есть «аспекты», которые связаны с другими подсистемами в виде сети, акцент делается прежде всего на описательности кода, а наличие или отсутствие аспектов в смысле AOP вторично.

Насколько же LP можно назвать «методологией»? Пожалуй, настолько же, насколько методологична Test Driven Development (и даже Type Driven Development).

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

Собственно, профессиональные программисты часто пишут весьма подробные текстовые описания системы (наподобие детальных Технических Заданий) — так будет естественным сразу совместить код и документацию. LP реализует эту схему так: нужен язык реализации (например, Паскаль), нужен язык документирования (например, TeX) и нужен язык/фреймворк сборки задокументированных «кусков» в действующую сеть, для чего обычно применяются стандартные web-технологии.

Классический пример — это легендарная книга TexTheProgram, в которой с помощью LP приводится подробно описанная реализация TeX на Паскале. Рекомендовано к изучению! Кнут, сильно ограниченный стандартным компилятором Pascal, придумал по сути уникальный препроцессор. Вот этот гениальный и пока никем не повторенный способ мышления профессора мы и попробуем смоделировать.

продолжение следует

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *