Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Неделя началась с нескольких постов про Conan. Логично было бы ее таким же образом и завершить. Тем более, что пару наших проектов как-то под Conan опакетить удалось.
Итак, поделюсь своими ощущениями от знакомства с двумя менеджерами зависимостей для C++. Это vcpkg от Microsoft-а и Conan, который сейчас находится под крылом JFrog. При этом сам я не пользуюсь в своих проектах ни одним, ни другим. И исхожу из своего опыта создания и сопровождения пакетов для этих менеджеров.
А именно: есть ощущение, что Conan существует не для решения проблем разработчиков, а для привлечения клиентов к сервисам JFrog.
Возможно, я сильно не прав. Но вот на третий день попыток освоить и изучить Conan у меня пока именно такое ощущение. И подталкивают меня к этому три фактора.
Фактор первый. Происхождение и развитие Conan-а. Если правильно помню, то сперва был biicode. Который некие чуваки, кажется, из Испании, пытались позиционировать как сервис для управления зависимостями в C++. Причем сервис как бизнес. Тема вполне ожидаемо не взлетела. Что не удивительно в наш век бесплатного OpenSource-инструментария. Далее biicode приказал долго жить, а на его руинах начал развиваться проект Conan. Который, имхо, ждала бы судьба biicode, если бы команду разработчиков Conan-а не взяла на борт JFrog.
Фактор второй. Conan пытается угодить всем. Могу ошибаться, но изначально Conan, как и его предтеча, biicode, был заточен под CMake. Но потом в Conan-е от завязки исключительно на CMake отошли и сейчас в документации к Conan говорится, что Conan перпендикулярен системам сборки. Мол, задача Conan-а только подтащить к вам на машину нужные вам артефакты, а дальше вы любитесь с этими артефактами любым удобным для вас способом. Хоть с CMake, хоть с Autotools, хоть еще с чем-нибудь.
Что лично мне непонятно от слова совсем: какой толк в "централизованном" репозитории зависимостей, если там перемешаны зависимости с разными системами сборки. Скажем, у меня в проекте Waf, а из Conan-а я беру три артифакта, первый из которых завязан на CMake, второй на GNU Makefiles, а третий на SCons. И что с этим винигретом мне потом делать? В этом плане подход vcpkg, hunter-а, build2 и buckaroo лично мне представляется гораздо более логичным и практичным.
Зато "всеядность" Conan-а на 100% оправдывается, если целью является привлечение как можно большего числа пользователей к JFrog Artifactory. Чтобы затем часть из них стала платными пользователями.
Ведь мир C++ неоднороден, CMake пока любим и используем не всеми. Значит, если Conan будет поддерживать только CMake (как тот же vcpkg), то круг потенциальных клиентов резко сужается. Поэтому нужно сделать Conan привлекательным и для тех, кто CMake пока еще не пользуется. Какая в итоге будет выгода пользователям Conan-а -- это другой вопрос, главный вопрос -- это сколько пользователей прибегут на сервисы JFrog-а.
Фактор третий. Есть ощущение, что проект развивается, что называется "без руля и без ветрил". Т.е. JFrog взял команду Conan-а на борт, а дальше дал им карт бланш и простую цель: сделайте так, чтобы ваш Conan приводил C++ников на наши сервисы. Как вы это будете делать никого ниипет не интересует, важен результат. Вот команда и творит хер знает что.
Лично мне сложно объяснить качество и понятность документации как-то иначе. Они, наверняка, сами не ставили себя на место обычного пользователя, который по этой документации должен был бы их инструмент освоить. Такое ощущение, что смотрели просто на объем: как-то мало, давайте еще текста вольем. Влили. Лучше или хуже стало? Да похеру, главное, что стало больше, солиднее.
Я бы своим коллегам/подчиненным за такого качества документацию руки бы давно поотбивал. И заставил бы переделывать до тех пор, пока бы документацию не привели к надлежащему состоянию. Тут же, наверное, жесткого лидера с четким видением цели нет.
PS. В общем, продолжаю погружаться в чан с говном в Conan. Раз уж взялся за то, чтобы сделать пакеты для Conan, нужно довести до логического завершения. Либо таки сделать. Либо обосновать раз и навсегда, почему пакеты Conan-а вместе с Conan-ом стройными рядами идут в /dev/null. И потом, наверное, напишу свое нелицеприятное мнение о vcpkg и Conan-е.
Старался внимательно штудировать мануал глава за главой. Но вот на этом коротком фрагменте наступил локальный ступор. Я процитирую содержимое, дабы каждый мог попытаться прочитать и попробовать понять, что же здесь написано:
The previous create approach using test_package subfolder, is not strictly necessary, though very strongly recommended. If we didn’t want to use the test_package functionality, we could just write our recipe ourselves or use the conan new command without the -t. command line argument.
$ mkdir mypkg && cd mypkg $ conan new Hello/0.1This will create just the conanfile.py recipe file. Now we can create our package:
$ conan create . demo/testingThis is equivalent to:
$ conan export . demo/testing $ conan install Hello/0.1@demo/testing --build=Hello
Команды conan new и conan create делают разные вещи? Вы серьезно?
Что означает "Hello/0.1" в conan new понять несложно. Но блин, что должно означать demo/testing в команде conan create?
Команда conan create эквивалентна команде conan export, о которой еще не было и речи, плюс еще и conan install, которая, как следует из ранее прочитанного, должна откуда-то загрузить пакет. Блин, по какой такой логике create получается эквивалентом export+install?
Ну хорошо, пусть сумрачный гений авторов Conan-а дошел до того, что create=export+install. Но, блин, куда делается export? И откуда делается install? Ведь Conan с каким-то сервером должен общаться. С каким именно, почему про это пока еще вообще ничего не было сказано?
Говорил раньше неоднократно, повторю еще раз: для разработки библиотек нужны другие навыки, нежели для разработки прикладного кода. Вовсе не обязательно хороший программист-прикладник сможет спроектировать и реализовать удобную в применении библиотеку (и наоборот). Для меня это уже давно очевидные вещи.
Ровно тоже самое можно сказать и о разработке другого инструментария для программистов. Бл*дь, да другие навыки нужны для этого, другой взгляд на мир, другой способ мышления.
Не верите? Ну посмотрите на тот же самый git Conan. Его явно делали люди, которым не нужно разрабатывать инструментарий. Вот вообще. Это еще со времен biicode было видно. И уж тем более, нельзя этим людям документацию писать.
Я, конечно же, этот факинг Conan победю, как победюл в минимально необходимой степени CMake. Но, ей богу, если кто сейчас активнее всего закапывает C++, так это авторы подобных CMake-ов, Conan-ов и их благодарные пользователи.
И да, я понимаю возражения на тему "лучше из того, что есть". Но не понимаю, когда откровенное говно нужно жрать с радостным причмокиванием, утешая себя тем, что другое еще хуже.
PS. А авторов альтернативных решений, вроде build2 или Buckaroo, после более плотного знакомства с Conan-ом, стал уважать еще больше. Хоть и думаю, что build2 не взлетит из-за своей оригинальности, а Buckaroo из-за привязки к Java для своей работы.
У меня тут очередная попытка опакетить наши разработки для Conan-а. И, есть подозрение, что будет как с поддержкой CMake: сделать-то сделаем, но проблеваться по дороге придется изрядно...
Я, в общем-то, человек весьма средних интеллектуальных способностей. И, с годами, ситуация лучше не становится, скорее напротив (склероз, маразм и пр.). Но, блин, по ходу чтения документации по Conan-у ощущаю себя совсем уж тупым. Ну реально, читаешь, читаешь, одну главу из документации прошел, вроде все слова понял, вторую прошел, опять же все слова понятные. Но не то, что целостной картины в голове нет, так еще и с приблизительной картинкой не складывается.
Вот, скажем, сперва говорится про conan install и пример приводится с его использованием. Потом этот пример усложняется каким-то количеством специфических для install опций. При этом я не понимаю зачем эти опции вообще и к чему они были упомянуты в данном примере. Потом происходит переход к описанию conanfile.txt. И вместо того, чтобы дать хотя бы общее представление о том, что за conanfile.txt, для чего он нужен, когда используется, где и когда его conan ищет, что в принципе в conanfile.txt находится, сразу идет перечисление секций из conanfile.txt с рассказом о назначении каждой из них.
Т.е. общее впечатление от conan-овской документации: куча разрозненных частных деталей из которых читатель сам должен сформировать общую картину.
Уж не знаю, может это сейчас так принято. Или это вообще особенность западной системы образования. Или может это у авторов документации к conan-у такой альтернат взгляд на мир. Но я как-то привык к другому: сначала общее, затем частное. Т.е., как по мне, сначала в общем должна быть описана решаемая задача. Затем, опять же в общем, крупными мазками, должен быть описан принцип решения. Затем на простом примере, без ухода в частности, показывается само решение. Затем еще несколько примеров, которые показывают решение в более сложных ситуациях. А уже затем подробный справочный материал.
Неужели это так сложно?
Попутно у меня просьба: если вы встретитесь с подобными косяками в нашей документации к SObjectizer/so_5_extra и RESTinio, то не сочтите за труд, дайте нам знать. Обязательно постараемся исправить.
Просмотрел только что свежую статью на Хабре про Rust: Приемы обобщенного в Rust: как мы переводили Exonum с Iron на actix-web.
Похоже, я могу понять, почему к Rust-у такое внимание. И от кого это внимание исходит. Если всю жизнь программировал на Python, Ruby, JavaScript или даже Go, то в один прекрасный момент динамическая типизация и невысокая скорость исполнения может основательно подзадолбать.
Захочется чего-нибудь нативного, очень шустрого, мощного и выразительного. Но что выбрать? Старый и замшелый C++, про который столько страшилок рассказывают, и в котором экосистема застряла в 1990-х? Вряд ли.
Может быть Ada? Или какой-нибудь Eiffel? Сильно вряд ли. Про них мало кто знает. Eiffel вообще платный (но есть GPL-ная версия) и где он сейчас непонятно. Ada вроде как жива и развивается, но модным и молодежным этот язык точно назвать нельзя. Да и у сегодняшней молодежи попытка изучить Ada может вызвать стойкий рвотный рефлекс, особенно если всю жизнь программировал на чем-то вроде JavaScript-а.
Можно еще и D. Но его популярность и распространенность колеблется где-то возле статпогрешности.
Вот и остается Rust. Который был построен на базе всех популярных страшилок и хайпов 2000-х годов. ФП во все поля, ООП сосет, безопасное многопоточное программирование (на самом деле нет), отсутствие и GC и утечек памяти, иммутабельность by default, ...
Так что почему на Rust переходят люди с Python/Ruby/JS и даже с C# или Java, мне вполне понятно.
Только вот глядя на более-менее практичные примеры кода на Rust я не понимаю двух вещей:
Во-первых, какой смысл сейчас разрабатывать прикладное ПО на Rust-е или C++? Ну т.е. такое, которое решает проблемы конечных пользователей. Зачем писать на Rust или C++ очередной HTTP-сервер, MQ-брокер, СУБД или компилятор я могу понять. Не понятно, зачем на Rust-е делать что-то прикладное, типа взяли данные отсюда, проверили, преобразовали, сохранили в БД, отдали вот сюда.
Ну вот, действительно, какой смысл? Порог входа в язык высокий. Код, который будет разрабатываться, особой читабельностью отличаться не будет. Посадить на проект какого-то "индуса" заместо выбывшего "индуса" не получится. Поскольку язык безопасный, с кучей проверок к run-time, по производительности он будет побыстрее, наверное, Java и .NET-а, но не на порядки. Да и вряд ли в разы быстрее, скорее на десяток-другой процентов, да и то вопрос. Экосистема еще только формируется и наполняется библиотеками...
Во-вторых, зачем C++ника пересаживаться на Rust? Не, я понимаю, что ФП во все поля, ванильные трайты вместо утиных шаблонов, синтаксические макросы, компилятор бьет по рукам, cargo и все дела... Но блин, в Rust-овом коде будет все тоже самое, что и в C++ном: лес из абстракций и обобщенных конструкций, построенных каким-то сумрачным гением. Так что в красивой обертке матерый C++ник обнаружит все тот же говнокод, наполненный трехэтажными шаблонами, с которым ему и так приходится иметь дело постоянно. И еще непонятно, какой из них ближе к криптограммам ;)
В общем, в очередной раз можно пожалеть, что D не взлетел. Сперва он появился слишком рано, когда еще не было надобности в шустром, но безопасном нативном языке с GC. Всех вполне устраивали Java с JVM и C# с .NET. Плюс к тому, затеяли переход от D1 к D2 и профукали момент, когда выстрелил Go в контейнерах, где нужна и скорость и отсутствие тяжелых ран-таймов.
Да и сейчас авторы D, как мне кажется, продолжают думать, что основные конкуренты для них -- это C и C++ (ну, может быть еще и Rust). Тогда как на мой взгляд, основные конкуренты для D -- это Go и грядущие Kotlin/Native, Scala/Native, Crystal, Nim и т.д. И вот эта неправильная оценка ситуации приведет к очередному профуканому шансу. Вместо betterC нужно в D другими вещами заниматься, имхо.
Жаль D. На данный момент это единственный язык, на котором хочется что-нибудь написать, когда C++ в очередной раз подзадалбывает.