Поскольку я с недавних пор устроился на работу, то простыни временно закончились. Тем не менее, каждый раз при работе с сишным кодом снова и снова всплывает мысль «блин, как же здесь не фатает крестов». Но в остальном сишки мне более чем хватает, мне не нужны геттеры-сеттеры, классы-интерфейсы под single responsibility, и прочая мура. Пару источников вдохновения:

https://google.github.io/styleguide/cppguide.html
https://yosefk.com/c fqa/

Итак, назовите от трех до пяти фич крестов, которые бы вы взяли с собой на необитаемый остров Си. Можно несуществующие или из будущих стандартов. А я чуть позже назову те, которые взял бы я. (назвал)

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

Итоги по состоянию на 24.12.2021 22:00 (MSK): https://pastebin.com/bxamaGDY

Специальный выпуск для linux.org.ru.

Когда я был юношей, то они мне говорили «вырастешь — поумнеешь». Я вырос, но не поумнел. Но иногда я жалею, что не знал тогда того, что знаю сейчас — так и хочется написать тому юноше письмо из будущего, что я и намерен импровизировать в виде треда на LOR.

Среди взрослых людей есть довольно ярко выраженная дихотомия в способе принятия решений: люди, которые знают решение, и люди, которые это решение всегда способны найти за достаточно продолжительное время; те, кто ни за что не признают ошибку, и те, кто ошибаются на регулярной основе даже если уже знают решение; те, чей максимальный интервал принятия решений составляет «между двумя глотками смузи» (ведь «моё время дорого стоит»), и те, кто тщательно выстраивает цельную картину проблемы и неспешно обсасывают ее со всех сторон.

Поскольку первых людей сильно больше, чем вторых (соответственно спросу), то массовый программист, как правило, оценивается по тому, как много решений он может выдать между двумя глотками смузи. Индустрии нужно зарабатывать деньги на массовом конвеерном фуфле, индустрии не нужны оригинальные решения. Как решить большую сложную задачу на подобном конвеере? Взять больше смузи и хлебать чаще, посадить дополнительных смузихлебов на тестирование этого дела. Самое страшное — когда в подобном духе начинает работать Boeing, и самолеты начинают падать. Можно радоваться тому, что упал не ваш самолет, а можно подумать о том, что завтра ваше авто с вами за рулем может внезапно оказаться не ваше, потому что его хакнет 7-летний китайский ребенок, и единственная реальная защита — это тот факт, что Илон Маск платит всем денеги только чтобы уязвимостями в автомобилях и инфраструктуре не пользовались злоумышленники.

Мне вспоминается старый-престарый эпизод моей жизни, как я еще будучи школьником выиграл олимпиаду по информатике. Задача была на поиск кратчайшего пути (пардон, точного условия уже не помню, это было давно и неправда). Грамотный программист быстро выдаст вам «правильное» решение O(N log N) по алгоритму Дейкстры. Но поскольку на тот момент я не знал алгоритма Дейкстры и не был грамотным программистом, то вместо «правильного» решения выдал асимптотику O(N), заэксплуатировав некоторые особенности конкретных условий той задачи.

И второй эпизод, современный. Меня выбесило одно из недавних моих собеседований: некая контора дала мне тестовую задачку, являющуюся также одной из фундаментальных задач, решаемых их продуктом. Мне просто забыли сказать, что «правильный» метод должен быть O(N^3), и я случайно потратил целый день на разработку метода O(N^2), который оказался настолько неожиданным для «сеньоров», что им понадобилась целая неделя для анализа моего решения на 500 строчек (inb4: фу-фу, лапшемес), а на собеседование со мной собрали всю верхушку — на минуту у меня сложилось ощущение, будто меня собеседуют в гугл, а не в местную помойку. Я не удивлюсь, если вся их шарашка уже работает над интеграцией моего метода, и в скором времени получит премию, мол «наш отдел провел тщательные исследования предметной области...», а тебе, мартыха, хрен с маслом. И это собравшееся начальство на собеседовании было серьезно намерено развести меня на решение еще одной важной для их помойки задачки. Большая часть их штата джуно-мидлов занимается обвязками-прокладками-интерфейсами-тестированием, короче говоря, теми задачами, под которые можно нанять горсть рабов с улицы хоть прям щас — но эти люди в жизни не смогут выдать оригинального решения, а только будут ждать команд сверху.

Вишенка на тортике — под конец мне дали задачку с литкода, которая была будто специально подобрана так, чтобы быстрое решение требовало от меня знание специфичных фич стандартной либы, которое я им изначально честно заявил как «слабое». Те функции выучиваются наизусть за пару дней, а аналитическое мышление развивается годами, но нет «ты слабоват, мы можем тебя взять, но на ЗП в два раза меньше». Вот так вот: «не подскажешь, как пройти к вокзалу?... А теперь встань раком и вези меня туда».

Что мы всё про меня да про меня. С точки зрения массовой индустрии Дуглас Крокфорд — посредственный программист, и в недавнем треде большое число отписавшихся доходчиво пояснило, почему это так. Да, подумаешь, он создал какой-то там JSON, на котором работает половина индустрии, а еще создал JSLint, который ведь оказался так себе и был вытеснен ESLint-ом, и вообще «я могу сделать лучше, просто оно мне не надо». Но печальная истина в том, что тысячи смузихлебов писали на JS безо всякого линта, и, я уверен, при возникновении онного долго противились новой технологии. Проходит время, и вот уже каждый школьник считает своим долгом задействовать ESLint и JSON, а пишет, естественно, на ES2015, добрая половина фич которого была реализована при непосредственном участии Крокфорда (кстати, мало кто знает, что Object.keys/Object.values еще в ES5 было внесено по инициативе Крокфорда) — но этот школьник понятия не имеет, откуда взялись «мои любимые технологии».

Я хочу подчеркнуть, что это не одиночный пример мнения отдельной макаки — это закономерность, которую заметил не только я, и не только эту. Такие люди, как Крокфорд, могут бесконечно выдавать оригинальные идеи, но как исполнитель они так-себе, у них вечно шило в попе, толкающее на приключения, потенциально грозящие сорвать сдачу проекта (которая назначена на вчера, как обычно). Я задумался: а кому могут быть в самом деле нужны такие люди? Да, в силиконовой долине можно себе пригреть местечко — по этому пути успешно прошелся Крокфорд. А что делать, если я не хочу развивать силиконовую долину? Я в молодости отказался ехать туда, и сейчас не особо горю желанием (но и не предлагают уже). Вот такое вот я капризное животное.

