По мотивам вакансии: Требуется: Программист С, Ростов-на-Дону

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

Мой вопрос в треде остался без ответа — кому и зачем это нужно? Ну то есть я не спорю, что так делают, цитирую:

Очень много раз слышал мнение, что «после 30 мозг уже не гибкий, не может приноровиться к новым задачам, изучить новые фреймворки. Если не стал к 30-35 большим начальником - то жизнь прожил зря и нам такой не нужен».

Я очень удивился, что в текущей моей компании нет такого мнения

Короче говоря — каковы истоки сего феномена?

Будь то багтрекинг, или же разработка нового софта, или даже вещи, слабо связанные с IT, вроде CRM или ERP систем. Все мы любим потешаться с корпоративного bloatware, вроде той же Jira (которое даже произошло от слова Gojira), или 1С, или Битрикс, или, боже упаси, решения оракла с SAP.

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

Если говорить про меня, то я — виртуальный луддит. То есть, компьютером-то я пользуюсь, но многие современные технологии для меня выглядят как «ненужно». Например, мне нравится работающее continious development — но я не люблю Git, на котором большинство подобных решений работает. Например, я веду список дел, которые мне нужно сделать, но в большинстве случае это произвольной формы текстовые записи без конкретных дат, а на какие-то редкие дела, вроде собраний, у меня ставится будильник:

Многомерный issue-трекер (комментарий)

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

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

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

Не буду утомнять вас плохими примерами — я все-таки хотел бы поговорить о хороших. Существуют ли они? Один пример уже приводили:

Многомерный issue-трекер (комментарий)

Это система автоматического тестирования, которая сама прогоняет тесты по куче конфигураций и выдает результаты в единой табличке. Мне нравится такой подход — но он весьма специфичен для конкретного этого проекта. Например, у разрабов GUI/frontend тесты писать не получается, потому что в пользовательском интерфейсе обычно переходы важнее, чем конечные состояния, к тому же конечные состояния могут быть очень разными при одинаково успешном тестировании — но автоматические тесты смотрят именно на конечные состояния. Не в последнюю очеред потому у Oracle и SAP очень сильно хромают пользователськие интерфейсы: руководители этих фирм поставили ключевым критерием успешной разработки софта прохождение тестов, и в итоге софт, успешно прошедший тесты, валится с ошибками у конечного пользователя, или же просто тормозит как Java в 1995.

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

https://habr.com/en/post/447162/ - Не купитесь на ERP

Сразу скажу, что я не согласен с автором, но позиция интересна. Если слегка смягчить ее, то получится что-то такое: если на вашем предприятии бардак, то ERP за вас не сможет его организовать; если же вы навели порядок на своем предприятии, то ERP вам уже особо и не нужна.

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

Подход SAP в этом плане весьма остроумен с коммерческой точки зрения, потому что работы по сверхточному нанесению пользы сам SAP не выполняет, вместо этого клепая вот такие таблички на 240 столбцов:

https://www.sapdatasheet.org/abap/tabl/mara.html

Ну или просто позволяя вам выбрать из готового набора 110 000 (сто десять тысяч) табличек те, которые подойдут вашему бизнесу... или не подойдут. Остроумен с коммерческой точки зрения такой подход потому, что с позиции человека, который не разбирается в IT, то есть, типового клиента SAP, какой-нибудь SAP R/3 предоставляет собой крупную хорошо проработанную и проверенную систему, которая покрывает чуть ли не все на свете варианты бизнес-процессов предприятия. В такие моменты я люблю вспоминать покойного Дейкстру:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

То есть, приходит менеджер, который отвечает за принятие решений, и спрашивает у продажника SAP: «у вас есть ${фичанейм} в системе? Насколько хорошо автоматизирует ${процесснейм} ваше решение?». Причем, говорить об этом до начала внедрения — это все равно, что спрашивать у женщины «вы можете родить мальчика или девочку? А мальчик будет гениальным?». Особенно если этой женщине 50 лет и ее маркетинговое преимущество — это что оба ее сына стали успешными учеными.

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

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

