Какой язык программирования объективно лучше? Ну т.к. любой язык программирования -- это прежде всего синтаксис,
то требуется прежде всего
a) хорошая рефлексия (что подразумевает гомоиконичность (структура программы похожа на её синтаксис)), и
b) возможность манипуляции синтаксисом (макросы).

Так :) Прекращайте уже мне рассказывать, как вы "изучаете" Haskell, или как вы "изучаете" TAPL, или как вы "изучаете" "новый Розеттский камень", все эти карго-культы и умничанье на уровне детский сад штаны на лямках. Пока вы самостоятельно не сделали на нормальной работе за нормальную зарплату проект/подсистему хотя бы на 20,000 строк "ООП", забудьте вообще об этом всём.

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

Сегодня буквально за 3 года весь ваш опыт обесценивается на 100%, если вы не развиваетесь карьерно в плане требований рыночных вакансий.

Моего трека по ООАП вам абсолютно достаточно для проектов на десятки тысяч строк; вот как научитесь их качественно делать, потом и тратьте время на понты (хотя это всё равно глупо, если вы не понимаете чётко, что это вам даст, а просто тупо "интересненько", просто кривые от императивщины мозги запутаете ещё больше).

Вот ваш прямой трек в ИТ: вам надо научиться легко создавать рабочие (за которые вам платят) проекты (самостоятельно или с подчинёнными),
с полной ответственностью за результат:

100 строк - 1,000 строк - джун - 10,000 строк - миддл - 100,000 строк - хороший миддл - ...

Моего трека по ООАП вам абсолютно достаточно до этого уровня. Вот пока до него не доберётесь, вообще прекратите тратить ресурсы впустую на любые побочные темки.

+9 Если у вас нет внутреннего интуитивного знания про O-большое, что определяет, сколь качественно вы реализуете требования, чувствительные к производительности, то вы никак не программист (не говоря уже об инженере-программисте).

Вы притворяетесь, что пишете код.

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

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

P.S. К тем, кто проходил мои курсы по АСД, не относится конечно.

Сегодняшняя популярность Python и Java -- примерно то же самое, что популярность Microsoft Basic и Borland Delphi лет 20 назад, когда они годами оставались на пике популярности, и казалось, что ничто не сможет поколебать их доминирование.
Не введитесь на "популярность" каких-то технологий, изучайте в первую очередь универсальные вечные вещи.

+10 Когда вам понадобилось в проекте что-то улучшить, не думайте об этом по схеме "что нового надо добавить" (какую очередную приляпку прифигачить :).

Думайте по схеме "как получить результат, удалив что-нибудь из проекта". Удалив лишние функции, лишние классы, лишний код...

+12 Стратегия развития в ИТ: формировать под профиль своей карьеры личную библиотеку абстракций, которые дают вам всё лучшие и лучшие результаты в ваших проектах, в вашем стеке, требуя при этом всё меньше и меньше ресурсов для реализации.

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

Рекламные обещания Java: write once, run anywhere.

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

Чтобы не получалось вот так и не возникало желания сбежать из айти:

"Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни?"

надо понимать прежде всего вот это.

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

+13 В продолжение темы библиотеки личных абстракций -- как её формировать?

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

Это примерно как своя тщательно отобранная и сформированная колода карт в MtG например (хотя все карты вроде как самостоятельны, но в то же время связаны определённой логикой друг с другом). Вы встречаете очередную задачку, очередной вызов -- и легко бьёте их своей супер-колодой! На любую проблему у вас есть работающее решение.
А вокруг все офигевают: как он это делает? он гений!

Наблюдение: Python постепенно превращается в TypeScript 😁

Если вы активно работаете с базами данных, или серверным программистом на бэке, и при этом не слышали о проблеме N+1 , то сейчас где-то заплакал котик.

Eric Von Reinhard, работавший ведущим программистом в швейцарском Google, в качестве лучшего языка программирования на перспективу в 2022-м рекомендует изучать Python.

Отмечу только в дополнение к вот этому его аргументу

"Companies compete all the time and they look for fresh developers who know a modern language… not the old Java and C++."

что Python тащит сегодня с собой вообще всё, начиная с 1991 года, и почти всё из этого всего вам никогда не понадобится.

