Codepedia 2: сага о фреймворке
От: Зверёк Харьковский  
Дата: 29.09.05 19:55
Оценка: 45 (5) +1
Краткое содержание предыдущих серий
Началось все это тут
Автор: Зверёк Харьковский
Дата: 25.09.05
. В результате длительного, и изредка даже плодотворного обсуждения, у меня появились существенно новые мысли на заданную тему.
Наиболее сильно повлиявшие на меня сообщения:
* 1a
Автор: eao197
Дата: 26.09.05
,
Автор: buriy
Дата: 26.09.05
— сведения о том, как близкие идеи организованы в действующих проектах.
* 2
Автор: FreshMeat
Дата: 29.09.05
(спасибо за подробный анализ, коллега!) — обоснование утопичности "независимых сниппетов".

Нижеследующий текст — в существенно большей степени философское рассуждение, нежели практическое предложение. Цель его — дать толчок развитию идей и обсуждений. Поехали.

Связь между кусками кода необходима
Codepedia, как набор совершенно независимых друг от друга сниппетов — это очевидная (для меня) теперь ошибка. Очень немногое количество концепций и абстракций могут быть реализованы без опоры на другие концепции и абстракции (FreshMeat убедительно показал это в [2] на примере простейших геометрических абстракций).

Да, все верно: продолжая аналогию с Wikipedia (да и вообще любой энциклопедией) — ценность ее в немалой степени определяется кросс-ссылками на другие "статьи" (в нашем случае — сниппеты). Это позволяет описать одну, чистую идею, привязывая underlying и related концепции ссылками. К вопросам и проблемам реализации "ссылок на другие концепции" в формализованных языках я вернусь ниже.

А сейчас мне хотелось бы поднять один вопрос крайне философского характера.

О библиотеках, которые поддерживают язык
Общим местом уже стала следующая сентенция: помимо языка, очень важны библиотеки. Т.е., по крупному счету, сегодня у программиста на каком бы то ни было языке не должно вставать вопроса, как же реализовать регекспы, математику, работу с сокетами, процессами, потоками и прочими вопросами, решаемыми "раз и навсегда" (размещу в скобках свое имхо: при этом, скажем, определенная свобода выбор все же обязана быть — в форме выбора "стратегий" там, где это уместно). Соответственно, такая вот "библиотека" должна существовать для языка, если он рассчитывает на практическое (промышленное) применение. Отличительной особенностью такой всеобщей "библиотеки" (из-за каковой особенности я и беру ее в кавычки) должна быть ее странная, "сильно-слабая" связность: с одной стороны, монолитность такого объемистого набора кода (когда ее надо целиком устанавливать, прилинковывать, или, скажем, собирать перед использованием) порождает достаточно много неудобств. С другой стороны (и это уже пересекается с нашими сниппетами и их взаимозависимостями) — разумные связи должны быть: например, поддержка регекспов и работа с сокетами должны (бы) использовать один и тот же тип строки, а не вводить каждая свой.

Теперь прикинем, как концепция "глобальной библиотеки" (кстати, есть для нее какой-то однозначный термин?) реализуется для разных языков.
Господа, я могу ошибаться в деталях. Поправки, а тем паче дополнения — welcome.
* Perl — имеется централизованный сборник модулей. Пишет и помещает их туда — кто угодно. Если мне нужна какая-то специфичная функциональность на Perl — я первым делом иду на CPAN и ищу там соответствующий модуль.
* .Net — имеется огромная "встроенная" библиотека (собственно, .Net фреймворк), поставляемый производителем. Теоретически, все что нужно — там есть. (Вопрос к дотнетчикам: а если нету — куда вы идете? тоже на SF?)
* С++ — ситуация, на мой вкус, самая тяжелая (внимание! именно с точки зрения "не задумываться о том, как сделать очевидные вещи") Именно к C++ в большой степени относится описанный в [2] печальный процесс — найти код, понять кто и зачем его делал, проверить его работоспособность, выяснить нюансы... и т.п. Есть, скажем, тот же boost; но как всеобъемлющий фреймворк он не вполне тянет из-за того, что старается оставаться в рамках "чистых концепций".

