О блоге

Более двадцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

Так же я пишу о жизни вообще и о нескольких своих увлечениях: о фотографии (включая публикацию своих фотографий, некоторые есть и на ZeissImages), о спорте, особенно о дартсе, и, совсем коротко, о кино.

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

Вы художник? Бармен или музыкант? Или, может быть, коллекционер? Плотник или столяр? Кузнец или слесарь? Владеете маленьким магазинчиком или управляете большим производством? Реставрируете старинные часы или просто починяете примус? Всю жизнь занимаетесь своим любимым делом и хотели бы иметь фото на память?

Предлагаю сделать портрет в обстановке, связанной с вашей работой или увлечением. Абсолютно бесплатно. Очень уж мне нравится фотографировать людей в их естественной среде. Происходить это может так...

[prog.c++] Идея развития темы, начатой в статье "A declarative data-processing pipeline on top of actors? Why not?"

Давеча опубликовал на Хабре большую статью на английском языке "A declarative data-processing pipeline on top of actors? Why not?", в которой описал старый, но доведенный "до ума" пример make_pipeline из состава SObjectizer-а. К самой статье Григорий Демченко задал интересные вопросы в комментарии. Плюс на Reddit-е подсунули ссылку на (как мне показалось) недоделанную и полузаброшенную библиотеку RaftLib.

В общем, появилось навязчивое желание сделать продолжение этой темы.

По сути, тема создания пайплайнов (или графов в общем случае) обработки данных на C++ состоит из двух частей. Можно сказать, что есть верхняя и нижняя части проблемы.

Нижняя часть -- это то, как работа распределяется по рабочим контекстам. Т.е. это вопросы, связанные с тем, что из себя на самом деле представляют стадии пайплайна, как стадии привязываются к тем или иным рабочим нитям, как происходит передача информации между стадиями пайплайна. В принципе, нижнюю часть не обязательно делать с нуля самому. Можно использовать какой-то готовый инструмент. Скажем, Intel TBB. Или, как в моем случае, SObjectizer. С нижним уровнем связано несколько вопросов и мне хочется посмотреть, какие ответы на эти вопросы может (и может ли) предоставить SObjectizer.

Верхняя часть -- это тот DSL, который будет предоставляться пользователю для конструирования своих пайплайнов. И здесь есть ряд интересных и не исследованных для меня вопросов. Начиная от того, какую функциональность пользователь сможет получить в свои руки. И заканчивая тем, как выразить эту функциональность в C++ коде, дабы получить контроль за какими-то ошибками прямо в compile-time.

Пока что есть желание потратить несколько дней на эксперименты в этой области. Первые соображения о том, какие цели преследуются и какие мысли уже есть, изложены под катом. Кому интересно, милости прошу подключаться к обсуждению.

[prog.flame] Почему Rust может быть намного более пригоден для прикладного программирования, чем C++

Несколько запоздалое дополнение к двум постам с прошлой недели (раз, два). Хочу немного поговорить о неоднократно услышанном от Rust-евангелистов мнении, что Rust отлично подойдет не только для системного (и околосистемного) программирования, но и для прикладного.

Лично для меня не понятно, зачем тянуть в прикладное программирования языки без GC. Т.е. как вспомогательный инструмент для устранения узких мест и повышения производительности каких-то операций -- это понятно. Но как основной язык для всего приложения?

Прежде чем пойти дальше отпрыгнем в сторону и попробуем хоть как-то определить само понятие "прикладного программирования". По большому счету к прикладному программированию можно отнести все, что не касается системного и низкоуровневого программирования. Т.е. если код не решает каких-то специфических задач, интересных только программистам (ядро ОС, компилятор, линкер, MQ-шный брокер, сервер БД, утилита типа grep и т.д.) или не управляет каким-то оборудованием (вроде бортового ПО автомобиля или самолета), то это прикладное ПО. К сожалению, в этом случае в "прикладное ПО" попадает слишком большой спектр софта: скажем, от Microsoft Word или Adobe Lightroom до склепанного на коленке в Wordpress сайта-визитки. Но есть подозрение, что если попытаться конкретизировать термин "прикладное ПО", то возникнет ощущение насильственной подгонки условий под нужный результат. Посему более жестких условий накладывать не будем.

Итак, есть тезис о том, что Rust отлично подойдет для прикладного программирования...

[prog.sadness] Похоже, разработчики D решили закопать свой язык еще глубже

За последние месяцы я несколько подзадолбался как с разработкой на C++, так и с общением с придерживающимися разных взглядов C++никами, так и c продвижением наших C++ных разработок в сильно сегментированном C++ сообществе. Настолько, что стал уже мечтать о том, чтобы закрыть ближайшие "долги" по работам вокруг SObjectizer-а и устроить себе отдых от C++. Пропрограммировать что-то для души на чем-то более современном и удобном, чем C++.