Более того, если допустить, что Крокфорд выдал некое супер-пупер классное решение для вашей фирмы, то возникает проблема — кто его будет поддерживать/развивать? А также так называемый Bus factor — что делать, если Крокфорда убьют Крокфорд уйдет? Типовой сеньор-помидор, посмотрев на код Крокфорда, выпучит глаза и закричит «ты где такое видел? Кто так делает? У тебя своя голова на плечах есть?».

Всё ли так безнадежно, и есть ли более-менее прикладные задачи, которые не сможет решить сеньор-принципал-архитектор даже в обнимку с цистерной смузи, даже выдавая по два заученных решения литкода в секунду? А может быть и есть. Например, быстрой инкрементальной Agile Scrum Kanban Fast-shipping Test Driven методикой постепенной разработки невозможно реализовать распределенную отказоустойчивую БД со строгой согласованностью данных. Отказоустойчивость — это бинарное свойство, БД либо отказоустойчива, либо нет. Не бывает почти отказоустойчивой приблизительно распределенной БД которая чуть ли не сохраняет все подтвержденные транзакции (привет разработчикам MongoDB). Ну то есть она в таком случае не отказоустойчива и не дает гарантий.

Даже Clickhouse можно почти сделать при достаточном стратегическом запасе смузи (только для единственного хоста), но яндекс так и не осилил аналога ZooKeeper (кластер ClickHouse работает через ZooKeeper), поскольку никакое количество костылей, инкрементально разработанных в Яндексе ранее, так и не смогли заменить одного грамотно продуманного решения. Что мы по итогу видим сейчас? Вся инфраструктура Яндекса стоит на ZooKeeper, найди возможность положить ZooKeeper — весь Яндекс встанет колом. Тот же Facebook тоже полагается на ZooKeeper (хоть и меньше, они там саги любят). В Amazon вообще всё печально, и я не поверю, что с любым количеством денег Amazon способен создать аналог ZooKeeper, поскольку я читал статьи их отдела по исследованию распределенных систем, и уровень там совершенно никакущий. Достоверно мне известна ровно одна контора, способная разрабатывать распределенные СУБД с гарантиями согласованности — это Google. Она разработала самое первое подобное решение, Google Chubby, близкой копией которого позже стал ZooKeeper.

Но вот в чем проблема — ZooKeeper уже есть, а значит «ты нам не нужен». Что же еще требует глубокого вдумчивого погружения и нестандартной находчивости? Похожие требования есть у многопоточных приложений. Еще подобного рода мышление нужно при тяжелой глубокой отладке софтины, на отладку которой систематически забивали, предпочитая спринты и быстрые релизы. Правда, с распространением защищенных сред выполенния, вроде JVM, CLR, JS, и Python, неустранимая потребность в отладке сильно снизилось, потому что в крайнем случае можно просто перезапустить контейнер или иметь запасные контейнеры сразу. (Еще есть UI/UX, но про мертвых либо хорошо, либо ничего).

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

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

Парадокс в том, что смузи-мастеры чуть ли не поголовно мечтают быть творцами. Какой смысл этого стремления? «Хорошо там, где нас нет»? «Полчаса побунтовал - и фатит»? Прежде чем окончательно и бесповоротно решить встать на этот путь, посмотрите на настоящих успешных творцов (не путать с клоунами вроде меня или Илона Маска). Такие люди не заработают заоблачных денег, их не расхватывают на рынке труда, им не так просто устроиться на обычную должность, а даже если устроятся — умрут со скуки, попутно занимаясь ремонтом того, что не ломалось, таким образом выведя из строя какой-нибудь старый добрый сервис на Cobol или MUMPS, написанный в 70-х годах «настоящими программистами, настоящими, не то что новое поколение».

Показательно, что работодатели идут навстречу этому стремлению, мол «пишешь конфиги для CI/CD? Ну ты же архитектор теперь». Аналитический склад ума нельзя поменять за месяц, его нельзя быстро приобрести или положить на полку на период отпуска. Wannabe-творец-на-выходные в лучшем создаст популярный клон существующего софта — даже не потому, что не способен ни на что другое, а потому, что понимает, что сообщество не примет ни одной значимой инновации серьезнее плагина к Emacs или очередных скрипт-костылей для сборки C++. Да и то, плагины к Emacs не нужны, поскольку уже есть настоящее проверенное решение в виде Vim и его аналогов.

И я не могу упрекать работодателей (как правильно заметил Kogrom по ссылке выше): им нужна взаимозаменяемость и предсказуемость, им нужно снижение рисков и издержек; им нужен посредственный сайт, который будет создавать иллюзию наличия этого сайта у компании — а больше и не нужно; заказчикам нужна иллюзия масштабирования и отказоустойчивости, с бессмысленными невыполнимыми требованиями к системы — выдайте ему микросервисную архитектуру со стоимостью и временем разработки в 3 раза больше грамотного монолита, также бонусом дайте ценные инструкции по масштабированию бигдата-серверов монги сверх 500 ГБ (на случай, если его бигдата размещается в кластере из айфонов). Можно упрекать разве что себя (мне — себя, а вам — себя, не меня). Например, много лет назад я имел возможность выбрать семью и карьеру, но я выбрал то, что выбрал — не иметь власти, но знать всё и ничего одновременно. В этом есть свой кайф и неудобство одновременно.

По следам треда: Python Shared Objects

Поскольку в прошлом треде все рискнувшие пройти по ссылке заснули на половине статьи, то я решил написать статью в 3 раза короче про совсем общие принципы, лишь отдаленно относящиеся к PSO:

https://habr.com/en/post/587750/ — Многозадачность и многопоточность — распространенные заблуждения и недопонимания

Начал плотно мониторить рынок труда
Макака ищет работу, C, Python, JS, либо челендж в опенсорсе на C++
и у меня обострилось довольно странная догадка, которая была и раньше, но сейчас прям очень режет глаз. А именно: откуда сейчас происходит такое странное искажение спроса на спецов в IT? Каждая третья-четвертая вакансия — блокчейны. Или просто очередные старпаты на реакте с микросервисами на ноде или Go. Ну вы же не хотите мне сказать, что получаемый продукт кому-то даст хотя бы доллар прибыли? Потому что я не поверю.

