Свободное метапрограммирование

предыдущая серия

Но в чем же все таки эксклюзивная особенность литературного программирования (LP)? Ну вот пишем мы подробные комментарии к каждой логической части кода, и что? Почему такой подход вносит некие качественные изменения в процесс разработки?

Вспомним интервью Кнута 2008-го года. Вот ее ключевые моменты:

— Кнут не любит и практически не пользуется unit-тестами и даже предпочитает не компилировать код слишком часто (проверяя его на синтаксическую корректность). Однажды он написал на Алголе для конкурса Memorial Day Programming Race 1971 г. программу, которая заработала после всего двух прогонов компиляции.

…Идею немедленной компиляции и «тестов частями» я использую редко, только если ищу дорогу в совершенно неизвестной среде и мне очень нужна обратная связь о том, что работает, а что нет. В противном случае куча времени тратится на деятельность, которая не нужна и о которой я даже не думаю. Мне нет особой нужды «импровизировать».

— Кнут сторонник знания классических вычислительных алгоритмов, но только не параллельных.

Я не удивлюсь, если вся идея многопоточных вычислений окажется лажей. За прошедние 50 лет я написал более тысячи программ, и большинство из них довольно серьезного размера. Но при этом я не могу назвать даже пять из этих программ, исполнение которых значительно улучшилось благодаря параллелизму или многопоточной обработке…
Я знаю, что параллельные вычисления важны для рендеринга графики, взлома кодов, сканирования изображений, моделирования физических и биологических процессов, и так делее. Но все эти приложения требуют специально заточенного кода и специфических алгоритмов, которые необходимо менять каждые несколько лет.

— Наконец, фишки по поводу LP.

Грамотное программирование — это очень персональная вещь. Я люблю этот проект — но возможно, это потому, что я очень странный человек. У проекта тысячи фанатов, но не миллионы…
По моему опыту, софт, созданный с использованием грамотного программирования, оказывается значительно лучше, чем тот, что создается традиционными способами. Тем не менее, обычный софт тоже зачастую не так плох — я бы поставил ему «тройку», а не «кол». Именно поэтому традиционные методы остаются в ходу. И поскольку эти методы понятны огромному числу программистов, у большинства из них нет стимула меняться…
Очень малый процент людей в мире хорошо программируют, и очень малый процент — умеют хорошо писать документацию; а я еще требую от людей, чтобы они попали сразу в обе эти группы…

Грамотное программирование определенно является самой важной вещью, которая вышла из моего проекта TeX. Это не только помогло мне писать программы быстрее и надежнее, но и оказалось одним из главных источников удовольствия с 80-х годов. Некоторые из моих главных программ, такие как мета-симулятор для MMIX, просто не могли быть написаны с какой-либо другой методологией программирования. Сложность программы была слишком высока для того, чтобы с ней справился мой ограниченный мозг; без грамотного программирования вся затея бы рухнула.

Каждая часть кода сопровождается описанием того, зачем он вообще нужен и что делает.

 Я должен предупредить читателя воспринять многое из того, что я скажу, как бред фанатика, который думает, что он только что обрел просветление. Мне так нравится эта новая методология, что трудно удержаться от того, чтобы не вернуться к каждой когда-либо написанной мной программе и не переделать её в «литературную».

Наконец я могу писать программы так, как они и должны быть написаны. Мои программы не только объяснены лучше чем когда-либо прежде; они лучше как программы,
потому что новая методология заставляет меня делать свою работу лучше.

LP сегодня позиционируется как а) удобный механизм документирования кода в крупных/сложных проектах и б) хороший способ обучения программированию. Нас интересует противоположный момент: как, возможно, даже с минимумом документации, успешно применять LP в мэйнстриме для сверхкрупных проектов, чтобы эффективность была бы сравнимой, например, с Type Driven Development? Ведь даже отсутствие комментариев в коде все равно может соответствовать LP, и наоборот, огромное количество комментов в исходниках однюдь не делает такую «технологию» литературным программированием.

Предположим, что ключевым в LP будут а) представление структуры проекта в виде, удобном для понимания человеку, а не компьютеру (и в частности, визуальная запись программы «по-человечески») и б) использование псевдокода, начиная с самых высоких абстракций, и постепенная детализация этого псевдо-кода, который на некотором шаге детализации превращается в код на реальном языке программирования. По сути, мы пишем код на некоем удобном нам мета-языке, который не есть реальный DSL со всеми техническими ограничениями, а скорее некое псевдо-подобие макро-команд в конкатенативных языках. Поэтому мы совершенно свободны в выдумывании нашего мета-DSL, не требующего никакого времени на реализацию!

И для всего этого чуда требуется лишь небольшая утилита, которая а) запутывает (tangle) словесное описание в код программы и б) сплетает (weave) из словесного описания документацию.

Далее рассмотрим этот подход на практике.

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

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

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