На D.

А вот сегодня на HackerNews увидел ссылку на статью Вальтера Брайта (это автор D и его основной разработчик) про возможность добавления в D механизмов Ownership и Borrowing из Rust-а. Смысл статьи в том, что изначально Брайт думал, что borrow checker из Rust в D не запихнуть, но потом у него появились идеи, которые Брайту кажутся вполне себе реализуемыми. Поэтому Брайт начинает активно копать в этом направлении.

Ну что тут сказать. Один раз Брайт и Ко уже основательно поднасрали своему детищу. Это кода в 2008-го году, всего через полгода после официального релиза D 1.000 было заявлено, что начинаются работы над D2, который будет несовместим с D1. Сказано это было в тот момент, когда вокруг D не было никакой существенной экосистемы и количество нормальных библиотек для D измерялось, в лучшем случае, несколькими десятками.

Да, D2 получился гораздо более интересным и мощным языком, чем D1. Но лет через шесть после D 1.000. И, по факту, он появился уже тогда, когда окно возможностей для D захлопнулось благодаря C++11/14, Go, хайпу вокруг Rust-а. Так что D отличный язык для небольших проектов маленьких команд и энтузиастов. Но широкого применения ему, увы, уже не светит.

А тут в D хотят впихнуть еще одну мегафичу. И мне непонятно нахрена это нужно делать :(

Ну вот основная фишка в том, что это продвинутый язык с GC для нейтива. И как раз GC дает D те преимущества, о которых C++никам остается только мечтать, если на C++ пытаться разрабатывать что-то более-менее высокоуровневое.

Казалось бы: ну и развивайте D как язык с GC. У вас и в этой области работы будет выше крыши. Зачем вы еще куда-то лезете? Делаете GC отключаемым, придумываете какой-то betterC... Теперь вот еще и borrow checker в язык затаскиваете...

Ну вот явно "чувство меры" -- это не то, что свойственно разработчикам D.

Пичалька, что еще скажешь. Вот так и разрушаются мечты :(

[prog.flame] Пятничное дополнение ко вчерашнему посту. Снова про Rust

По поводу тяпницы и в качестве продолжения вчерашнего поста решил поделиться с читателями блога вопросом, на который у меня пока нет ответа:

А что будет, когда на Rust-е начнут программировать разработчики уровня сильно ниже среднего?

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

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

Так, на примере C++ видно, что есть языки, которые не прощают тупость разработчика.

Что-то похоже, полагаю, можно сказать и про Scala. Там, правда, последствия не такие катастрофические, как в C++, но несопровождабельный код, который проще переписать, чем понять, на Scala пишется легко.

Тогда как языки Java и Go зарекомендовали себя просто отлично с этой стороны. Высказывание "на Java можно посадить толпу индусов" -- это уже давно не фигура речи, а многократно подтвержденный успешный менеджерский опыт. Причем "индус" здесь не национальность, а уровень квалификации.

Так вот, мне не понятно, что будет происходить с разработкой на C++, когда туда придут персонажи, вроде RussianFellow с RSDN-а. Чтобы было понятно, о чем речь, вот замечательный образчик. И если кто-то думает, что подобные персонажи -- это редкость, то смею вас разуверить. Не редкость.

В свое время, когда C++ был настоящим мейнстримом, таковых было множество. Со временем, к счастью, изрядная их часть перешла в Java и C#. Но часть, к сожалению, еще осталась. И, если Rust продолжит набирать популярность, они неизбежно туда подтянутся.

Имхо, вариант Haskell-я, когда посредственности в этот язык просто не идут, здесь не прокатит. Т.к. Haskell в силу разных причин никогда и не мог претендовать на широкое использование. В отличии от Rust-а.

Так что будет интересно посмотреть на то, что произойдет. Выпрямит ли Rust-овский компилятор растущие из жопы руки? Или этот самый компилятор наеб*т посредством расставления unsafe в коде, ибо дедлайны, нужно фичи в прод выкатывать, а не ублажать borrow checker.

[prog.flame] Предлагаю новый слоган для D: "Fast as C++, safe as Rust, easy as Java"

Намедни в LOR-овском срачике сформулировал свое впечатление от наблюдений за тем, кто, как и откуда переходит на Rust. На мой взгляд, в Rust идут люди, которые всю жизнь программировали на безопасных языках с виртуальной машиной. Ну там Java, Python, Ruby, JavaScript, Erlang, Clojure и т.д. А так же C++ники, которые толком C++ не освоили, а уж о том, что такое современный C++, вообще не имеют никакого понятия.

А потом довелось прочитать серию постов небезызвестного своими "плачами Ярославны" НикиТонского: "С высоты", "С высоты-2" и "С высоты-3". И еще более утвердился в том, что мои наблюдения более-менее коррелируют с действительностью.