Второй интересный факт, который мозолит глаз — это требования в специализации на штатовском рынке намного выше. Работая в очень-очень узкой нише в штатах можно по прежнему иметь большой рыночек, чуть ли не плана «специалист по async/await в JavaScript» — и все уже к этому привыкли. То есть, фактически в вакансиях это проявляется в виде экзотики в разделе «hard skills», названия которой я первый раз в жизни вижу. Эта закономерность имеется и в СНГ, но в штатах она достигла каких-то фантастических масштабов. Грубо говоря, от соискателя будет требоваться три года опыта разработки на каком-нибудь фреймворке, который два года назад релизнулся. А вот надо было сразу с бета-версий осваивать его, тогда был бы востребованным спецом.

Пока что цепочка видится такая: ФРС и банки генерят деньги, деньги самыми разными путями попадают к «инвесторам» (что-то близкое к понятию «инвестор в МММ»), инвесторов окучивают аккуратно одетые мальчики и девочки с поставленной речью, выдающими базворды через слово, что-то про «проверенные решения», «перспективные платежные средства», «занять место на растущем рынке», «мотивированная команда, жаждущая постоянного роста своей квалификации», и так далее. Раньше для того, чтобы доказать, что «эти слова не пусты», садились имитаторы программиста в опенспейс офис. Даже если они не профессиональные имитаторы — все равно будут исполняющими обязанности, потому что в опенспейсе эффективный кодинг невозможен в принципе. Как сейчас организаторы пузырей убеждают инвесторов отдать деньги — понятия не имею, предлагайте ваши варианты.

Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет? (комментарий)

Я в данный момент наблюдаю стартапы только для отмывания денег или для игр инвесторов в финансовые пирамиды.

Но самая интересная моя догадка касается того, что вектор целей этих пузырей и даже не совсем пузырей косвенно управляются забавными механизмами. Как то банальный кредитный рейтинг, который диктует очень простую вещь: если твои партнеры являются российской фирмой, то рейтинг ты получишь низкий, и кредиты под свой пузырь ты получишь с большим процентом. Сей инсайт позволил мне понять странный наблюденный мной феномен, а именно — в компании все программисты сидят в россии/СНГ, но почему-то офис находится в штатах/бриташке/гонконге. При том, что он там никому не нужен и никакие заказчики туда не приходят, тем более в короновирусную эпоху. Почему об этом так мало рассказывают? В интернетах мало людей, которых хотя бы просто интересуют вопросы бизнеса с прямой работой на забугорных заказчиков?

PS: поднял архивы с другого компа и нашел сочные материалы с http://labor-union.wikia.com/ (оригинальный сайт удален):
Работающая бедность в РФ
Lifehacks
Лайфхаки для выживания в РФ

Вот такой контент я бы читал в интернетах днями и начами. Жалко, что к создателю сайта (keinkeinkein) в Воронеж пришли правильные люди, и вежливо попросили удалить под ноль все материалы.

inb4: при чем тут это к линю и опенсорсу? Это очень глупый вопрос, потому что в 2021 весь ваш опенсорс находится в рабстве забугорных корпораций, ваш GPL софт используют в коммерческих целях, а модифицированные сорцы никто отдавать обратно не собирается. Потому что SaaS, тотальная централизация и прекращение разработки оффлайнового софта. Когда я еще в 2008 году вкатывался в опенсорс, я бы ни за что не догадался, что опенсорс станет таким.

10 лет в разработке, из опыта — GUI и веб-фронтэнд, UX, но не графический дизайн, СУБД, опыт разработки больших распределенных и многопоточных систем (си, паскаль), животное хорошо знакомо со внутренностями CPython, но бэк и машинное обучение на нем не писало. Когда-то разрабатывало контроллеры и аналоговую электронику, но нынче это никому не нужно, особенно на удаленке. Любит наукоемкие сферы, в частности математику, физику, химию.

Уверенный письменный английский, менее уверенный, но всё же разговорный английский.

Мой код вы можете заценить тут: https://github.com/byko3y/python-shared-objects

Зряплатные ожидания $4000-6000 за фултайм, но на очень сочные проекты возможны скидки. С радостью рассмотрю предложения part-time.

Бесплатно (или почти бесплатно) напишу фичу или исправлю годами висящий баг в более-менее известном опенсорс проекте на C++, если это теоретически выполнимо за несколько недель. Просьба не предлагать монстров, компилирующихся полдня, вроде Google Chrome. В крайнем случае Firefox, это верхняя граница.

Поскольку релиз пре-альфо-альфы моего проекта вызвал шквальный интерес, то почему бы мне не запостить результаты своих успехов на LOR.

https://github.com/byko3y/python-shared-objects - репушка

https://habr.com/en/post/585320/ - статья-обзор-бенчи (ахтунг, english).

https://www.reddit.com/r/Python/comments/qfdj8m/pso_easy_concurrency_with_pyt... — душный тред на reddit (тоже инглиш, внезапно)

Меня больше всего удивила не негативная реакция, нет, а тот факт, что мне даже никто не ответил в списках рассылки бидона. При том, что чел, который недавно просто выкинул GIL из питона (просто выкинул, почему бы и нет) и выложил свое творение, словил кучу ответов. Ну то есть ответы плана «откуда вас таких рожают? С 1999 года уже который раз выкидывают GIL, но ни к чему это не приводит». ХЗ, может центральные разработчики просто заняты очень важным обсуждением нового синтаксиса для ленивых параметров по умолчанию в PEP 671, и в поте лица пытаются выбрать между символом «=:» и «=>», но никак не получается. Люди работают, а я их тут отвлекаю.

Я давно выдвигал теорию, что разработка софта скатилась в говно. Современный кодер не разрабатывает новый софт — современный кодер только клеет существующий.

Интервал 20 лет выбран не случайно — последние прорывные P2P технологии массово создавались 20 лет назад (Chord, Kademlia, eDonkey, BitTorent).

Начну со своего варианта ответа: Bitcoin. Подавляющее большинство блокчейнов слизаны с битка почти один в один, кое-кто даже развил идею, но качественного скачка не смог сделать никто. К сожалению, больше ничего не вспоминается.

