пятница, 7 октября 2011 г.

[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-а.

11 комментариев:

Andrey Valyaev комментирует...

Ну на мой взгляд boost::test всетаки получше, чем Google test.

Сейчас для общего развития решил побаловаться с последним. Многих вещей там нету.

Нет например возможности отключить вывод успешных результатов выполнения теста.

Нет проверки на исключения (вероятно из за общей нелюбви google к исключениям).

Нет сравнения коллекций. Хотя в бусте оно тоже не идеально :)

Я вообще пользуюсь бустом, активный бустоюзер. С большими фреймворками надо быть конечно аккуратным. В своем проекте подсели на boost::serialize.. и все.. продолжаем есть кактусы... изменить пока невозможно ничего (совместимость с предыдущими версиями нужна).

Но утилитарные библиотеки исключительно полезны. :) Кроме того не вызывают такого стойкого привыкания, как большие фреймворки.

eao197 комментирует...

@Андрей Валяев:

>Но утилитарные библиотеки исключительно полезны. :) Кроме того не вызывают такого стойкого привыкания, как большие фреймворки.

Золотые слова! Очень точно сформулировано.

Rustam комментирует...

@Евгений
Насчет аналога JDK/.NET Framework для C++ сейчас микрософт похоже возвращается к С++, он бы вполне потянул. Недавно смотрел краем глаза альфу Win 8 и соответственно WinRT они уже все что нужно для этого (ABI, метаинформацию) перетянули из C#/NET в С++.

имя комментирует...

по п. 1, 2, 3 почти согласен -- за исключением boost.spirit -- его делать в языке было бы глупо, но то, что языка может не хватать для его поддержки -- это да, да и вообще по-моему парсер-комбинаторы это совсем не сложно

по п.4 куча замечаний

а) занадто = ?

б) это в говновинде допустим да, один архив, а у нас в дебиане 15 разных пакетов libboost*-dev (+ столько же не-dev пакетов, + отдельно jam, + еще разное)

на тему "какую версию брать" -- естественно, ту, которая идет в том дистре, который будет стабильным на время эксплуатации проги (наверно это можно делать и под виндой)

имя комментирует...

> Именно "модным", когда шаблоны применяются и к месту, и не к месту.

гы-гы

в с++ просто нет другого способа вычислить что-то в компайл-тайм (кроме шаблонов), а вычислять очень хочется и даже видимо нужно

"вычислить" тут в широком смысле -- например, твой недавний пост ("[prog.c++] Попробовал было C++11 для проблемки работы с опциональными значениями"), где тебе хотелось полиморфные лямбды, можно рассматривать как желание чтобы компилятор вычислил тип аргумента этой самой лямбды

eao197 комментирует...

@имя:

>а) занадто = ?

Через чур, слишком много.

У нас есть практика помещать в репозиторий 3rd-party библиотеки, которые используются в проектах. С такими вещами, как ACE, POCO, pcre, crypto++ эти вещи проходят. А вот с большими библиотеками вроде Boost или Qt уже нет. Что добавляет геморроя.

>б) это в говновинде допустим да, один архив, а у нас в дебиане 15 разных пакетов libboost*-dev (+ столько же не-dev пакетов, + отдельно jam, + еще разное)

Я, конечно, рад за Debian, но Debian это даже далеко не весь Linux.

eao197 комментирует...

@имя:

>где тебе хотелось полиморфные лямбды, можно рассматривать как желание чтобы компилятор вычислил тип аргумента этой самой лямбды

Вот именно, хотелось, но раз нет, то расхотелось. А некоторым, наоборот, это только азарта добавляет.

Miroslav комментирует...

есть один плюс кучкования библиотек. legal issues. Если на каждую либу будет отдельная лицензия то в корпорации с 1+bn revenue вы элементарно зашибетесь сношаться с legal по каждой лицензии. А буст он у всех на слуху

eao197 комментирует...

@Miroslav:

Да, для компаний с большими оборотами это может быть весомым аргументом. Наверное.

jazzer комментирует...

> Бустовские регулярные выражения лучше, чем PCRE?

Вообще-то лучше, так как больше поддерживают - несколько вариантов POSIX, синтаксис perl/sed, плюс есть даже вкусности для MFC, если кому надо.
http://www.boost.org/doc/libs/1_47_0/libs/regex/doc/html/boost_regex/ref/syntax_option_type/syntax_option_type_synopsis.html

Ну и плюс она все-таки С++ и Boost, т.е. интерфейсно совместима с итераторами и прочим STL.

eao197 комментирует...

@jazzer:

>Вообще-то лучше, так как больше поддерживают - несколько вариантов POSIX, синтаксис perl/sed, плюс есть даже вкусности для MFC, если кому надо.

Да, если кому-то потребуются данные возможности, то это бует огромный плюс в пользу Boost.Regex.