Литературное программирование, часть 1

[anton_nazarov]

Кнут придумал литературное программирование в начале 1980-х годов, во время работы над TeX-ом. Надо сказать, что первую версию TeX-а он написал и отладил на бумаге, а ввёл в компьютер лишь спустя несколько месяцев.

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

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

Кнут, вполне естественно, предложил для текста TeX. Кроме того, в тот момент он использовал язык программирования Pascal, строгость которого усугубляется требованием однопроходной компиляции. Из-за этого порядок определения функций, типов и переменных строго фиксирован, что противоречит требованию понятности изложения. Так что Дональду Кнуту пришлось написать свою систему WEB, которая устроена примерно так. Программа состоит из кусочков (chunks)документации, чередующихся с кусочками кода. В кусочках кода можно ссылаться на другие кусочки, причем ссылки могут идти и вперед, и назад, а на один кусочек может быть несколько ссылок. Получается своего рода сеть, отсюда и название, которое потом использовали для похожей структуры документов в интернет.

Чтобы такую программу можно было использовать, есть две утилиты - tangle, которая вытаскивает кусочки кода, подставляет их на место ссылок и формирует программу, которую можно скомпилировать, и weave , которая форматирует кусочки кода командами TeX и создает документ TeX, который можно распечатать.

TeX и написан таким образом, а человеко-читаемая версия вышла в виде книги "TeX: The program".

Кстати, чтобы получить эту книгу в электронном виде, достаточно скачать исходный код TeX и выполнить следующие команды:

weave tex.web
tex tex.tex
xdvi tex.dvi

или

pdftex tex.tex
xpdf tex.pdf

Потом Кнут перешёл на язык C (который он хвалил в своём интервью, см. предыдущий пост ) и написал CWEB. Возникли и другие инструменты, например, noweb, nuweb, rambutan и другие.

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

Сам Дональд Кнут в своем интервью в книге описал ситуацию следующим образом, сославшись на Джона Бентли:

"[Т]олько два процента людей могут быть программистами. И только два процента могут быть хорошими писателями. А Кнут хочет чтобы все сочетали эти качества."
Я не думаю, что количество программистов в мире когда-нибудь превысит два процента - я имею в виду программистов, которые действительно способны находить общий язык с машиной от рождения. Однако теперь люди ведут блоги. Поэтому я заметил, что в среднем способность выражать свои мысли сильно растет, поэтому второй аргумент уже не имеет такого значения.

То есть ситуация улучшается благодаря всеобщему увлечению блогами. Программисты начали писать про программирование и иногда получается очень интересно, например у Джоэла Спольски (Joel on software) или у Стива Йегги (Steve Yeggae и тут). Так что литератуное программирование, возможно, ещё достигнет популярности.

Литературные программы, ориентированные на то, что их будут читать люди, хорошо подходят как для сопровождения в течении длительного времени, так и для совместной работы и обучения. Мне кажется, что литературное программирование в этом смыкается с OpenSource-движением. Для совместной работы над кодом существует масса сервисов, начиная от систем управления версиями (и социальных сайтов типа github на их основе) и заканчивая различными pastebin-ами (paste.lisp.org, pastebin.org и т.д.).

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

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

Comments

[anton-nazarov.livejournal.com]

Я не имел в виду сравнение Haskell со Scheme, совсем. Понятно, что это сравнение будет в пользу более нового и продвинутого языка. Мой комментарий скорее можно интерпретировать как сравнение Haskell с тем, как народ сейчас пишет вычислительные вещи (C++, SciPy/NumPy, Mathematica, Matlab, и т.п.).
У меня есть кусок кода на Maple, в котором выражены всякие алгебраические вещи, которыми я занимаюсь. Он выглядит ужасно, так как Maple довольно кривой язык, в котором сложно выражать новые абстракции. Я думал переписать этот код на каком-то другом языке, но от переписывания на Haskell пока отказался из-за упомянутых сложностей. Ведь из-за них этим кодом вряд ли сможет воспользоваться кто-то кроме меня и даже мне будет трудно на других машинах, так как придётся доустанавливать какие-то билиотеки и т.п. Вот сейчас думаю про Математику, она вроде лучше Maple как язык и вообще на Lisp похожа.

Насчёт проблем с платформами ты уже и сам отписался, у меня были некоторые трудности со сборкой ghc на машине с OpenSUSE 10.2 без прав рута (это совсем не старый дистрибутив, но тем не менее).
Под не работает по отношению к NumericPrelude я имел в виду, что если использовать эту библиотеку, то сломаются все остальные, то есть я окажусь с более хорошими числами, но без линейной алгебры.

[sergeif.livejournal.com]

Не очень понимаю почему с этой библиотекой должно перестать работать то, что работало раньше, но не пробовал, и верю тебе.

Народ вычислительные вещи все-таки на plain C пишет, наверное. Благо и библиотек достаточно. А лучше всего Intel C compiler + Intel Math Library, работает понятно на каких платформах, но рулит по скорости безмерно (интересно, что иногда на бинарник ругается мой антивирусник). А если еще и Intel Parallel Studio заюзать... Но это все около 2К$ стоит, хотя и вполне оправдывает цену. Делаешь библиотеку с нужным тебе вычислительным ядром и после этого пишешь GUI на каком-нибудь Qt -- супер!

Вот с NumPy у меня схожая ситуация, что у тебя с Numeric в Haskell. Мне NumPy был нужен исключительно для установки Biopython'а, версию поставил из списка совместимых. Очень часто эксепшены появляются в части, которая юзает NumPy. Моей квалификации не хватает, чтобы понять что именно не так, но вот с точки зрения пользователя Biopython, NumPy -- зло.

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