Сразу замечу, что «продавать настроенную инфраструктуру», оно же «облака» — это, мягко говоря, не новое решение. NoSQL СУБД — это шаг назад, с NoSQL БД начинались. Последние новые технологии искуственного интелекта появились в 90-х.

Техлид+ПМ (комментарий)

system-root заинтриговал, но ответов не дал. Лично в моих глазах это переводчик с офисно-рыночного языка на программистский, который не занимается техническими деталями, но расставляет приоритеты для конечных фич и сроков их реализации, а также разводит заказчика на даллары. Но мне кажется, что я действительно что-то упускаю.

Хороший манагер — что это за зверь, и чем он отличается от плохого манагера?

Прошлая серия:
Откуда растут ноги ненависти к php?

Я не знаю, есть ли где-то на планете второй такой поехавший, которому реально интересно понять, как инструменты разработки развивались и приобретали успех у простых смертных мартышек. Ну вот нравится мне собирать информацию, на которой невозможно заработать денег. Я пока что не встречал ни одного блогера, который подобный анализ произвел для веб-разработки в целом — а мне интересно.

Итак, что нового я откопал: WordPress, который изначально был CMS для создания бложиков в два клика, внезапно развился в целую платформу, и вот уже на нем клепают интернет-магазины — хотя затея эта, на мой взгляд, и провальная, ведь нагрузку WP абсолютно не держит, а ломают сайты на WP из-за уязвимостей плагинов на раз-два, только и успевай накатывать патчи в надежде, что сегодня взломают не тебя.

Давайте подумаем: а что же у нас до WordPress было инструментом для создания бложиков? Ну? Ну?

Идем далее:
https://www.djangoproject.com/weblog/2005/nov/16/firstrelease/ - Django 0.90
https://github.com/django/django/tree/ce079538c66d826be5f0c4260ab4405b7abcbed7 — примерное состояние сорцов перед релизом 0.90

Что представляла собой джанга на момент 2005 года? Платформа для создания CMS некоего регионального новостного сайта (история разработки) и блевотных бложиков, по сути стоящая на трех китах:

— шаблонизатор;
— ORM, поставляющий содержимое из баз данных в шаблонизатор и засовывающих их обратно в базу из форм;
— алгоритмы авторизации и админка для изменения содержимого бложика.

Вы уже снова узнали, что аналогичный инструмент до боли стар и хорошо нам всем знаком. Забавно, что в дичайшую нечитаемую лапшу джангу превратило уже сообщество — оригинальные сорцы имели зачатки лапши только в иерархии полей модели, где создатели почему-то решили логику отображения-контроллера полей в шаблоне (генерации HTML и валидации введенных полей, core/formfields.py) унаследовать от классов с алгоритмами доступа к БД (core/meta.py), в остальном это было простецкое наследование от template.Node (управляющие структуры шаблона) и meta.Model (абстрактной бессмысленной сущности для агрегации полей аля «таблица»), и даже было немало классов без базового класса. Итого 12 тысяч строк с комментами тогда, а сейчас в Django 300+ тысяч строк питона.

Вы уже поняли логику успеха? Делаем инструмент для создания говнобложиков в два клика — миллионы индусов кидаются писать на нем свои говноблоги — на рынке оказывается огромное число кодеров толка «я не умею в PHP, но могу сделать вам сайт на WordPress» или «питон? не, не умею; когда-то слышал про него, но толком не пытался изучить, я пока только на Django научился сайты писать».

С другой стороны — почему бы не позволить людям писать в два клика вебсайты на Go? Или на лиспе. Где там наш Пол Грэм со своим конструктором сайтов на лиспе? В конце-концов, я и другие программисты пишем программы именно для того, чтобы простой человек мог без напряга воспользоваться нашим софтом.

Интересно было бы услышать вашу аналитику о делах недавнего прошлого: Ruby on Rails? Symphony? Я вот пока не понял, почему Laravel нынче стал лидером среди других PHP фреймворков.

Давайте немножко побеседуем про новомодные low consistency poor availability системы, снискавшие популярность в последнее время.

Попытка заблокировать сервисы Google обернулась сбоем в работе систем Центробанка РФ (комментарий)
«интернет вояками планировался как отказоустойчивая сеть, но вебмакаки умудрились сделать из нее сильно связанный фарш, поздравляю, вы сломали чугунный шар»

Как мы все знаем, интернет разрабатывался, как отказоустойчивая система, которая функционирует до последнего узла. Как мы знаем, коммерсанту частенько есть что скрывать и не хочется зависеть от благого расположения Васи Пупкина, даже если Васю Пупкина зовут SAP, Oracle, IBM, или Microsoft. Так почему же люди покупают Office 365 и Dynamics 365 при том, что есть полностью оффлайн альтернативы? Если вы размещаетесь в России или Китае, покупаете продукт 365, а потом Роскомнадзоры или сам MS блокирует вам облако — вы остаетесь полностью в дерьме. Кто это покупает и что ими движет? Кто завязывает свой бизнес на Dynamics 365? Или на облачный Битрикс? Я не понимаю, предлагайте ваши вариант.

«Облака», в плане «привязан цепью к интернет-серверу», не новы, Самая отстойная копирастическая контора, Ubisoft, в свое время отличилась тем, что их uPlay при кратковременной потере интернет-соединения вываливал вас из ОФФЛАЙН игры. По сути, многие софтоделы ориентируются на облако просто для того, чтобы иметь больше возможностей струсить денег с потребителя. И даже несмотря на то, что теоретически возможность миграции предоставляет много кто — фактически эта миграция выйдет вам в копеечку и вы семь раз подумаете, прежде чем мигрировать.

Ладно, допустим, просто допустим, что таким образом некий Ерохин экономит время и деньги на установке и настройке оффлайнового софта, на организации своего сервера, к которому можно было бы получить доступ даже с мабилы (не спрашивайте меня, зачем с мобилы — я не понимаю). Давайте даже на минуту пофантазируем, что мы — технически грамотный разработчик, который желает приобщиться к потоку денег. Естественно, при этом мы желаем клиенту только добра. Железо дешевое, хостинг дешевый — давайте же сделаем бэк нашего продукта на большом-прибольшом числе серверов, да еще и в разных геолокациях, чтобы у нашего любимого клиента было меньше проблем со связью.