Реляционная же модель приводит к тому, что когда внезапно появляется необходимость сделать связь сущностей N-к-M вместо какой-нибудь 1-к-N, то приходится перекраивать базу верх ногами, создавая новую таблицу связей между сущностями и изменяя алгоритмы создания-чтения-обновления-удаления. А в случае перехода от 1-к-1 в N-к-M нужно создавать уже две дополнительные таблицы. У того же SAP по этому поводу из коробки для целой кучи атрибутов есть поддержка множественных связей, откуда и появилось астрономическое количество табличек — в реальности таблиц корневых сущностей там всего несколько сотен.

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

Есть много опенсорсных попыток писания ERP софта (например, Odoo, OpenERP, IDempiere/Compiere/Adempiere/Openbravo/metasfresh), но каждая из них, как правило, представляет собой одну и ту же попытку повторить SAP в мелком масштабе. У меня есть некоторые абстрактные зарисовки по этой теме, но, как показывает практика, публиковать их не имеет смысла, а пытаться сделать что-то конкретное прямо сейчас у меня тупо нет времени/желания, поскольку я работаю над релизом предыдущего незаконченного проекта питоньей многозадачности. Так что принимайте эстафету.

В свое время неприязнь к C++ погубила мою карьеру программиста. Не буду загадывать, хорошо ли это или плохо, но это случилось. Одни люди видят в крестах гору костылей и повод заработать, обучившись этими костылями орудовать — другие, вроде меня, отстраняются и занимают позицию вроде «лучше я буду работать за еду, чем писать на этой параше, где в крупном проекте нужно хотя бы 8 ядер и SSD, чтобы проект компилировался меньше часа».

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

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

Или вот возьмем свежее обсуждение: React. Казалось бы, крошечная бибилотека, даже меньше моего члена, которая пишется с нуля за недельку-другую, и которая совершенно неюзабельна для достаточно динамичных приложений, потому что будет тормозить даже на самом быстром современном компе. Что иронично, учитывая ее назначение — SPA приложухи.

Я занимаю позицию «зачем мне эта гадость? Я же буду душевно страдать, прикасаясь к ней изо дня в день». И, естественно, я выпадаю из массовой фронтенд разработки, потому что куда ни плюнь — там «Senior React developer needed». В моих глазах это похоже на «Senior Calculator operator». А по-хорошему должна выглядеть как «мы — лохи с деньгами, и у нас их слишком много». То есть, позитивно, на достижение какой-то цели, а не традиционное «не нужно». Тем более, что если написать фронтэнд хорошо, не на React-е, то я создам заказчику проблему — как этот код потом будет поддерживать макака с одной извилиной? У меня-то извилины две!

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

Не в последнюю очередь это сдерживает меня от релиза и своего нынешнего проекта, потому что в его сыром виде это таки очередное «ненужно», которое для доведения до возможности прикладного применения требует даже не напильника, а станка с ЧПУ.

Вот. Нид хэлп, сэнкс ин адванс.

Может кто-то встречал необычные идеи, концептуальыне проекты, или просто какие-то передовые и непопулярные модификации имеющихся инструментов разработки интерфейсов?

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

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

Самую-присамую писечеку из рядов массового софтопрома разрабатывает гугл в своем хроме:

https://www.chromium.org/developers/design-documents/compositor-thread-archit...

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

Но даже этого недостаточно для того, чтобы приложения на электроне перестали быть тормозным и жрущим оперативу калом. Но достаточно, чтобы сравниться с приложениями на Java. Это забавно выглядит в 2020 году, когда производительность процессоров растет медленнее, чем растет тормознутость интерфейсов. Сижу я тут, играю в Deus Ex: Mankind Divided, и думаю: а может, и правда, в 2029 году «прогресс» дойдет до того, что интерфейс для ввода четырех циферок будет открываться-закрываться по пять секунд, как в этой игре? И выключатели на тач скринах, которые работают только на «вкл-выкл» — я ванговал в соседнем треде, что на будущих девайсах для прогрессивной молодежи должна быть только одна кнопка.

