[prog.sadness] Buckaroo: заменить одно ненужно на другое :(

Наглядный пример того, как выбросить одно ненужно и заменить его другим ненужно: https://github.com/LoopPerfect/buckaroo/releases/tag/v2.0.0

Есть такая система сборки для C++ проектов: Buck.
И к ней система управления зависимостями Buckaroo.
Кажется, от чуваков из Facebook.

Так вот, раньше эта система управлениями зависимостями была написана на Java. Соответственно, хочешь использовать для своих C++ проектов Buckaroo -- ставь себе JRE.

А теперь это все добро взяли и переписали на чем?

На .NET.

Инсталлятор этой прелести для Windows весит 35Mb, для Linux-а и Mac-а чуть больше 65Mb. Для FreeBSD готового инсталлятора нет.

Что в этом всем печальнее всего?

А то, что по своей задумке и Buck, и особенно Buckaroo, наиболее интересные и вменяемые из всего, что сейчас развивается в мире C++ инструментария, включая CMake, build2, meson, vcpkg, Conan, Hunter и пр. А уж Bockaroo, так это чуть ли не доведенный до своего логического завершения MxxRu::externals. Все ИМХО, конечно же.

[prog.thoughts] Rust дал compiler-driven development широким массам

Вчера, в результате обсуждения в Facebook-е двух вариантов одного и того же кода на Rust-е довелось таки воспользоваться Rust-овским playground-ом и набросать на Rust-е пару-тройку собственных вариантов.

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

Стало понятно, что имеют в виду растоманы, когда говорят, что компилятор им помогает писать код.

Ну реально. В Rust-е, с одной стороны, драконовские ограничения и жесткий контроль за программистом. С другой совершенно криптографический синтаксис, более-менее сложные конструкции приходится разбирать очень внимательно, обращая внимание на каждый символ. Так что хрен поймешь, что именно ты пишешь и что на это скажет компилятор. А потом приходит этот самый компилятор и говорит: вот тут ты херню написал, перепиши вот так, а вот этот символ, в принципе, есть, но я тебе не дам его использовать, пока ты вот такой use не напишешь.

Поэтому не остается ничего другого, как делать то, что тебе говорит компилятор. А потом оно раз! И работает.

Ну понятно, почему у людей крышу-то сносит. Особенно у тех, кто на Rust с динамики, вроде JS, Python или Ruby приходит.

Имхо, здесь есть сильная аналогия с тем, какую серьезную роль в разработке софта в середине-конце 1990-х годов произвели IDE. Сперва Delphi, затем IDE для Java (при этом IDE для C++, имхо, в те времена, да и потом, сильно недотягивали до Java-аналогов, что обуславливалось особенностями языка). Можно сказать, что в 1990-х сформировался IDE-driven development, который пышным цветом расцвел в 2000-х. Да и сейчас, наверное, цветет и пахнет.

А вот Rust, похоже, делает доступным для широких масс такую штуку, как compiler-driven development.

Что, как мне кажется, неизбежно скажет свое веское слово в индустрии софтостроения.

Но знаете, что по-прежнему удивляет меня сильнее всего касательно Rust-а? Это то, что не смотря на всю крутотень Rust-а и толпы писающих кипятком фанатов для Rust-а еще не появилось ни одного сколько-нибудь заметного GUI-фреймворка. За 3.5 года после выхода стабильного Rust 1.0. За три с половиной, мать его за ногу, года.

Да в 1990-е на первых версиях C++ GUI-фреймворки в одно рыло клепались только в путь и росли как грибы после дождя. Первая версия Qt была сделана за четыре года. В 1990-е, на древнем C++. Маленькой командой. Без GitHub-а. Только вдумайтесь. Да и сейчас люди делают вещи вроде ImGui и Nana. Для C++, не для Rust-а. Загадка, однако.

[life.cinema] Очередной кинообзор (2019/01)

Подошло время очередного кинообзора. В этот раз, в основном, всякий шлак. Ничего выдающегося, даже средних фильмов раз-два и обчелся.

Звезда родилась (A Star Is Born, 2018). Сюжет немного предсказуем. Актриса из Леди Гага никакая. Диалоги неестественные и тупые. Бредли Купер хорош. И музыкальное сопровождение немного спасает ситуацию.

Эшер (Asher, 2018). Проходной и не очень интересный фильм. Однако, приятно увидеть, что Ричард Дрейфусс, Рон Перлман и Фамке Янссен в отличной для своих лет форме.

Исчезновение (The Vanishing, 2018). Вот тут сильно двойственные чувства. С одной стороны, хорошая история и отличное техническое воплощение в фильме (работа оператора, имхо, заслуживает отдельных похвал). Но, с другой стороны, неудачный подбор актеров. С трудом верится в то, что брутальный герой Батлера в конце фильма превратится в истеричку.

Репродукция (Replicas, 2017). Хорошая задумка. И несколько звездных актеров в главных ролях. Но катастрофически плохие спецэффекты.

Близко (Close, 2019). Трейлер, к сожалению, оказался интереснее, чем сам фильм. Да еще и вобрал в себя практически весь имевшийся в наличии экшн.

Вдовы (Widows, 2018). Собрали крутых актеров, а вышла какая-то непонятная и тягомотная хрень с мутным финалом.

Хроники хищных городов (Mortal Engines, 2018). Редкая муть и бредятина. Даже отличный видеоряд не спасает.

Робин Гуд: Начало (Robin Hood, 2018). Это какой-то ППЦ. В процессе просмотра разбил себе лицо фейспалами.

[disillusion] Google+ фсе :(

Google сегодня окончательно порадовал: в период с 4-го февраля по 2-е апреля будет уничтожено все, что связано с предназначенным для индивидуальных пользователей Google+. В том числе исчезнут из Blogger-а созданные через G+ комментарии. Собственно, уже исчезли, потому, что в настройках Blogger-а использование G+ комментариев я сегодня отключил.

Приношу свои извинения читателям, т.к. в комментариях содержалась масса интересного.

Google показал волевое решение настоящих, больших бизнесменов. Если уж ходить, так по крупному. Раз сказали в морг, значит в морг. Оставить существующий контент хотя бы в режиме read-only? Актитесь, половинчатые решения -- это для сопляков. Сделать платные аккаунты и брать с пользователей арендную плату за поддержку их контента в G+? Да кому вы нужны со своей жалкой десяткой долларов в год, когда компания ведет многомиллиардный бизнес.

[work.pain] О наболевшем: github or not github?

Простите, я опять на тему SObjectizer-а, хотя постараюсь в этом году в блоге про него писать пореже.

Пора уже вплотную заняться работой над версией 5.6, но я все еще не определился с тем, где держать основной репозиторий с его исходными текстами. Понятно, что это будет не SourceForge. Но вот github, bitlab, bitbucket или что-то еще?

Рассудок подсказывает, что раз де-факто стандартом является github, то нужно делать на github.

Но у этого выбора есть два фатальных недостатка: git и github :)

Так уж получилось, что мне не нравится ни первое, ни второе. Понятное дело, что все это субъективно, что могу пользоваться и тем, и другим (собственно, вынужденно и пользуюсь). Но мне с hg и bitbucket-ом гораздо проще и удобнее. Ну и в работе же должно быть хоть какое-то удовольствие, а какое тут удовольствие, когда в придачу к C++ еще и git с github-ом? ;)

