Залипательное: 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 видов зависимостей, и как с ними правильно поступать.

Концепция динамической архитектуры была формализована Калифорнийским университетом в 1990-е годы. Это когда система уже была построена, но потом её спецификация стала (сильно) меняться, ну и не хотелось бы переделывать всё/многое заново. Финансировали эту работу военные: Rome Laboratory и US Air Force Materiel Command.

В некотором смысле это похоже на инъекцию зависимостей, только когда эти зависимости совсем не зависимости, а условные "объекты", репрезентующие элементы архитектуры. Подозрение, что и Clean Architecture, и DDD, и им подобные родились из этой и подобных научных работ.

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

Разберём этой осенью в СильныхИдеях (после 10 типов зависимостей) соответствующий архитектурный паттерн, он довольно простой, ему достаточно просто следовать "по форме". Конечно, это не универсальный подход, но в немалом числе случаев вполне подходящий (что доказали соответствующие американские проекты по критическим информационным инфраструктурам).

Интересное исследование Microsoft Research "What is it like to program with artificial intelligence?"

Утверждается, что хотя программирование с AI-помощниками наподобие Copilot и имеет некоторую поверхностную схожесть с парным программированием и с "программированием" гуглением + stackoverflow, существуют фундаментальные различия как в техническом потенциале этого подхода, так и в практической работе. Авторы выражаются политкорректно, но засада в том, что когда такими инструментами пользуются разработчики низкой квалификации, то вероятность накосячить сильно вырастает, потому что предлагаемый AI код отнюдь не точный, очень вероятно содержит ошибки, и его надо ещё прилично допиливать, подробно разбираться с ним и т.д. Ну понять-то надо как минимум?

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

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

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

Это кстати в некотором смысле хорошо, и вот почему.

"что делать" -- это фактически тупое обучение на примерах нейросетки в вашей голове. Если хардвер вашего ума от природы мощный (повезло/карма), то пройдя например мой курс обучения программированию с нуля, где вы грузите в свой ум, в свою условную GPT-3, текст теории + решаете сотни задачек + потом разбираете эталонные примеры, вы научитесь достаточно успешно решать задачки соответствующей мощности автоматически. У вас в уме появился Copilot 1-го левела, а так как обученные модельки ресурсы/энергию почти не потребляют, то и решать соответствующие задачки вам удаётся легко.

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

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

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