[prog.flame] Наткнулся на свой старый список претензий к Boost

Будучи некоторое время активным RSDN-ером написал там множество комментариев. Через которые ко мне в блог и сейчас попадают люди. Интересно бывает перечитывать то, что писал N лет назад. Вот как в данном случае.

Так уж получилось, что на Boost я смотрел года с 2001-го, но в серьезную эксплуатацию никогда не брал. Самое большое – это использование Boost.Test в нескольких мелких проектах (откуда он теперь выпиливается). Почему так произошло – тема долгого разговора. Вкратце список того, что мне не нравится(лось) в Boost-е я описал вот в этом комментарии. Позволю себе его процитировать, поскольку прошло уже больше трех лет, а список до сих пор актуален:

1. Реализация boost-а исключительно сложна. Ну т.е., когда все идет гладко и в исходники библиотеки заглядывать не нужно, то нет проблем. Но, тем не менее, здесь есть два момента, которые мне не нравятся:
— ни в одном другом языке (а мне приходилось лазить в библиотеки Ruby, Eiffel, D, немного Java) мне не приходилось видеть такой разительной разницы в сложности реализации библиотек и прикладных приложений. По мне, это некий признак того, что что-то где-то не так;
— всегда приятно иметь увереность в том, что твоих знаний хватает для того, чтобы при необходимости разобраться в деталях с происходящим в твоем приложении. По крайней мере у меня не было проблем с тем, чтобы залезть во внутренности MFC, Qt, FOX, ACE. В случае с boost ситуация обратная -- тот же boost.variant сразу же отбивает желание понять, как же он устроен.

2. Некоторые вещи в boost-е направлены на предоставление разработчику инструментов, которые, по хорошему, должны были быть в языке. Пример: boost.lambda. Да и, насколько я понимаю, boost.mpl так же использует различные трюки для того, чтобы обойти существующие недостатки языка. По-моему мнению, это не нормально. Должен развиваться язык, а недостатки языка не должны скрываться за библиотеками, сложность реализации которых слишком высока (см.предыдущий пункт).

3. Некоторые библиотеки boost-а (тот же boost.lambda, а так же boost.spirit), на мой взгляд, являются примерами того, что не нужно делать. При этом у меня складывается впечатление, что наличие подобных вещей создает у C++программистов "головокружение от успехов" -- т.е. программирование на шаблонах в C++ становится модным направлением. Именно "модным", когда шаблоны применяются и к месту, и не к месту.

4. Boost велик. Слишком велик. 22Mb в tar.bz2 версии 1.35 -- это занадто. Имхо, для C++ поздно создавать одну большую стандартную библиотеку. Можно понять Sun с JDK и MS с .NET Framework, которые держат большие штаты программистов, поддерживающих JDK/.NET Framework. А кто будет поддерживать OpenSource-ный boost? Что произойдет, если кому-то из авторов включенных в boost библиотек надоест сопровождать и развивать свое творение? Или как разработчикам каких-то библиотек выпускать новые релизы вне графика выхода версий самого boost-а?

Далее, включение библиотеки в boost осуществляется по результатам review, в которых, обычно, едва набирается несколько десятков отзывов. Т.е. заявляется что-нибудь типа boost.egg и что? Находятся несколько ценителей прекрасного, которые присылают положительные review и egg в boost-е. И что из того, ценность буста повысилась? В то же время вне буста есть, например, crypto++, botan или cryptlib, которыми пользуются сотни, если не тысячи программистов, но которые никаким боком к boost-у не относятся.

Еще один момент. Библиотеки, которые являются альтернативными boost-овским, они что, уже второго сорта? Бустовская сериализация -- она лучше, чем s11n? Бустовские регулярные выражения лучше, чем PCRE? Бустовские юнит-тесты намного лучше CppUnit? Не получится ли так, что когда разработчику понадобиться что-то, то он просто возмет реализацию из boost-а даже не глядя на альтернативы? Т.е. выбор будет строится не на возможностях, а на репутации. Как бы в результате boost не стал монополистом, который своей массой будет просто давить конкурентов.

Отмечу так же, что время не стоит на месте. И Boost, при сохранении вышеперечисленных недостатков, все-таки за прошедшее время обзавелся рядом полезных библиотек, которых мне в нем не хватало изначально (в первую очередь Boost.Asio). Так что если бы сейчас встал вопрос брать или не брать Boost для совсем нового проекта, я бы сделал новую попытку оценки уместности использования Boost-а.