Ну, началось! А я уже не один год говорю -- нейросетки это хорошо, но мир таки захватит AI на формальной логике :)
В The NetHack Challenge 2021 (программы, мастерски играющие в легендарную рогульку) победил с ощутимым отрывом AutoAscend -- чистый символьный AI. Нейросетки тут не конкуренты, потому что они не умеют "думать стратегиями" и скорее всего никогда не научатся.

Я на нетхак потратил когда-то наверное тысячу часов :) До Амулета Йендора добирался...

P.S. И немного о грустном: в свежем Tortoise "The Global AI Index" Россия в мировой AI-гонке остаётся стабильно в третьем десятке, 32-е место.

Мир с помощью AGI (символьного :) через 2-3 десятилетия захватят США + Великобритания, или Китай, на 99%. Довольно внезапно с 12-го на 5-е место (за год!) поднялся Израиль. Впрочем, нифига не внезапно: он на первом месте в мире по относительному финансированию темы AI и на душу населения, и по исследовательским работам.

+15 "Разворачиваемость" вашего проекта (скорость лёгкость простота его деплоя) -- это одна из неотъемлемых, ключевых, абсолютно обязательных целей любого правильного проектирования.

Читаю "Real-World Cryptography" David Wong -- очень классный учебник, рекомендую и по теме, и не только: много bad/best practices, которые отлично подходят к повседневному программированию. Каждому уважающему себя миддлу-сеньору желательно изучить, в спокойном темпе главка в месяц, в алгоритмы/код особо можно не погружаться, достаточно понимания, всё очень хорошо объясняется, с картиночками для малышей :)

Узнал из этой книги, что Майкл Хайден, бывший директор АНБ и ЦРУ, заявил “We kill people based on metadata” :) В связи с этим вопрос, насколько вы доверенная сторона, насколько ваши ИТ-системы спроектированы так, что гарантируется (в идеале формально) что к этим метаданным нету нежелательного доступа, что они не могут быть скомпрометированы, сфальсифицированы? Викиликс вот говорит, что в АНБ дела с этим не очень... Впрочем, везде с этим не очень; более попсовую по теме можно почитать "The Perfect Weapon" David Sanger.

В частности, одну из рекомендаций Вонга для повседневных нужд перефразирую так:

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

Сегодня довольно активно применяется GraphQL, довольно часто ребята кто у меня занимается эту СУБД упоминают.
Ну, GraphQL -- это своего рода WSDL/SOAP для миллениалов и поколения Z :)
(рассказывал про это всё)

Что будет следующим? web3 , что-то типа WSDL с сильной типизаций, с акцентом на семантику, и уж совершенно точно не JSON-ы.

Чем отличается гуру от хорошего сеньора (10+ лет опыта)? Если вы сеньор, то вы (или какой-то другой сеньор) можете вписаться в подавляющее число ИТ-проектов самого разного профиля, и помочь большому количеству людей практически в любом таком проекте.

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

Я вообще большой сторонник TDD, всегда к нему призываю, всегда рекомендую, потому что это первый шаг в направлении TLA+ (мышление спецификациями) и полноценных формальных методов в перспективе. Однако всё же надо честно признать, что когда тимлид вроде как по моим рекомендациям пытается "внедрять" TDD в своей команде, в 70% случаев получается карго-культ )))

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

Только вот интерфейсы всех компонентов, сюрприз! оказываются в итоге спроектированы так, чтобы успешно проходить тесты, а не быть удобными в работе )))

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

Ok, это моя недоработка :) В следующем году будем с этим очень плотно разбираться.

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

Я бы даже сказал, что эта схема работает так продуктивно, что похожа на жульничество :)

8 когнитивных багов начинающих архитекторов распределённых систем:
- сеть работает надёжно;
- задержка нулевая;
- полоса пропускания бесконечна;
- сеть безопасна;
- топология сети неизменяема;
- стоимость трафика нулевая;
- сеть гомогенна (только винда например :);
- для суппорта сети достаточно одного админа на удалёнке.

Бонус: "больше не воспроизводится".
Ну, недетерминированные системы пытаться покрывать классическими детерминированными тестами, очевидно, просто глупо. Правильно: проектировать систему в детерминированных моделях, допускающих распределённые вычисления.

+16 Важные коаны проектирования :)
- плоское лучше, чем вложенное;
- разреженное лучше, чем плотное.

Да, и конечно, если реализацию вашей схемы проектирования вам сложно словесно объяснить хотя бы котику -- значит, сама идея плоха. Переделывайте :)