Когда вы разрабатываете ТЗ для некоторой системы, есть обязательные мета-требования, подходящие практически к любой предметной области:
- пользователям должны быть везде доступны undo/redo;
- "пакетные" операции на клиенте ("автоматизация" пользовательской работы: макро, настраиваемые хоткеи....);
- управляемая сборка мусора;
- создание моментальных снимков состояния системы (условный сэйв/лоад в любой момент времени, а не то что в автосимуляторах, когда во время гонки невозможно сохраниться);
- синхронизация состояний;
- ребейзинг по истории изменений с возможностью просмотра дифов.

Если вы их не добавите, это значит, что вы создаете софт, которым сами не захотите пользоваться.

Время срочно записывать Carbon в свои скиллы :)

Хорошая новость, что симпатичный курс HighLoad Junior
о котором я говорил недавно: "От организаторов конференции Highload++, и я его раньше рекомендовал. Однако, сервис по обучению highload от мастеров highload сам по себе оказался крайне ненадёжным и очень хрупким :)"
вроде бы ожил: пришла рассылка, в которой (вроде бы) все активные ссылки на материалы наконец-то рабочие.

Правда, highload.guide/blog/ слегка зависает, но это же мелочи для русского хайлоада? :)

Есть ли перспективы у no-code? Нет, абсолютно. Потому что в этой темке не бывает никаких революционных изобретений. Это просто поиск компромиссов между универсальностью и простотой UI, стараясь угодить выбранной рыночной нише. Вдобавок за этим стоит, очевидно, достаточно объёмный код, и этот легаси-хвост сильно затрудняет быструю подстройку под нужды разных клиентов. А агрессивная монетизация даёт в основном саморазрушительный эффект.
Расходимся, в no-code вообще не на что смотреть.

А вот low-code, где есть хотя бы немножечко кодинг, перспективно однозначно. Причём чем визуальнее тут программирование, тем лучше, как в scratch или squeak например -- потому что сегодня это направление очень сильно взлетает и в профессиональной разработке, на моём новом формате занятий "hard work" будем это обязательно изучать.

Если вы не можете записать что-то на русском языке, вы не сможете это запрограммировать.

Дико уважаю:
I started BPS.space almost 7 years ago in the fall of 2015 with the goal to propulsively land a model rocket. I had no background in aero, EE, coding, etc so it took a lot of trial and error, but today I finally stuck the landing

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

Что такое хорошая абстракция? Пока на сегодня лучшее и достаточно формальное определение, которое я нашёл для учебных целей :) такое:
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, только не тупо угадывающая нейросетка, а на основе хорошего движка формального вывода и верификации под капотом.