Объективно, если брать современный GUI iOS/Android, то это упрощение по сравнению с многозадачными интерфейсами десктопов: пониженные требования многозадачности, пониженные требования к отзывчивости, набор доступных действий неочевиден, что идет против концепции GUI «я должен найти все фичи программы просто гуляя по менюшкам» — последняя проблема уже имеет варианты решения в виде Pie/Marking Menus. Да, это частично оправдано малым экраном. Да, эти проблемы со временем можно будет частично решить (если тенденция ухудшения не перевесит тендинцию улучшения). Но в целом, с позиции разработки, программы для тачфонов по прежнему пишутся в стиле однопоточного цикла обработки сообщений, просто сообщения стали несколько другими.

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

https://habr.com/en/post/526002/ — Making python's dream of multithreading come true

Хотелось написать что-то для прочтения буграм, но и вам запощу, так и быть. Буду благодарен, если кто-то запостит это на reddit.com/r/python и даст ссыль сюда, потому что мне еще две недели нужно ждать, пока аккаунту разрешат делать посты.

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

В частности, написание статьи само по себе помогло сообразить, что без механизма каналов особо нечего ловить в прикладнухе. Причем, я уже знаю, как эти каналы можно сделать гибкими на зависть Go-шникам, потому что это будет не прибитый гвоздями к языку черный ящик, а отдельные примитивы синхронизации и хранилище аля std::deque, для которого можно как быстро в lock-free режиме добавлять и забирать записи, так и выполнять на самом питоне сложные транзакции плана «выбрать записи определенного типа из очереди» — не блокируя при этом lock-free добавление новых сообщений и не блокируя параллельных читателей. То есть, в одном флаконе умещаются любые сочетания взаимодействий производитель-потребитель. Конечно, я подозреваю, что алгоритмы на питоне будут тормознутыми, но что ж поделать, это питон.

Навеяно чтением статьи:

http://blog.alinelerner.com/ive-been-an-engineer-and-a-recruiter-hiring-is-br...

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

Булшыт-бинго тред (комментарий)

Однако, я не вижу у автора статьи (CEO этого interviewing.io) понимания эффективных путей решения этих проблем. Ну то есть она предлагает агрегировать данные о кандидатах при помощи проведенных другими людьми собеседований и опыту работы. Что, опять же, не исключает вот таких сценариев:

HR ставят диагнозы или erzent был прав

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

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

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

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

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

Перемещено leave из development

Беглый поиск показал, что отдельные люди разделяют мое мнение:

Как исключить домены из поискового запроса Google?

То есть, если что и сделало medium.com популярным, то это точно не качество технической реализации. У меня постоянно горит очаг, когда я нахожу неплохую статью, но мне нужно ее читать через тонкую кишку с зияющей пустотой по обе стороны, а загрузка картинок будет требовать JS даже несмотря на то, что контент представляет собой типичнейший чистый HTML:

https://caniuse.com/loading-lazy-attr

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

Как вы можете знать, Эван Уильямс был маркетологом, бездарным программистом-фрилансером, позже организовал Pyra Labs, которая создала платформу Blogger — одну из первый блоговых платформ. Здесь мне задним числом всё ясно, человек хорошо прочитал расширяющийся рыночек домохозяек с доступом к интернету, которым не о чем рассказать и они хотят поделиться этим с миром. После покупки гуглом Эван покинул гугл по неочевидной причине — как технический руководитель он был полной бездарностью, а развивать старый проект по новым направлениям было уже некуда.

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

Далее я отстаю от рынка, мой мозг застрял где-то в начале десятых годов. Да, Эван понимает, что разные новостные платформы и блогеры зарабатывают на проплаченных новостях. Как я понимаю, в случае medium.com акцент был сделан не на механизмы работы сайта, не на какую-то техническую реализацию, а на потребителей контента. То есть, они приобрели контент от громких людей, вроде Обамы и его администрации, Дурова, Маска, чтобы получить качественную аудиторию, состояющую из гиков с хорошим доходом, которые сидя в метро или самолете листают большие содержательные статейки, а потом еще раз их листают дома/в офисе на ноуте/десктопе.

Уважаемые знатоки, внимание, вопрос: почему этот сервис появился только в 2012 году и что занимало эту нишу ранее? Дефицит мобильного интернета? Blogger.com устраивал всех, но внезапно перестал? Какая-нибудь Quora (2009) метила на ту же нишу, но в итоге ниши оказались разные, хоть Quora и покупает именитых людей для создания привлекающего контента.

