Конечно в ней есть утечки памяти, но кого это волнует, она же ракета!

Что такое хорошая абстракция? Пока на сегодня лучшее и достаточно формальное определение, которое я нашёл для учебных целей :) такое:
matt.might.net/articles/intro-static-analysis/

Например, множество целых чисел ...,-2,-1,0,+1,+2,... отображаем в абстрактный домен {-,0,+}, где "-" -- все отрицательные числа, "+" - все положительные.

Теперь можем сделать раскладку операций над этим доменом:
{+} + {+} = {+}
{+} + {-} = {+, 0, -}
{+} * {-} = {-}
и т. п.

И теперь мы можем выполнять очень простой статический анализ без необходимости оценивать полное выражение, то есть нам не надо вычислять -4 * +3, чтобы понять, что результат будет отрицательным.

На мой взгляд, это короткое, симпатичное и полезное отображение абстракции.

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

Подробно разбираем в СильныхИдеях эту крайне важную тему.

Залипательное: shark.fish/curiosity/
Ну, да, программистам нередко вот так именно и приходится разбираться -- с легаси-кодом, с issues тимлида, с "ТЗ" заказчика :) А то и с официальной документацией, которая подчас круче любого квеста.

Я где-то около 10 лет назад наверное играл в его же cube composer (сами найдите), тоже крайне рекомендую, микро-тренировка в функциональном мышлении.

Вот наконец и топовые гуру вроде ЛеКуна заговорили о важности symbol manipulation в современном ML/DL/AI.

Ребята без особого проектного опыта, которых повысили и поставили на новый проект с нуля, часто в порыве энтузиазма (но уже немножечко учитывая предыдущий печальный опыт, когда хотелки менеджеров/заказчиков постоянно меняются и растут) заявляют так: "Я хочу разработать универсальную систему, которую можно будет использовать для случаев, которые я ещё не предусмотрел!".

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

Это самая большая ошибка в программировании: не иметь чёткого представления о том, как данные "движутся" в программе, что из чего вытекает и что куда втекает.

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

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

Смешное (в продолжение вчерашнего поста в вк) про то, что 99% ребят "учатся" программированию в стиле "безответственно плодить кучу недопустимых состояний", и потом тащат с собой этот кривой скилл всю жизнь, во все самые серьёзные проекты -- например, когда пилишь биткоин :)
https://github.com/bitcoin/bitcoin/...

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

А я моим курсантам в августе дам более строгий, формальный способ проектирования: как за 15 минут научиться пожизненно правильно думать о всех видах состояний в программе, заведомо избегая недопустимых.

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

Программирование будущего будет примерно таким:
unison.cloud

Пока Гугл и М*** соревнуются в пиаре, у кого круче спецы по AI,
IBM втихомолку набирает ударную группу учёных в проект Systems Neuroscience Approach to General Intelligence (SynAGI). ...To design, build, and code novel architectures for artificial neural networks that exhibit many of the capabilities of biological intelligence while mirroring certain observations in brain anatomy, systems physiology, and behavior.

Особо порадовало такое требование к академикам: ...and develop/implement example AI constructs plus validation methods in Python/C++.
Ну а чего сразу с козырей, сразу плюсы?:)
Между Python и C++ дистанция космического размера.

Твоё лицо, когда вложил 10 миллиардов долларов в метавселенную, и исполнители наконец выкатили "под ключ" итоговый продукт "с кучей контента и уникальной высококачественной графикой".

Как быстро и легко использовать сильные вещи на Python для решения сложных проблем -- с помощью
- Breadth and Depth First Search
- SAT Solvers
- Reinforcement Learning
- Temporal Logic with TLA⁺ and Z3
- Generic MCTS with CNN and Reinforcement Learning

Красивое:
The language that all programmers use

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

Классный курс по System Design, рекомендую.
github.com/karanpratapsingh/system-design
Отлично работает на пару с учебником
"System Design. Подготовка к сложному интервью".

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

Однако всё оказалось не так просто; специально был взят объём утечек, которые могли бы слиться за максимально возможное время полёта, после чего его тупо умножили на два, и таким образом получили дополнительный объём памяти, который был добавлен в аппаратную часть, чтобы "поддержать" утечки.

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

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

"Вы закономерно можете спросить: ну и чем поможет такая формальная система спецификаций, если мы всё равно не можем контролировать конкретную реализацию malloc из некоторой стандартной библиотеки, как правило завязанной вдобавок на конкретную ОС (а то и на конкретную версию ОС), когда нету доступа к её исходным текстам?"

Есть такой термин code smell ("код с запашком") -- кривой стилистически код, что потенциально чревато ошибками (на курсе "Ясный код" довольно подробно разбираем, как правильно). И программисты обычно говорят о "коде с запашком" как о чём-то плохом; но что, если ваш код пахнет картошечкой с жареным лучком?

Python — это фреймворк для Си.

Красивое: lyrajs.io
Lyra is a modern, dependency-free full-text search engine written in TypeScript. It has been built with speed in mind and completes most search lookups in a few microseconds.

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

Хотя и "cohesion", доведённая до абсурда, тоже нехороша: даже если класс достаточно автономен и хорошо отвечает SRP, внутри него может быть такое сцепление, что он сам превратился в несокрушимый монолит с кучей недопустимых состояний.

Для курсантов на прошлой неделе выложил формальную думательную машинку в СильныхИдеях -- как правильно проектировать систему, чтобы в ней таких состояний не возникало. Дальше будет большая тема, в несколько заходов, как понижать coupling/избавляться от зависимостей.

Ну например, нам нравится (ошибочно) думать, что если A не зависит от B, то изменение B не может повлиять на A. Но что если вы измените B таким образом, что появится новая зависимость? Например, если вы измените глобальную переменную, которую использует A?
Разберём 10 видов зависимостей, и как с ними правильно поступать.