В этот раз позволю себе откровенно позловредничать. Но сразу хочу подчеркнуть, что есть библиотеки и разработчики библиотек (против которых я ничего не имею), а есть сам Boost – организация со своими целями и проблемами. Вот про организацию речь и пойдет.
Цитаты из свежего письма в списке рассылки “Boost Announce”:
As always, we need experienced review managers. The review queue has
been growing substantially but we have had few volunteers, so manage
reviews if possible and if not please make sure to watch the review
schedule and participate.We are also suffering from a lack of reviewers. While we all
understand time pressures and the need to complete paying work, the
strength of Boost is based on the detailed and informed reviews
submitted by you. A recent effort is trying to secure at least five
people who promise to submit reviews as a precondition to starting
the review period.
На мой взгляд, начинает проявляться изначальная проблема организации Boost-а: сбора разнородных библиотек под одну большую крышу. Это не правильная политика. По двум причинам (как минимум):
- Сам механизм отбора базируется на механизме добровольного review. За развитием Boost-а следят далеко не все практикующие программисты, а только небольшая их часть, которым это интересно. Среди этой небольшой части есть только часть тех, кто принимает участие в review. Ну и еще вопрос о том, насколько заинтересованы именно они в этой конкретной библиотеке.
- Попавшие в Boost библиотеки оказываются, я бы сказал, лучше распиаренными, чем их аналоги вне буста. Поскольку “Boost – это бренд” и сейчас многие программисты в поисках подходящего инструмента сначала заглядывают в Boost, а уже потом смотрят вокруг.
Из этих двух причин проистекают различные следствия.
Тот же процесс review. Откуда возьмутся толпы добровольцев, которые захотят рассматривать десятки предлагаемых к включению в Boost библиотек? Особенно, если изрядная часть этих библиотек решает какие-то специфические и нетривиальные задачи.
Далее, вошла в Boost библиотека и что потом? Пока автор библиотеки имеет желание и возможность ее развивать и поддерживать – она будет жить. А потом? Откуда возьмется новый доброволец, который будет занимается ей дальше? Если речь идет о какой-то очень востребованной и безальтернативной библиотеке (вроде Boost.Multindex), то желающие найдутся. А если это какой-нибудь FiniteStateMachine или Spirit?
Что будет происходить, когда в Boost будут предлагать включить альтернативные варианты уже имеющихся в нем библиотек? Вот сейчас есть Boost.Range. Хотят еще добавить какой-то RangeEx. В чем смысл существования под одной крышей обоих Range?
До каких пределов будет увеличиваться размер Boost-а? Сейчас его tar.bz2 архив занимает порядка 30Mb. Что будет дальше – 50Mb, 100Mb? И это при том, что в 1.5Mb архиве POCO практических инструментов для решения моих насущных задач оказывается больше, чем в 30Mb Boost-е.
Что, в конце-концов, представляет из себя Boost – это полигон для отбора новых библиотек в стандарную библиотеку будущих версий C++ или же это собрание production ready компонентов для использования в промышленной разработке? Если честно, то я не представляю, как оба эти качества могут объединяться в одном проекте.
А что, на мой взгляд, могло бы стать альтернативой Boost-а?
Во-первых, унифицированная кроссплатформенная система сборки C++ проектов. Тот же Scons. Ну или CMake. Хотя и мой Mxx_ru был бы не плох ;)
Во-вторых, унифицированная система дистрибуции C++ных библиотек. Аналог RubyGems. Т.е. нужен тебе C++ный компонентик (C++ный кирпичик -- C++ brick), скажем RangeEx, ты делаешь:
cppbrick install RangeEx --version ‘>1.3.0’
и получаешь компонент RangeEx с последней стабильной версией, номер которой больше 1.3.0.
В-третьих, централизованное хранилище доступных C++ компонентов. Аналог RubyForge. Кроме того, что это хранилище будет использоваться для загрузки нужных пользователям C++ компонентов, на нем еще будет вестись статистика использования компонентов. И данная статистика как раз будет одним из критериев определения востребованности и качества компонента.
В-четвертых, централизованная система тестирования компонентов. Например, когда новая версия компонента публикуется в хранилище, разработчик компонента указывает, какие версии сторонних компонентов ему нужны. Скажем, RangeEx версии 1.3.5 нуждается в Config 3.4.* и IteratorTraits 2.0. После публикации хранилище производит автоматическое тестирование RangeEx 1.3.5 с соответствующими версиями Config и IteratorTrais. И отчет тестирования публикуется вместе с описанием компонента. Чтобы потенциальные пользователи могли его увидеть. Можно пойти и еще дальше. Когда разработчик IteratorTraits публикует новую версию, которую он объявляет совместимой с версией 2.0, хранилище может автоматически протестировать ее со всеми компонентами, которые зависят от IteratorTrais 2.0. После чего отчеты тестирования могут быть отправлены как разработчику IteratorTraits, так и разработчикам использующих IteratorTraits компонентов.
Такой подход, на мой взгляд, позволит отказаться от процедуры review вообще. Человек делает библиотеку для себя, публикует ее. Если это хорошая библиотека, если она в достаточной степени задокументированна, то она будет использоваться. Если она будет использоваться и разработчик захочет ее развивать – он будет прислушиваться к мнениям и пожеланиям пользователей. Если же разработчик не захочет больше ей заниматься, то ничего страшного – она все равно останется опубликованной и для нее будет известно, с какими версиями сторонних компонентов она может работать.
Что еще важно, так это то, что я получаю возможность выбрать для себя только то, что нужно мне здесь и сейчас. И получить только это. Если мне нужен 100Kb RangeEx для которого потребуется 1Mb Config и 500Kb IteratorTraits, то я получу только 1.6Mb зависимостей для моего проекта. А на 30Mb, как сейчас.
Вот как-то так.
Мне кажется, что корень проблем — один: для комфортной разработки нужно слишком много «базовых дополнительных» библиотек (строки, массивы, словари, диапазоны, свойства, итераторы и проч.)
ОтветитьУдалитьДа, такие штуки должны быть общими для всех (считай — в std::), а «дополнительные библиотеки», «зависимости» — это уже прикладные вещи (насколько я знаю, в Руби тот же Facets редко кто использует — а все лепят собственный, независимый core_ext.rb).
С Бустом изначально, действительно, было непонятно — то ли это вот такой же std_ext:: (и тогда надо требовать его наличия везде), то ли сборник библиотек на все случаи жизни. И именно оттуда эта неясность и бралась: какой-нибудь Spirit вроде как независим, но если он завязан на 3-4 бустовских библиоетки (а буст есть не везде!) — то «естественно» включить его в буст.
Мне вообще кажется, что именно в этом вопросе (нехватки общих примитивов) вообще основная проблема и причина смерти плюсов.
На мой взгляд, буст давно превзошел состояние, когда его можно было рассматривать как некий std_ext:: -- большую библиотеку, которая должна стать стандартной библиотекой следующей версии C++.
ОтветитьУдалитьБыл бы буст объемом в 3-4Mb архива, содержались бы в нем основные базовые элементы (ranges, multi_index, hash_table, regex, random), которые действительно достойны быть в стандартной библиотеке и необходимы там -- вот это было дело. Не жалко было бы таскать за своими проектами новую зависимость.
Но туда же затолкали фиг знает чего. И математику. И парсинг. И асинхронный ввод-вывод. Т.е. своим объемом и желанием добавить в буст по какой-нибудь библиотечке на все случаи жизни буст, фактически, был переведен из разряда std_ext в разряд рядовой универсальной самоделки (на ряду с ACE, Poco, wxWidgets, Qt). Но при этом с продолжением позиционирования себя в качестве std_ext. И это, я считаю, не правильно. Как и не правильно продлжение его распространения в виде одного большого архива.
А что до слухов о смерти плюсов... Они, имхо, сильно преувеличены :) С одной стороны крисис, как мне кажется, играет на руку плюсовым разработкам. С другой стороны для тех же маломощных нетбуков разрабатывать приложения на плюсах более логично, чем на прожорливых Java/.Net.
да просто для простых и очевидных (в применении) библиотек найти ревьюеров нетрудно - все с областью знакомы.
ОтветитьУдалитьТ.е. когда предлагается какой-нть Boost.Log - тогда ревью пишется куча, а когда какой-нть мощный, но заумный Boost.Egg - ревью никто не пишет, потому что далековато от народа.
Там в форме ревью есть специальынй пункт - насколько Вы сведущи в данной области?
По хорошему, ценность ревью от несведущего человека близка к нулю, а для хитрых библиотек найти сведущего человека тяжело.
Потом, с хитрыми библиотеками еще разбираться надо, в отличие от понятных Boost.Spirit или Boost.MultiIndex, когда понятно, чего от них ждать и как их тестировать.