Но раскидать серваки по планете — это одно, а заставить их работать после этого вместе — это совершенно другого уровня задача. Как она обычно решается? Через базы данных, в число которых входят брокеры сообщений, вроде RabbitMQ. И здесь мы вступаем на тропу лютого треша, потому что проектировать и реализовывать распределенные системы и БД в частности на планете умеет человек двадцать, и скорее всего они работают не у вас, но спрос на них сильно больше, потому что другие «умники» уже давно витают в облаках и своих спецов не отдадут.

«Готовые решения всё порешают» — скажете вы? А знаете ли вы, что ZooKeeper — единственная распределенная СУБД, гарантирующая строгую согласованность данных при отказах? А знаете ли вы, что, даже несмотря на выдающиеся достижения, в ZooKeeper операция синхронизированного чтения нелинеаризуема, а потому часть вашего кластера может сидеть с тухлыми данными, не зная об этом? А знаете ли вы, что полностью исправный кластер Riak при интенсивных конфликтах обновлений теряет более половины этих обновлений на полностью исправном кластере? Даже при самых строгих настройках согласованности данных. Причем, таким ужасным Riak делать было не обязательно — на самом деле это спонсоры Riak и попросили сделать умолчательную конфигурацию такой ужасной.

Но как же так, мы же все давно знаем про Paxos, который еще триста лет назад позволял достигнуть консенсуса в распределенной системе с отказами узлов — почему же до сих пор в школе не преподают основы построения распределенных систем? Если мы возьмем тот же ZooKeeper, то мы увидим, что в случае отказа лидера кластеру требуется НЕСКОЛЬКО СЕКУНД на возобновление работы — это настоящая стоимость честного распределенного консенсуса, который у ZooKeeper при выборах лидера похож на Paxos. Для решения проблем дичайше медленного консенсуса и возникла идея выбора «эталонного сервера», лидера, мнение которого безоговорочно принимает весь кластер без затрат на спор между узлами.

Правда, этот подход все равно не сработает при достаточно частых сбоях с частыми потерями лидера. Более того, система на консенсусе полностью выйдет из строя при потере более половины узлов. Вы можете заметить, что согласно теореме говна-или-мочи достижима либо согласованность данных, либо доступность системы, либо в системе недопустимы отказы. Давайте пожертвует согласованностью ради доступности! Но беда мамкиных бигдатовцев заключается в том, что средняя система по больнице не обладает высокой доступностью и не обладает хорошими гарантиями согласованности. То есть, высокодоступная система готова работать 24/7 до первого отказа сервера или потери соединения с интернетом. Почему пришлось так делать? Потому что иначе будет высокая задержка ответа и/или большая нагрузка на каналы.

Возьмем среднюю бигдату в вакууме — GitLab:
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/
Пока бигдатовцы боролись со спамером, они умудрились ушатать данные пользователей за целый день, и потом еще день восстанавливали ее из бэкапа. Тест на доступность успешно провален. Это еще ладно — а я слышал истории о том, что у сервиса бэкапы-то есть, но восстанавливать их придется несколько недель. Так что отказ на день — это еще вполне себе High Availability по нынешним меркам.

Да, какой-нибудь яндекс регулярно устраивает тесты отказоустойчивости, вырубая датацентр. Однако, мне страшно подумать, что случится, если у яндекса внезапно вырубится более половины датацентров и отвалятся службы, опирающиеся на консенсус. Ихний кластер ClickHouse опирается в своей работе на (сюрприз) ZooKeeper. Отказ обезьянника (а он полностью отрубается при отказе половины узлов) приводит к переходу кластера в read-only. Сколько там еще служб отправится в read-only — мне было бы интересно узнать (давайте попросим роскомнадзор для проверки поблокировать датацентры яндекса).

Заметьте, что на серверах обычно SSD/HDD стоят в зеркале — чтобы, боже упаси, 24/7 сервис не умер из-за отказа одного из жестких дисков. И этому процессу впаривания говна нет конца, даже если завтра сделают устройства для передачи информации со сверхсветовой скоростью на спутанных квантовых состояниях и карманные петабайтные носители со средним периодом отказа в 2000 лет, то желающих хранить данные на локалхосте станет еще меньше и облачные сервисы будут выходить из строя по таймаутам при недопустимо больших задержках канала связи в 1 мс.

Потому, как ни странно, самое надежное «облако» — это то, которое стоит у вас в локальной сетке. Мало того, что облака могут в любой момент отвалиться — они еще и более несводобны, чем проприетарная софтина на локалхосте, как и предупреждал нас Штолман:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

Я вот что не пойму: я один это вижу? Ваши данные, которые не ваши, ваши приложения, которая не ваши, ваши высоконадежные высокодоступные SaaS, которые остаются таковыми до первого отказа (и тоже, в общем-то, не ваши). Или вы тут все зарабатываете на SaaS (как Шома), потому особо не вскрываете эту тему? А со мной не поделились — у-у-у, подлецы.

PS: сам участвовал в разработке SaaS, но поставляли также и коробку для внутреннего сервера.

Выделил в отдельный тред обсуждение консольного клиента GitHub:

www.linux.org.ru/forum/talks/16499288?cid=16499698

Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал? Мне не устраивают сказки про «DVCS намного лучше централизированной репы», потому что большинство пользователей Git/GitHub используют его как централизированный репозиторий и сам GitHub развивался именно как централизированный хостинг.

Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab. Причем, именно в таком ключе продолжает развивать эту инициативу Microsoft, ныне владеющий GitHub: дополнительные инструменты в виде виртуальной файловой системы для online-only работы с центральным сервером, при этом сохранение совместимости с консольными клиентом GitHub-а.

По мотивам:

Вкатиться в наукоемкое программирование/моделирование (комментарий)
https://www.joelonsoftware.com/2002/05/06/five-worlds/

Джоэл вкинул важный тезис: если подход не работает в этих ваших опенсорсах, то это не значит, что он не работает вообще. Якобы есть какие-то проекты и команды, где программирование парами со взаиморевью кода и со 100% покрытием кода позволяет ускорять и упрощать разработку каких-то там проектов. Я сталкивался с таким подходом только в лице какого-то блоггера-коуча в рунете, который беспощадно тёр любые комментарии с отличным от его мнением. Судя по всему, движуха до сих пор жива — значит, она кому-то нужна? Соответственно, у меня вопрос:

