Ответ на вчерашнюю задачку: {{}} -- это непустое множество. Но совсем не потому, что это естественно, а наоборот -- всё очень запутано:)

Классический пример кризиса оснований математики -- это аксиоматическая теория ZFC (логика предикатов + проверка принадлежности множества множеству), развитие которой происходило весьма неформальными методами. Воеводский эту проблему пытался как-то решить, по крайней мере запустил процесс, в унивалентных основаниях математики, и его продолжатели вроде таких куда-то ещё бредут, потому что даже сама возможность формализации метатеории не доказана, или даже, точнее, тут возникает потребность в некоей странной нелогической, "корпускулярной" логике :)

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

Готовлю лекцию "Про инопланетян, плоскую землю и функциональное программирование". Вы узнаете такие невероятные факты, что
a) Haskell значительно старше, чем Java, и
b) Haskell сейчас в том возрасте, в каком был Algol, когда родился Haskell.
Ещё смешное, в тему: Monad_tutorials_timeline
В 100500-й раз про то, как преобразовывать профунктор в комонаду через коалгебру, снова вот это вот всё.

Если вы думаете, что знаете, на что способен type inference, подумайте ещё раз: профункторные линзы на PureScript
(нет, это совсем не похоже на TypeScript, это скорее хаскель для фронтенда)
вот какие красивые композиции можно выделывать

Однако если вы хотите изучить функциональное программирование "для практики", не вздумайте браться за хаскель, потеряете кучу времени совершенно впустую. Самый прагматичный подход: сперва изучаете C++20 просто по хардкору, и затем берётесь за stl, в которую Степанов сразу заложил мощную математику -- в ней идеологически полно функциональщины. И потом смотрите, что в вашем языке из стандартных либ есть подобного (хотя вряд ли), ну по кр.мере пытаетесь придерживаться стиля stl. И в целом, от темплейтов остаётся всего один шаг до метапрограммирования.

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

Задачка по импортозамещению: спроектируйте логическую плату (напишите функцию, условно), у которой три входа и три выхода. При подаче на любой вход 1 или 0 на соответствующем выходе появляется инвертированный сигнал 0 или 1. Вы можете использовать произвольное количество AND и OR, но из-за санкций только два элемента NOT.

Джона Бэкуса однажды спросили, почему функциональное программирование так и не стало по-настоящему популярным. Он ответил: "ФП сильно упростило реализацию сложных задач, но сильно усложнило реализацию простых задач".

Результат конечно неидеальный :) Радует лишь, что в аналогичном опросе у какого-то американского профессора cs, более 50% (!) его студентов проголосовали за вариант В.
Дорогие, ну логику очень важно развивать, завтра напишу как.

То самое чувство, когда понимаешь на собственной шкурке, что же такое капитализм )))

"Twitter employees say managers instructed them to work 12-hour shifts, seven days a week to hit Musk’s aggressive deadlines and that their jobs are at stake."

Надеюсь, вы активно используете sed, но он универсальный, а нередко требуется нечто более продуктивное под определённую специфическую задачу. Например, разбираться с этими гадкими безтиповыми json-ами -- лакмусовой бумажкой того дна, в которое скатилось ИТ :)

jq -- a lightweight and flexible command-line JSON processor.

jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text.
...it has zero runtime dependencies.

Я посмотрел, как он устроен внутри -- ну, да, jq создаёт внутреннее представление json-а, так что вы используете изоморфизм :) На эту тему в СильныхИдеях будет материал скоро.

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

Как программисту развивать логику?

Хорошо бы конечно отдельно пройти курсы по мат.логике,

а на уровне джуниора/миддла очень рекомендую порешать задачки из книг Рэймонда Смаллиана для малышей: "Принцесса или тигр?", "Алиса в стране смекалки", "Загадка Шехерезады". Далее, если будете это легко решать (но это вряд ли :), попробуйте осилить "Вовеки неразрешимое", и после этого уже вполне можно взрослый курс по логике изучать.

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

вылечит и психа
и лунатика
кодоприкладная
математика

Привлекли микрософтовских буржуев к общественно полезным работам ))

In 2020, Core Developer Mark Shannon drafted an Implementation plan for speeding up CPython (the most common implementation) by five times. Python 3.11 has already seen speedups of 10-60% in some areas of the language.

