суббота, 3 апреля 2010 г.

[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 и проблема вновь оказывается актуальной. Нужно что-то искать или делать. Может быть, будем что-то делать. Но это уже не только от меня зависит.

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

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

наверное напишу пост. может в понедельник :)
на примерную тему "хоть мы и застряли с плюсами надолго вперед, нет ни одной причины рекламировать эту платформу компромиссов".

night beast комментирует...

Угу. Текущее положение с++ не может не огорчать.

Мне кажется, ситуацию может исправить скриптовый язык легко встраиваемый в плюсы с хорошим набором библиотек.

Пока думаю в этом направлении...

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

>Мне кажется, ситуацию может исправить скриптовый язык легко встраиваемый в плюсы с хорошим набором библиотек.

За счет чего?

night beast комментирует...

>За счет чего?

можно будет добавить сборщик мусора, стандартную гуи и др. библиотеки.

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

если удастся реализовать описание грамматики - то будет поддержка ДСЛ.

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

2night beast:
>Мне кажется, ситуацию может исправить скриптовый язык легко встраиваемый в плюсы с хорошим набором библиотек.

не может :) Я к счастью начинал со связки с++ и Lua5.

2Евгений:
лень страшная штука - повторять очевидное достаточно неинтересно. На вопрос чего мне не хватает в плюсах ответ правда не столь обычен - "перформанса".

Так что имхо нужно приветствовать любые попытки создать новые system языки. И день когда мы сможем сказать "Le Roi est mort, vive le Roi!" (фр) не будет грустным.

night beast комментирует...

Rubanets Myroslav>Так что имхо нужно приветствовать любые попытки создать новые system языки.

дык назвал бы такие.

пока народ все больше фунциональные/декларативные изобретает...

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

>дык назвал бы такие

Пока разве что Go от Google может на такое звание претендовать.

Есть еще lisaac. Но последним двум в гонке за Go, имхо, ничего не светит.

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

Что-то комментарий обрезался. Кроме lisaac я еще Zimbu упоминал.

Можно было бы еще понянуть D, но после стольких лет долгостроя я от него уже ничего не жду. Даже если автор выпустит D 2.0, следом пойдет разработка какого-нибудь D 3.0, настолько хорошего, что D 2.0 никому не будет нужен (как сейчас D 1.0).

Так что пока надежда на Go :-/

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

>можно будет добавить сборщик мусора, стандартную гуи и др. библиотеки.

Имхо, сейчас все это происходит в обратном направлении -- люди программируют на Python/Ruby/Tcl+Tk, а части своих приложений пишут на C/C++. В будущем к этому добавится еще и JavaScript в Chromium OS.

Имхо, скриптовые языки могут помочь C++ только в очень-очень узких областях.

night beast комментирует...

Евгений Охотников>Пока разве что Go от Google может на такое звание претендовать.

даже не знаю, может ли язык со сборкой мусора быть системным...

я так понимаю вопрос с контролем памяти в геймдеве стоит не на последнем месте

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

>даже не знаю, может ли язык со сборкой мусора быть системным...

Если язык позволяет GC отключить, то вполне. На Eiffel, насколько я знаю, даже встраиваемые системы разрабатывают.

Другое дело, что язык должен позволять масштабирование. Т.е. чтобы на нем легко можно было и планировщик ОС написать, и какую-нибудь утилиту (типа grep) для этой ОС. В первом случе GC не нужен, во втором -- был бы вполне полезен.

>я так понимаю вопрос с контролем памяти в геймдеве стоит не на последнем месте

Про геймдев не знаю, но этот вопрос много где не на последнем месте. В системах реального времени, в CAD-ах, даже в server-side задачах, где сейчас Java рулит, и то за памятью следить приходится. А то бывают случаи, что очень Ынтырпрайзные Java-приложения даже на заявленных разработчиком как оптимальные 16Gb памяти даже не заводятся.

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

Кстати, забыл еще один язык, который компилируется в нативный код: Vala

Никогда на него пристально не смотрел. Но он упорно развивается.

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

Скриптовые языки да вещь страшная, начинаешь с мелкого безобидного встраивания чтобы разрулить конфиги и заканчиваешь тем что пишешь например на питоне а С++ остается только в виде модулей для того же питона :)

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

2Rustam: есть такое дело.