Итого. О чем это я
Вот к чему я все веду.
Я вам опишу сначала идею, ага? И вы над ней немножко подумаете — именно над идеей в целом. А ниже я чуть-чуть про детали реализации поговорю.

Codepedia, которую я тут "задумал", как "движок" всеобъемлющего фреймворка. Выглядит это примерно так: мне нужно "нечто". К примеру, кривая Безье на C++. Я захожу на cpp.codepedia.org и нахожу ее там (как "нахожу" — вопрос отдельный; вроде бы, теги и поиск рулят, но с другой стороны, хорошо бы что-то еще более очевидное cpp.codepedia.org/Bezier_curve — а почему бы и нет?).

Вижу краткое описание — пример использования, публичный интерфейс, полностью код. Плюс информация "контроля качества" — компилябельность, наличие юнит-тестов и результаты их выполнения и т.п. Буде меня все это устраивает, я "забираю" решение с codepedia. Это значит что я получаю код класса "кривая безье", код всех классов и методов, которые он использует (точка, линия, поверхность, математика.....), код юнит-тестов, некоторую сгенерированную документацию — все. При этом, полученный "пакет" должен интегрироваться в мой код одним движением (примеры: Perl-модуль с CPAN нужно только скопировать в каталог modules; в Руби есть RubyGems, позволяющий одной командой установить или убрать библиотеку и все библиотеки от которых она зависит) — и не только в код. Документация и примеры использования — в справочную систему, тесты — в систему тестов... В идеале, еще и проверка обновлений сниппета должна происходить автоматом.

Сама codepedia — суть движок, позволяющий:
* редактировать код прямо на сайте — увидев в реализации кривой Безье некую неэффективность, я нажимаю "отредактировать", вношу несколько изменений, сохраняю — потрачена пара минут, код улучшился.
* "связывать" один сниппет с другим. Причем, даже не путем каких-нито там include или using, а просто — как только в коде я написал некое имя — оно тут же становится ссылкой на соответствующий сниппет. Причем сниппет этот может быть еще не реализован — например, создаю код этой многострадальной кривой Безье, а класса "точка" в codepedia еще нет.
* некоторым образом "проверять" код — на компилируемость, на юнит-тестах (соотв., должен быть и способ вводить их), возможно, просто проверка некоторых инвариантов, возможно, профилирование — и все это с учетом того, что код может опираться на еще не существующие сниппеты.
* документировать код — ооооооо, какая больная тема
Автор: c-smile
Дата: 25.09.05
. Проблема синхронизации документации с кодом.... Брр...
* и, конечно же, "доставлять" код тому, кто хочет его использовать — собирать "пакет" (код + все зависимости + вся документация... короче, см. выше)

Все это нужно зачем? За "эффектом Википедии" — созданием единого источника информации, надежность и полнота которого обеспечена миллионом леммингов. За эффективным созданием фреймворка пользователями языка, а не производителем. За шкафом, в конце концов!

И напоследок...
...о проблемах реализации. Помимо технических, описанных в Codepedia 1
Автор: Зверёк Харьковский
Дата: 25.09.05
, имеется огромная идеологическая проблема: создание сниппета, который опирается на еще не созданные. Все в том же примере с кривой, пишу я, к примеру: "point a;", класса point еще нет, как должно выглядет его использование? Допустим, я использую его, вызывая point.x, point.y, point+point... Что сразу "фиксирует" интерфейс еще не существующего сниппета (тот, кто будет его создавать, должен следовать этому интерфейсу; да и тот, кто станет использовать еще-не-существующий point в другом сниппете — тоже уже обязан следовать ему). Проблема тут, естественно в том, что "первый пользователь создает интерфейс" — и если этот "первый пользователь" потребовал у точки наличия какого нибудь .isInsideMyCoolPoligon — разумно ли, что будущая точка уже обязана иметь такой метод? Отнюдь.

В общем, dixi.
FAQ — це мiй ай-кью!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.