P.S. В сентябре кстати я говорил, как microsoft подставляет разработчиков своим copilot-ом, и вот на днях им выкатили иск на 9 миллиардов долларов, и поделом.

Тим Бернерс-Ли (отец Интернета) призвал на днях "игнорировать" криптодвиж, и заявил, что он не считает блокчейн жизнеспособной технологией для создания интернета следующего поколения.

Он также возмутился, что дескать термин "Web3" скрали пацаны из Ethereum для своих блокчейн-проектов.
"Web3 is not the web at all"

При этом однако Папа продвигает свой собственный децентрализованный(!) проект Solid под брендом "Web 3.0" :)
Идея проста: единый логин везде для всех, и "common universal API" для скачивания данных. Но пока он поднял на свои идеи лишь 30 млн. долл.

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

EA закрыла серию Project CARS, и это понятно. Насколько изумительной была Project CARS 2, настолько отстойным дном стала Project CARS 3 :)

Вот был классный продукт CARS 2 для очень лояльной и весьма хардкорной аудитории любителей автосимуляторов, причём с очень корректной регулировкой сложности, чтобы вообще почти с нуля и до импассибла. Так нет, решили сделать откровенную попсу CARS 3, ну и...
Вон линейка WRC многие годы клепается подобными друг другу релизами, и норм живут. Правда, уровень для слабачков так и не сделали :) Может, и правильно, держат планку входа для определённой проверенной аудитории.

Обычно ругают программистов за кривые руки, но на практике, в 98% провалов (особенно финансовых) ИТ-проектов напрямую виноваты менеджеры буквально всех уровней.

Смешное: компиляция gcc проекта на плюсах в Linux + ext4 выполняется в 5-10 раз быстрее, чем в Windows + NTFS (на одном и том же компе с одной и той же SSD). Более того, даже если юзать встроенную в винду убунту WSL2, всё равно проигрыш получается в разы, что тоже объяснимо, т.к. ext4 там виртуальная; хотя даже если и примонтировать NTFS, всё равно получается медленно и печально.

год как пашет таня
в секторе айти
и теперь от глюков
таню не спасти

В рамках исследования "Python Coding Style Compliance on Stack Overflow" 2019 было просмотрено 400 тысяч кусочков Python-кода (не менее 6 инструкций) на StackOverflow.
-- 94% кусочков нарушают PEP8;
-- в среднем 0,7 нарушений на каждую (!) инструкцию;
- даже самые авторитетные комментаторы ничем не лучше других по критерию плохого стиля.
В мэйнстриме традиционное дно, и AI-ассистанты активно на этом всём обучаются.

Илон Маск погнал программистов из Теслы (плюсы и python) делать code review миллионов строк кода твиттера (javanoscript и scala), откуда сеньоры сразу после сделки разбежались, и хотя их теперь зовут обратно с бонусами, возвращаться не хотят, и правильно. Никогда не возвращайтесь туда, где с вами хотя бы раз поступили непорядочно или неуважительно.

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

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

Однако есть простое, хоть и неочевидное решение, если подумать, чему изоморфно подмножество допустимых плейлистов (и при чём тут биективный гомоморфизм моноидов :). Курсантам в СильныхИдеях скоро поясню эту тему примерами кода.

"Need to take moment to completely rewrite the software stack’"
-- Elon Musk

Раньше: программная инженерия, capability maturity model, классические итеративные подходы, аджайл-методики...

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

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

Понятие Cohesion (сцепление) по Кенту Беку:

-- Вещи, которые должны изменяться вместе, находятся вместе в проекте ("физически" в условной проектной папке).

-- Вещи, которые не должны изменяться вместе, находятся в разных местах. Где? Это вам и надо определить, товарищ проектировщик. Но, скорее всего, вместе с теми вещами, которые должны меняться одновременно с ними.

Бертран Мейер в своей методике ООАП рекомендует вроде бы другой подход: группируем в проекте классы в кластеры по их логической общности (например, все классы оружия или все классы ролей пользователей), но если подумать, этот подход будет почти изоморфен Беку. С какой стати вдруг потребовалось одновременно изменять классы, по смыслу не связанные? Хотя правильно спроектированное ООП подразумевает смысловую правку ровно одного класса, если SRP хорошо выдержан.

Тут главная фишка, что думаем об этом всём именно в контексте cohesion, не скатываясь в coupling.