Краткое содержание предыдущих серий
Началось все это
тутАвтор: Зверёк Харьковский
Дата: 25.09.05
. В результате длительного, и изредка даже плодотворного обсуждения, у меня появились существенно новые мысли на заданную тему.
Наиболее сильно повлиявшие на меня сообщения:
*
1aАвтор: eao197
Дата: 26.09.05
,
1бАвтор: 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.