Довелось некоторое время пользоваться этим чудом техники. Я считаю, что Jira является лучшим доказательством того, что все эти новомодные методологии разработки не работают. Ну, то есть работают, и производят редкостное говнище.

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

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

Я бы вспомнил еще претензию по поводу отсутствия возможности отменять изменения задачи, которые вносятся в онную одним кликом, но проблему можно решить отправив SMS на короткий номер приобрести расширение, которое добавляет отмену изменений: https://marketplace.atlassian.com/apps/1220176/action-undo-for-jira?hosting=s...

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

В продолжение: Многопоточный питон, PEP 554

По мере того, как я приближаюсь к релизу своей софтины для реализации многозадачности в питоне, у меня возникает вопрос: а на кой черт она вообще нужна? То есть, зачем нужна объектно ориентированная in-memory база данных с нулевым переключением контекстов. Какие задачи вообще можно решать с помощью большого числа процессов/потоков питона и общего хранилища?

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

Очевидная сфера применения - это веб сервера. Мы заменяем всякие там Redis, RabbitMQ, Celery на родные питоньи решения. То есть, например, энное число процессов получают запросы пользователей, скидывают их в родную питоновую очередь в виде родных питоновых объектов, а потом оттуда эм процессов питона достают объекты и обрабатывают их. Нынче для подобных задач у вас есть выбор межуд in-memory Redis с неродными объектами, либо какие-то более родные, но не in-memory решения:
https://github.com/nascheme/durus
https://pypi.org/project/dobbin/
http://www.zodb.org/en/latest/
http://www.garret.ru/dybase.html

Прикладной data mining и ML - это вообще дремучий лес для меня, к тому же, по моему первому впечатлению мне кажется, что проблему параллелизации непитоновыми методами там уже решили, вроде того же TensorFlow, где большая часть логики, в том числе многопотоков и вычислений на видеокартах, написано на C/C++.

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

if condition then
begin
  ...
end;

