Альтернативный подход к воспроизводимым исследованиям, где исходный код является основной средой
TL;DR:
Подход общего динамического документа (стиль записной книжки IPython) к воспроизводимым исследованиям обычно не приводит к многократному использованию модулей исходного кода. Существуют ли инструменты / подходы, которые используют исходный код в качестве основного носителя и включают в себя текст, чтобы сделать код более пригодным для повторного использования?
Проблема с общим динамическим документным подходом
Мне очень нравится концепция воспроизводимых исследований с использованием динамических документов / тетрадей. Это имеет смысл, особенно с исследованием и анализом данных, где удобно документировать и комментировать процесс анализа, как это происходит. Я обычно использую ноутбуки / ядра Emacs Org-mode и / или IPython, и они довольно хорошо интегрированы. Я также взглянул на R и его аналоги (ESS, knitr).
Однако обычно эти документы состоят из серии блоков кода, которые, как ожидается, будут выполняться последовательно. При запутывании (извлечение исходного кода) результирующий исходный код обычно нелегко повторно использовать в качестве модуля или библиотеки.
И все же я так часто думаю: "О, я хотел бы просто использовать ту конкретную часть анализа, которую я провел несколько дней назад". Обычно получается, что я должен выполнить большинство ячеек перед интересной частью из-за неявных зависимостей. Включение только определенной части сплетенного документа обычно также не легко. И даже если бы это было (с Org-mode's #+INCLUDE директива или LaTeX catchfilebetweentags), обычно разные абзацы не являются самостоятельными. Конечно, я мог бы просто скопировать и отредактировать предыдущий документ анализа и скопировать / вставить / перенести соответствующие части. Но это побеждает цель.
Подвести итоги:
Общий динамический подход к записной книжке поощряет "линейный" стиль разработки кода, то есть фрагменты кода должны выполняться в последовательности и текстовых абзацах, которые следуют обычно линейному повествованию и, таким образом, обычно не являются автономными. Это обычно приводит к плохо используемому запутанному коду и сплетенным текстовым документам.
Ищем возможные решения
Вот некоторые идеи для решения этих проблем, которые я придумала до сих пор.
Исходный код как основной носитель
После некоторого времени я пришел к выводу, что проблемы, описанные выше, проистекают из прозаического / текстового документа, являющегося основным средством. Такой текстовый документ со случайными рисунками и таблицами по своей природе является линейным описанием некоторого повествования. И я думаю, что это то, что поощряет "слишком линейный" стиль.
Если исходный код является основным средством, различные объявления / определения могут быть модульными с самого начала, а их документация / объяснение могут быть автономными. Мастер-документ может затем выбрать только соответствующие части в соответствии с необходимым описанием. В некотором смысле это очень близко к тому, как строки документов используются в Python, извлекаются и обрабатываются с помощью Sphinx. Последовательности построения графиков, таблиц и значений могут быть частью набора тестов или примера кода.
Однако этот подход ограничивает интерактивность по сравнению с обычным подходом. Большая часть интерактивной работы будет выполняться при создании и отладке юнит-тестов или примеров. Не то чтобы поощрение написания юнит-тестов и примеров - это плохо, но это может быть медленнее, чем быстрое тестирование / создание прототипа, например, в IPython. С другой стороны, это будет более последовательным и, возможно, лучше управляемым.
"Нелинейный" стиль грамотного программирования с использованием возможностей noweb
Грамотное программирование тесно связано, но не поощряет этот "слишком линейный" подход, например, ссылки на стиль noweb делают менее "линейный" и более модульный стиль вполне возможным. Это не поощряет это все же.
Тем не менее, он обычно работает хорошо, только когда полностью запутался. Кроме того, он не предназначен для интерактивного использования. Кроме того, на прозаические блоки нельзя ссылаться, как на кодовые блоки, поэтому текстовый аспект все еще остается "линейным".
Мои вопросы
- Есть ли кто-нибудь, кто использует такой подход с исходным кодом в качестве основного средства?
- Кто-нибудь, использующий такой подход, успешно использовал предыдущие отчеты в новых?
- Или сила "нелинейной" теперь не в том, чтобы идти?