Кто-то хотя бы слышал про такие проекты, где принципы экстримального программирования дали что-то, помимо экспоненциального роста со временем затрат на разработку и поддержку внутреннего корпоративного софта?

Возможно ли это сделать челу с в.о. по фуфлыжной специальности автоматизатора заводов? Заводов серьезных в округе толком нет, регалий особенных у меня нету тоже. С математикой-физикой-химией дружу, но никогда не видел в них толка, потому что в коммерции нынче востребовано только «купи-продай, разницу себе».

Я прагматичный человек, потому меня не привлекают мозгодробильная математика аля крипта или квантовые вычисления, которые еще никогда не одной реакции не предсказали. В грантораспильных организациях мне ловить нечего, потому что регалий у меня нет и я плохо подхожу для оправдания того, почему никаких результатов нет, а все деньги уже потрачены. Расчеты механических прочностей/ динамики/гидро/газодинамики — это прикольно, но без сверки с испытательными образцами ничего не стоит. Устраиваться в какой-то НИИ или завод за еду работать 8 часов от звонка до звонка уже очень не хочется.

Есть ли какие-то шансы у простого смертного продвинуться в этом направлении, или в СНГ всё глухо? Да, есть вариант сделать собственную лабораторию, но это не так-то просто по финансам, да и перспективы с ней неясные.

Недавно мне в копилку подкинули замечательный сайт:

https://phpthewrongway.com/

Отличительной особенностью сайта является то, что он предоставляет хорошие ссылки для дальнейшего углубления.