int crypto_register_acomps(struct acomp_alg *algs, int count)
{
	int i, ret;

	for (i = 0; i < count; i++) {
		ret = crypto_register_acomp(&algs[i]);
		if (ret)
			goto err;
	}

int ClassName::ReallyLongFunctionName(int par_name1, int par_name2,
                                      int par_name3) {
  DoSomething();
  ...
}

int ClassName::ReallyLongFunctionName(int par_name1, int par_name2,
                                      int par_name3) {

  DoSomething();
  ...
}

Тот же Qt переносит скобку на новую строку для классов и функций, но не делает этого для условий-циклов.

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

Наткнулся на статью:
https://habr.com/ru/post/321864/ - OpenResty: превращаем NGINX в полноценный сервер приложений

У меня сразу возникло два вопроса:

• Мне одному кажется, что автора статьи - бородатый школьник, который сам не разбирается в теме статьи, и половину онной кидает гнилые понты про «я с пелёнок пишу хайлоад»?
• В чем преимущество OpenResty над альтернативными решениями?

Для тех, кто не в курсе, кратко расскажу про OpenResty. Кому-то в Taobao стукнуло в голову, что будет очень хорошим решением взять nginx и засунуть в него LuaJIT. Именно «в него», а не «к нему». Так родился модуль Lua для nginx, на основе которого был сделан OpenResty и еще пару подобных проектов. Nginx однопоточен, LuaJIT однопоточен, вот они как бы в event-driven модели должны хорошо согласовываться. Питон/php/node.js тоже однопоточны, но пожирнее и помедленнее будут. С тех пор OpenResty распространился в основном по китаю, хоть и в остальной мир потихоньку проникает.
Мотивация создателей мне ясна: берем самый быстрый веб-сервер (пусть и неполноценный), берем самый быстрый скриптовый язык, которым на 2011 года действительно был именно Lua c его LuaJIT, скрещиваем их вместе, говорим волшебные слова - получаем замечательный полноценный веб-сервер. Правда, уже на момент 2017 года дистанция между V8 и LuaJIT неумолимо сокращалась, и сейчас они имеют похожую производительность выполнения кода.

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

PS:

Если у вас, допустим, кодовая база на Perl, и вы не Booking, вы не найдёте перловых программистов. Потому что их нет, их всех забрали, а учить их долго и сложно

Палю годноту: Booking набирает кодеров без знания перла для работы с перлом. Так что если кто мечтает писать на перле - имейте в виду.

- Сколько нужно архитекторов, чтобы создать язык программирования?
- Сто. Один будет писать язык, а 99 - говорить, что могут сделать лучше.

Так скажем, я решил вспомнить обсуждение по теме треда: Generics в Python или помогите победить mypy

Да, наркоманский питон захватывает мир, и с этим нужно что-то делать. Нет, я не намерен делать питон 4 - я вижу свет в конце тоннеля в рамках третьей версии. Но мне нужна ваша помощь: какие фундаментальные фичи, по-вашему, в питоне вообще не нужны, а какие - должны быть переработаны?

Прежде всего, я хотел бы вспомнить про RPython ( https://rpython.readthedocs.io/en/latest/rpython.html ).
Смысл особенностей языка прост - поддержка вывода типов. В частности, из языка убраны динамические определения классов и функций, динамическая типизация переменных, глобальные переменные стали константами, функции-генераторы транслируются в классы-итераторы и потеряли большую часть своих фич. У RPython есть большой минус - эти его ограничения сильно раздувают код, затрудняют писание и читание.
Итак, мои соображения:

1. Множественное наследование. Его нет даже на уровне C-функций в реализации питона и API расширений. «Но как же интерфейсы?» - возразите вы. Интерфейсы в C++ и Java нужны в роли объявления протоколов вызова методов объекта с целью последующей статической проверки этих протоколов при компиляции, а также для формирования таблиц методов, которые можно использовать независимо от объекта во время выполнения. Эти роли полностью потеряны в питоне, потому нет никакого оправдания их существованию. Мне нравится то, как сделаны интерфейсы в Go - это очень похоже на питоновые ABC: https://www.python.org/dev/peps/pep-3119

2. Генераторы - зло. Это прямо-таки запущенный случай GoTo, когда выполнение не просто бесконтрольно прыгает по коду - оно прыгает по стэкам. Особенно лютая дичь происходит, когда генераторы пересекаются с менеджерами контекста (привет PEP 567). В треде, скорее всего, опишу веселости реализации генераторов в PyPy/RPython. В питоне есть общая тенденция запутывать приложение в тесный клубок связанных изменяемых состояний, что не дает возможности параллелить и оптимизировать выполнение программы, а генераторы - вишенка на этом торте.

3. Изменение классов для существующих экземпляров объектов. Не, я понимаю, что класс в питоне объявляется во время выполнения. Но, блин, зачем в него совать изменяемые переменные? Зачем в старые объекты добавлять новые методы? Причем, попрошу обратить внимание на то, как нужно нагибаться раком для того, чтобы добавить аналогичные методы в сам объект, а не в класс - для этого нужны types.MethodType, function.__get__, functools.partial, и так далее. Методы в питоне вообще понадобились по простой причине - гвидо не придумал других способов сделать короткие имена функций (чтобы не было gtk_button_set_focus_on_click), поскольку не ясно, как выбирать из кучи похожих функций с коротким именем нужную под этот конкретный объект. Так в питоне появились len, iter, next, isinstance, slice, dict, dir, str, repr, hash, type - сейчас это обертки над соответствующими методами классов с подчеркиваниями в имени, а когда-то встроенные простые типы не являлись классами и работали только через эти функции. Так-то, я не вижу особой разницы между записью method(object) и object.method - особенно если method является статичной функцией, которой, в общем-то, все равно, какой первый аргумент (self) принимать.

Вот. Прошу дополнять. Да, я знаю, что у питона основные проблемы две: отсутствие статической типизации и многопоточности - но это черезчур абстрактные требования. К тому же, Javascript безо всяких типизаций достиг производительности Java, при том, что жавамакакам постоянно приходится гнуться под язык, а JS-кодеры испытывают удовольствие от говнокодинга.

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

https://github.com/ericsnowcurrently/multi-core-python
https://www.python.org/dev/peps/pep-0554/

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

Теперь главный вопрос: зачем? PEP 554 предлагает обращаться за помощью к каналам, как в Go, но:
- каналы как средство взаимодействия потоков убоги даже в Go;
- в питоне уже есть multiprocessing, который по сути и есть развитая идея каналов с возможностью прокинуть в обе стороны вызов функции и запрос атрибутов объекта, вплоть до итераторов, но не более того.

Для людей, которые уже готовы отвечать «ну дык есть же многопроцессы, есть форк на никсах - вот и используйте их», напомню, что реализация форка процесса на уровне ОС-и в действительности мало помогает многоПРОЦЕССовости питона - машем ручкой сборщику мусора, который передергивает счетчики ссылок:
https://instagram-engineering.com/dismissing-python-garbage-collection-at-ins...

>>> import os, sys, gc
>>> len(gc.get_objects())
6888

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

def hello():
    return "hello world"

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

Для решения проблемы со стандартными бибиотеками и сборщиком мусора сообразительные люди довольно быстро придумали Jython, позже - IronPython, а потом и PyPy. Все три реализации привязывают вас к соответствующей среде выполнения, и это неприкольно даже несмотря на возможность выйти из них в расширения на C или других языках - проще написать уже всё на крестах или жабе, чем морочиться с пирамидами языков.

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

Кто-то видит свет в конце тонеля? Или же это предсмертные видения?

Я осознаю, что Python+ML или Django сейчас дают хороший доход и есть много вакансий. Проработав много лет над скучным проектом Delphi+Firebird у меня нет больше желания работать просто ради денег, вплоть до того, что я бы занялся неким общественно ценным проектом забесплатно.
Опыт: GSoC на C и GTK; разработка ARM-контроллера электропривода на C; многопоточные приложения Win32 API (не только VCL) и SQL (firebird). Говорю/слушаю/пишу/читаю english, примерно A2-B1, хуже всего говорю, хорошо слушаю. Хорошо знаком с экспериментальной орг. химей. Малообщителен, но имею склонности к решению сложных проблем, в частности, отладка. Из более поверхностных знаний Django, JS, Haskell, SQLite, OpenGL, Maemo, разработка модулей ядра Linux, настройка Linux серверов (bind, apache, nginx, postgresql).
Местоположение - глубинка, потому скорее всего удаленное взаимодействие.

Понравилось, как неодимовый магнит магнитится ко всему. Жесткому диску это, по-видимому, ни разу не понравилось.

# ddrescue /dev/sdc2 /dev/null
rescued:   157181 MB,  errsize:       0 B,  current rate:   75169 kB/s
   ipos:   157181 MB,   errors:       0,    average rate:   93942 kB/s
   opos:   157181 MB,     time from last successful read:       0 s
Finished
# ddrescue /dev/sdc3 /dev/null
rescued:     2716 MB,  errsize:    325 kB,  current rate:     7948 B/s
   ipos:     2716 MB,   errors:       2,    average rate:   15346 kB/s
   opos:     2716 MB,     time from last successful read:       0 s
Interrupted by user
# ddrescue -i 3000M /dev/sdc3 /dev/null
rescued:    983552 B,  errsize:       0 B,  current rate:    51765 B/s
   ipos:        3 GB,   errors:       0,    average rate:    51765 B/s
   opos:        3 GB,     time from last successful read:       0 s
Interrupted by user
# ddrescue -b 1024 -i 4000M /dev/sdc3 /dev/null
rescued:    456704 B,  errsize:   68608 B,  current rate:     8617 B/s
   ipos:        4 GB,   errors:       1,    average rate:     8617 B/s
   opos:        4 GB,     time from last successful read:       0 s
Interrupted by user
#ddrescue -b 1024 -i 60000M /dev/sdc3 /dev/null
rescued:     1358 kB,  errsize:    215 kB,  current rate:    11355 B/s
   ipos:    60001 MB,   errors:       2,    average rate:    12132 B/s
   opos:    60001 MB,     time from last successful read:       0 s
Interrupted by user

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       411
  3 Spin_Up_Time            0x0027   154   151   021    Pre-fail  Always       -       1266