Поэтому пока не могу сделать выбор между просто git+github-ом и hg+bitbucket+зеркало на github-е. Больше склоняюсь к hg+bitbucket+зеркало.

Но есть подозрение, что это неправильный выбор... :(

[prog.flame] Возраст и умение программировать. Или становятся ли программисты с возрастом лучше?

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

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

"Научиться программировать" -- это значит научиться писать работающий код, который делает то, что требуется. Не падает. Не имеет внутри себя никому не понятных кусков неизвестного происхождения. Нормально оформлен. С более-менее вменяемыми комментариями внутри.

[prog.c++] "Modern" Dining Philosophers in C++ with Actors and CSP (part 2)

In the previous post we discussed several implementations of "dining philosophers problems" based on Actor Model. In this post I will try to tell about some implementations based on ideas from CSP. Forks, philosophers and waiter will be represented as std::thread and will communicate each other via CSP-channels only.

Source code can be found in the same repository.

CSP-based Implementations

Like in the previous post we will start from implementation of Dijkstra's solution, then we will go to simple solution with putting the first fork if an attempt to take the second fork fails (without arbiter), and then we will go to solution with waiter/arbiter. It means that we will see the same solutions like in previous post, but reimplemented without Actors. Moreover the same set of messages (e.g. take_t, taken_t, busy_t, put_t) from Actor-based implementations will be reused "as is" in CSP-based implementations.

[prog.c++] "Modern" Dining Philosophers in C++ with Actors and CSP (part 1)

Some time ago a reference to an interesting article "Modern dining philosophers" was published on resources like Reddit and HackerNews. The article discusses several implementations of well-known "dining philosophers problem". All those solutions were built using task-based approach. I think the article is worth reading. Therefore, if you have not read it yet, I recommend read the article. Especially if your impressions of C++ are based on C++03 or more earlier versions of C++.

However there was something that hampered me during the reading and studying proposed solutions.

I think it was usage of task-based parallelism. There are too many tasks created and scheduled thru various executors/serializers and it's hard to understand how those tasks are related one to another, in which order they are executed and on which context.

Anyway the task-based parallelism is not the single approach to be used to solve concurrent programming problems. There are different approaches and I wanted to investigate how a solution of "dining philosophers problem" can looks like if Actors and CSP models will be used.

To do that I implemented some solutions of "dining philosopher problem" with Actors and CSP models. Source code can be found in this repository. In this post you will find description of Actors-based implementation. In the next part I will tell about CSP-based implementations.