Я уже давно почитываю обсуждения на hackernews и WikiWikiWeb (например, http://wiki.c2.com/?XmlIsTooComplex ). К сожалению в них существует та же проблема, что и в интернете в целом: очень много мусора, то есть, шаблонных бездумно копируемых «собственных» точек зрения, подтвержденных богатым опытом из пяти угробленных «не мной» за последний год проектов.

Как человеку, который поддерживал годами проекты, над которыми сам работал, и который понимает, чего стоят многие книжные знания, мне, тем не менее, совсем не достаточно своего опыта и интересен аналогичный опыт других людей. Например, когда Дан Абрамов писал-писал годами компоненты в реакте на миксинах, чтобы потом в итоге заявить Mixins Considered Harmful и Mixins Are Dead. Long Live Composition. Ну и из классики — мой любимый Дейкстра, конечно.

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

Как некоторые из вас слышали, я уже некоторое время пытаюсь укусить локти и думаю, с какой стороны бы подступиться к нише CRM+ERP.

Существуют ли по-настоящему удобные системы совместного планирования и работы?
Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

Последний тред
Поиски вдохновения и единомышленников
я создал в том числе потому что почувствовал, что исчерпал запас новой информации, но хронически не знаю, откуда его пополнить. Удивительно, но почему-то интернет скромно замалчивает эту сферу. К сожалению, имеющиеся у меня сведения позволяют сделать вывод: готовые CRM/ERP системы не нужны. Если клиенту нужно руками вводить информацию о клиенте, обновлять его статус и писать комментарии — это не автоматизированная связь с клиентами. Это тупо ручная система организации, поскольку незначительно отличается от создания бумажных карточек клиента от руки или на печатной машинке. «Оповещения» — это те карточки, которые коллега передал мне в отдельную стопочку.

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

«По большей части ручного» — потому что все таки есть некоторые элементы автоматизации. Например, слежение за времяпрепровождением сотрудников — пусть ввод и весь ручной, но сбор статистики о времени активности все-таки полуавтоматический. Или генерация PDF файлика по введенным оператором значениям — это тоже полуавтоматика. Конечно, когда я вижу, как оператор три минуты пялится в экран, чтобы распечатать мне чек по уже выполеннному заказу — это не автоматизированный процесс, а полуавтоматизированный. Так и хочется сказать «недоавтоматизированный». Но давайте здесь я еще больше не соглашусь сам с собой, потому что никому на самом деле не нужен PDF файл. Особенно сейчас, когда бизнес постепенно мигрирует в электронную нишу, и максимум что нужно печатать — это чек, хотя бы потому, что так требует законодательство. А вот если на печатаемом документе еще и нужно ставить подпись/печать — это уже лишняя и бессмысленная ручная работа оператора.

Самое труднодостижимое и самое полезное в автоматизации — когда оператор перестает замечать систему. Когда руководитель вводит в компьютер «сделать трактор», а система находит нужных свободных сотрудников, ставит им задачи со сроками, резервирует детали, заготовки, инструмент на складах и заказывает недостающее. Это то, для чего изначально вообще задумывалось ERP. К сожалению, в реальном мире возникают несостыковки, брак, работник заболел/его сбил автобус, технология изменилась, склад замело снегом. Если довести эти факторы до абсурда, то получится система планирования в рамках страны, в которой форс мажоров настолько много, что планирование со сколь бы то ни было приемлимой точностью просто невозможно.

Проблемы автоматизации, как правило, находится на стыке некоторых механизмов, например: поступил звонок от клиента — передать клиента его привычному менеджеру или первому свободному, если привычный занят. Здесь есть две точки сопряжения: распознание номера телефона и определение факта доступности менеджера. Если их не проработать, то от автоматизации не остается и следа. И если у нас в системе есть N программ/механизмов, то задача их сопряжения имеет сложность O(N^2), то есть, сопрягать N механизмов с N(-1) механизмами. Отсюда вывод: плодить программы значительно проще, чем потом лепить из них единую автоматизированную систему.

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

А что же тогда продают упомянутые мегаплан, битрикс, ну и в конце-концов SAP с Oracle? Как правило, они продают число модулей, табличек, вкладочек, рюшечек на страничках. Это свойство, которое точно противоположно автоматизированности системы — незаметности модулей, которые должен видеть только админ и которые просто тихо незаметно работают. Таким образом, когда вы внедряете эти готовые программы на предприятии, вы прежде всего ВНЕДРЯЕТЕ ПРОБЛЕМУ, а потом уже ищете ей решение. Так и вижу лозунги «Битрикс 24 — лучшая проблема для вашего бизнеса», «BMW е$@^!я с SAP», «SAP — ready when you are» (вольный перевод: «SAP — будет готова как только вы подготовитесь к ней»). Последнее, между прочим, настоящий рекламный слоган, который иронично отражает сложность внедрения SAP на предприятии — а у SAP накопился богатый опыт провалов внедрений.

Как сказал один мой знакомый, который когда-то занимался вместе со мной внедрением самопального ERP на местном заводе: «нужно не спрашивать у заказчика о том, какую проблему ему нужно решить, а приходя к заказчику нужно уже иметь решения проблем, про которые он до тебя не знал». Я много лет не мог понять этой фразы. Наконец, я её понял.

Но я, все-таки, подходил к вопросу со стороны «чему можно научиться у этих систем? Как можно сделать их лучше, можно ли улучшить интерфейс и реализацию, чтобы по итогу получить конкурентное преимущество и оттяпать у них рыночек». А парадокс решения в том, что чем тоньше ваша система, тем проще она поддается автоматизации. Чем проще ваша БД, тем удобнее её адаптировать под нужды бизнеса. По этой причине SAP является самой-присамой неудобной базой для автоматизации на рынке.

Специалист по UX, Голден Кришна, написал целую книгу на схожую тему «Хороший интерфейс — невидимый интерфейс». Один из ключевых тезисов книги — нынче модно лепить планшеты куда ни попадя, хотя они делают устройство не проще, а сложнее. Именно это делают мегаплан-битрикс-SAP-Oracle — удовлетворяют потребность налепить китайский планшет на ваш бизнес (на удивление, довольно популярную потребность), превратив хорошо налаженное и много лет работающее предприятие в сиамского близнеца с четырьмя ногами. Мол «ваш бизнес приобрел больше ног, и теперь может ходить в два раза эффективнее». В тему планшетов/смартфонов они вам скажут «зато у нас есть готовые мобильные версии, удобно вне офиса ткнуть в смартфон и посмотреть список дел и сообщений». Я с удивлением обнаружил более одного человека, который занимается планированием не на компьютере и не на смартфоне, а тупо в бумажной тетрадке. Потому что бумажную тетрадку можно носить с собой и пользовательский интерфейс у нее заметно удобнее смартфона. К тому же, тетрадка не разобьется при падении на асфальт.

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

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

Да-я-занимаюсь-онанизмом-thread

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

Когда-то такой платформой был ЖЖ и я относительно активно в нем участвовал. Да, вы можете сказать «заведи свой блог и собирай единомышленников в нем». Но проблема в том, что специфика моего поведения плохо подходит под формат блога, потому что людям нужен регулярный и ожидаемый контент, то есть, если человеку понравилась тема UI/UX в моем блоге, то он зайдет еще раз почитать про UI/UX. Но у меня кончились интересные идеи в этой нише и я вообще забыл про нее на полгода. А если ему внезапно в ленту начнут сыпаться посты про авиацию из моего блога, то он вообще отпишется от меня.

То есть, мне больше подходит роль «на подхвате у сообщества». Я внезапно заваливаюсь к анимешникам, вдохновленный единичной годнотой со смыслом, но очень быстро выясняется, что подавляющее большинство аниме — это низкопробное говно, а его поклонники — не самые мудрые люди. И в итоге короткое время поучаствовав в жизни сообщества я с чистой душой забываю про него навсегда. Примерно как я лет на 8-10 пропадал с LOR-а, настолько, что даже забыл пароль к старому аккаунту (по сути я уже пятизвездочник).

К сожалению, ЖЖ бесповоротно скатился в говно. Альтернативных сервисов не вижу. Ну то есть вижу. но они всё больше напоминают помойки, заваленные рекламными статьями и не подразумевающими обсуждения. Вроде сайта Y Combinator, который, помимо фактического состояния помойки из случайной и рекламной информации, имеет отвратительную функциональность комментирования, где ты пишешь комментарии непонятно кому даже не надеясь на ответ. Некоторое время мне посчастливилось сидеть на одном сайте с Пелевиным, который мне очень близок широтой и спецификой своих интересов, но с закрытием сайта связь пропала, а публичности он, как и я, не любит.

С простыми смертными мне разговаривать не о чем, поскольку миром они не интересуются, книжки не читают, хобби не имеют, им «лишь бы работа была», пиво в холодильнике, и хер стоял. Попа мира, где я нынче размещаюсь, обладает довольно скромным количеством интересных людей, поскольку онные поразъезжались строить карьеры в столицы. Иронично, что на местном городском портале самым интересным человечком оказался парниша, который живет в штатах. Я даже знаю вполне конкретные адреса оффлайн тусовок, но они чертовски далеко от меня.

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

По мотивам:

Подарите старый NetBeans 8 с поддержкой C++ (комментарий)

Мне интересно, кто как больше всего применяет и редакторы кода, и просто текстовые редакторы, вроде Notepad++. На самом деле то же самое я пытаюсь узнать уже много тредов, но почему-то всегда получаю абстрактные ответы «NeoVim — говно хипстерское» или «зато в виме макросы есть» — правда, ни один пример полезного применения макросов мне пока что не смогли привести.

Итак, дублирую здесь свои требования к IDE/редактору:

Для меня ключевые фичи — это подсветка синтаксиса, пар скобок, текущей строки, достаточно простые операции автоматической обработки текста, вроде «верхний/нижний регистр», замена табов на пробелы и обратно, и вообще автоприменение отступов, и самое-самое-самое главное — это фичи обзора кода, то есть: поиск слов по файлам, открытие файлов по нечеткому имени, поиск тегов по нечеткому совпадению, в идеале поиск объявлений/реализации, иерархии вызовов, и самая обожаемая фича в VS, которую не может повторить никто — это возможность выстроить ручными или полуручными переходами иерархию связанного кода в одном окне прямо в коде. Обычно максимум что могут редакторы по последнему пункту — это позволят открыть несколько окошек и просматривать другие файлы параллельно там, пока не забудешь, что к чему привязано и зачем ты это вообще открывал. Вкладки для этой задачи подходят еще меньше, поскольку смысл их открытия забывается еще быстрее.

В текстовых файлах я в том числе создаю «базу знаний», но, к сожалению, во многих текстовых редакторах не хватает нечеткого полнотекстового поиска по простому тексту, а не коду программы, потому далеко не всегда поиском по файлам получается найти то, что записал, из-за банальной опечатки, или, наоборот, слишком большой выдачи по общему запросу, который не получается конкретизировать дополнительными условиями плана «из результатов поиска найти те, рядом с которыми находится такое-то слово». Буду благодарен, если кто-то также подскажет готовое решение для данной задачи — размеры моей благодарности не будет знать границ.

Как вы все прекрасно знаете, в мире есть волшебная традиция: множество людей, которые создают вещи, и множество людей, которые зарабатывают на них деньги, в основном не пересекается. За очень-очень редким исключением. Торвальдс делает ядро, IBM (а скоро и Microsoft) на нем зарабатывает. Это примерно как народная мудрость «есть люди умные, и есть люди сильные». Меня в данном случае не волнуют банальные рациональные объяснения, вроде «господь желает сохранить спонтанную радость в людях и не дает превратить мир в цифровой концлагерь» — даже если я не смогу научится в продажность, я хочу понять, как и почему.

У меня навык продажи, в том числе своего ануса, хронически хромает. Поскольку я в ближайшее время свой анус выставляю на аукцион, то хотелось бы немножно апгрейднуться в этом направлении. Я понимаю, что не совсем на том сайте это спрашиваю, но все же. Я потихоньку коллекционирую наблюдения за успешными, вроде «отдавай предпочтения популярным/популистским решениям, а не правильным» (ты себе хочешь сделать хорошо или заказчику?), «врубай режим нарцисса и рассказывай, что краше тебя на белом свете нету», и просто «пиши про себя на каждом заборе — авось кто-то поведется».

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

Также бонусный вопрос: где нынче в айти вообще шевелятся денежки? Ну то есть я плохо понимаю, как за последние годы перекроилась индустрия. Для меня не составляет проблемы вкатиться в новую нишу, но очень не хочется вкатываться в совсем уж помойку, которую я обязательно безошибочно выбору из сотен вариантов. Как я выбрал тот же поцкаль, который никому не нужен — и это правильно. Правильно, что индустрия на нем ничего не пишет, и правильно, что я выбрал бесполезную технологию — всё, что нас не убивает, делает сильней.

Воскресный батхерт-разогрев перед началом рабочей недели. Очередной рассказ про «слабую логическую связанность, составленность из груды костылей, неподдатливость расширению», то есть " питоничность".

Как вы декорируете блоки кода в Python? Ну то есть все мы знаем, что можно декорировать функцию:

@decorator
def funcname(arg):
    pass

и даже декорировать класс:

@decorator
class classname:
    def __init__(self):
        pass

Но вот беда — как передать кусок кода в другую функцию? Вечная проблема лямбды в питоне, которая не решена до сих пор и никогда не будет решена:

>>> decorator(lambda: a = 2)
  File "<stdin>", line 1
SyntaxError: lambda cannot contain assignment

Мне стыдно, но я до сих пор не подозревал, что в лямбдах нельзя использовать присваивание. Я подозреваю, что я не один такой, на самом деле, потому что лямбды почти никто не использует — в том числе по этой причине.

«Хорошо, наш язык говно, но давайте не отчаиваться, с этим что-то можно сделать» — сказал когда-то Гвидо, и предложил:
https://www.python.org/dev/peps/pep-0343/ — PEP 343 — The «with» Statement

Этот чудесный костыль позволяет вам обрамить любой блок кода процедурами инициализации и финализации. Проблема — что мне делать, если я хочу обрамить блок кода сложнее, например, чтобы он оказался в цикле? То есть

for filename in filenames:
   with try_infinitely():
      print(open(filename, 'r').readlines())

В данном случае код должен пытаться бесконечно открывать и читать файл, пока не сможет это сделать. На питоне это можно написать как:

for filename in filenames:
    while True:
        try:
            print(open(filename, 'r').readlines())
        except Exception as e:
            print(e)
        else:
            break;

Но писать такую стенку каждый раз весьма утомительно. Как и заставлять юзверя объявлять вложенную функцию и передавать ее функции-декоратору, поскольку это будет нарушать обычную читаемость кода из-за того, что код вложенной функции будет выполняться позже своего объявления, в отличие от тех же лямбд JS, которые выполняются там, где определены. Чтобы была чуть более очевидна блевотность такого кода, я специально добавил цикл for filename in filenames снаружи:

for filename in filenames:
    @try_infinitely
    def nestedfunc():
        print(open(filename, 'r').readlines())
    nestedfunc()

или

@try_infinitely
def nestedfunc():
    print(open(filename, 'r').readlines())
for filename in filenames:
    nestedfunc()

Последнее, к моему удивлению, работает, потому что области видимости в питоне поделены на уровне функций, а не блоков, и потому filename будет видима в любом месте функции.

А хотелось бы чего-то простого и понятного, плана:

for filename in filenames:
    @try_infinitely:
        print(open(filename, 'r').readlines())

Чувствуете, как код сразу стал намного проще? Единственный выход, который я пока что вижу — это городить свой DSL через

source = inspect.get_source(func)
ast.parse(source, func.__code__.co_filename, 'exec')

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

По мотивам: Си с классами

бери с++20 с концепциями, корутинами и ренжами. игнорируй всё из с++17, сфинае, не пиши упоротые шаблоны, вообще шаблоны старайся не писать, и всё будет ок.
концепции уже вроде работают, ренжи тоже есть, корутины ещё не подъехали, но в будущем пригодятся, генераторы там всякие, всё такое. ещё будет проще потом перелезть на экзекюторы и т.д. потом ещё модули затащишь.

Как эффективно учиться? (комментарий)

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

Конкретно мне интересен функционально-процедурный подход к написанию кода на крестах, что-то похожее на Rust, только без абсурдной помешанности на безопасности памяти, так сказать «си с плюшками», но совсем НЕ «си с классами», как было в упомянутом треде. Для примера: Qt и UE — это примеры плохой архитектуры в данном контексте. Например, fstream — это плохая реализация файловых операций, поскольку скатывается в классы и исключения, в ней даже нельзя без исключений получить конкретную ошибку файловых операций.

Итак: какие есть конкретные хорошо проработанные приемы и библиотеки для писания на крестах в функционально-процедурном стиле?