[prog.thoughts] Развернутый ответ SleepyDrago по поводу наезда на Boost-оводов

Как уже не раз бывало, начал писать ответ в комментариях, но текст получился слишком большим для комментария, поэтому появилась данная заметка. Итак:

2Евгений:
наезды на бюст не понятны. Они нам ничего не должны ;)
Я вот могу сказать что я рад что я вообще не смотрел на bjam, несколько spirit'ов, кучу мета-, boost.preprocess и кучу мелких. Ну и ? это не значит что кому-то оно не пригодилось. Более того я рад что ничего не знаю про poco,ace, rubygems :)
а из комментария jazzer'а мне понятно что я ничего не узнаю про этот риппл ))

ps Про bjam например стало очевидно когда те, кому надо билдить много, померяли и обсудили его перформанс.

Ну на меня иногда находит... Ведь C++ совсем не плохой язык. Какие-то вещи на нем делать намного приятнее, чем на Java, скажем. Но, поскольку мне приходится работать на C++, то жалко смотреть на то, что он уже довольно сильно ушел от мейнстрима. Т.е. продуктов на нем делается много, но вот молодых программистов, которые бы умели программировать на C++ становится все меньше и меньше. Такое впечатление, что многие просто не хотят связываться с этим старым монстром.

А ведь ситуацию можно есть не исправить, то хотя бы улучшить. Да, проблемы языка никуда не денутся. Все равно ноги будут отстреливаться, а C++ные программисты будут проводить ночи в поисках запорченных указателей. С этим ничего не поделать (кроме как выправлением кривых рук). Но вот работу с библиотеками улучшить можно. Сейчас чтобы поставить OpenSSL нужно взять Perl, выполнить по инструкции настройку OpenSSL, потом скомпилировать, потом прописать пути. А если приходится работать с разными компиляторами на одной платформе – то проделывать это несколько раз. Установка Boost-а – своя история, установка Qt – своя. И т.д.

И это не касается языка (т.е. язык накладывает свои ограничения, но это уже просто исходные условия для решения задачи) – это касается инструментов, которых почему-то нет. Хотя лично мне они нужны. И, думаю, нужны они не только мне. Ну а если инструмент нужный, то должен же он когда-то появится.

А теперь представим, что какие-то инструменты для дистрибуции C++ных библиотек появились. Штуки три. От Васи Пупкина, Джона Смита и Кумара Гашишовава. О каждом из которых знает человек двадцать-тридцать друзей и коллег авторов данных инструментов. Какие шансы у этих разработок, даже если они удобны и качественно сделаны, стать настоящим мейнстримом в C++ коммунити? Очень маленькие, имхо.

Совсем другое дело, если бы велосипед по дистрибуции библиотек появился в составе Boost-а. Это как iPhone от Apple – как телефон фигня, зато какой ажиотаж! Еще пример: я слышал, что многим не нравится qmake из Qt. Но им пользуются, поскольку это штатный инструмент для Qt.

Так вот, если бы Boost выпустил что-то вроде RubyGems для C++ – это было бы очень и очень знаковое событие. Что радует, Boost-оводы сами осознали необходимость такого инструмента. Кроме того, Boost-оводы позиционируют себя как активные развиватели C++ – это же их цель – отбирать новые библиотеки для включения в следующий стандарт C++. Ну так почему бы не заложить в стандарт и систему пакетов/библиотек для C++ (тот же RubyGems уже входит в стандартную комплектацию Ruby 1.9)?

Т.е. Boost действительно никому ничего не должен. Но я не вижу другой настолько же авторитетной консолидирующей организации в C++ коммунити, которая бы смогла такой инструмент протолкнуть в жизнь. Разве что Qt, но Qt – это вообще отдельный континент на планете C++, со своими законами и целями. То, что хорошо для Qt-шников не обязательно хорошо для остальных C++ников.

Ну а коль уж Boost-оводы начали делать ryppl, то хотелось бы, чтобы он подошел не только Boost-оводам. Но и всем остальным C++никам, которые не хотят или не могут использовать Boost, или же ведут свои проекты совсем по другим правилам, чем Boost. А у меня сложилось впечатление, что этого-то и не будет. Пока все похоже на bjam.

PS. Чувствую себя обязанным ответить на вопрос “А самому слабо?” Честно скажу – слабо. Я пытался изобрети такой велосипед. Но на его воплощение в жизнь не было ресурсов. Оказалось проще воспользоваться средствами Subversion, о чем я рассказал когда-то в статье. С тех пор именно этим способом мы и пользуемся. Даже сторонние проекты в репозитории укладываем и стараемся адаптировать их к нашей системе сборки (ACE, POCO, PCRE, Crypto++, libcurl и пр.). Но все это не работает, когда приходится публиковать SObjectizer и сопутствующие ему библиотеки. Пока мы мало их публикуем и эта проблема не сильно меня волнует. Но теперь появляются ресурсы для дальнейшего развития SObjectizer и проблема вновь оказывается актуальной. Нужно что-то искать или делать. Может быть, будем что-то делать. Но это уже не только от меня зависит.