7 октября вышел наш любимый π-тончик 3.14
В мэйнстриме в основном восхищаются его скоростью, и она действительно хороша: CPython 3.14 топчик, многопоточный интерпретатор здорово допилили под нагрузку, а PyPy летает вообще безумно быстро. Питон по скорости реально начинает конкурировать с нодой, и даже в ряде случаев с растом!
Ну а мне больше всего понравилось вот это =>
Add a built-in implementation for HMAC (Keyed-Hashing for Message Authentication; RFC 2104) using formally verified code from the HACL* project. This implementation is used as a fallback when the OpenSSL implementation of HMAC is not available.
Тренд однако.
В мэйнстриме в основном восхищаются его скоростью, и она действительно хороша: CPython 3.14 топчик, многопоточный интерпретатор здорово допилили под нагрузку, а PyPy летает вообще безумно быстро. Питон по скорости реально начинает конкурировать с нодой, и даже в ряде случаев с растом!
Ну а мне больше всего понравилось вот это =>
Add a built-in implementation for HMAC (Keyed-Hashing for Message Authentication; RFC 2104) using formally verified code from the HACL* project. This implementation is used as a fallback when the OpenSSL implementation of HMAC is not available.
Тренд однако.
Python documentation
What’s new in Python 3.14
Editors, Adam Turner and Hugo van Kemenade,. This article explains the new features in Python 3.14, compared to 3.13. Python 3.14 was released on 7 October 2025. For full details, see the changelog...
🏆36🤔10⚡8❤🔥3🤝2
Заслушался сказок классный прошлогодний видосик "Why Vlad Tenev and Tudor Achim of Harmonic Think AI Is About to Change Math—and Why It Matters"
где два пацанчика пиарят свой Mathematical Superintelligence :)
Harmonic: AI for Formal Mathematical Reasoning
С тех пор они подорожали раз в 10, почти до миллиарда долларов.
Ну, да, 90% в задачках MiniF2F, золотая медаль на IMO 2025 (5 из 6) и т.д.
Ну, да, оба со стэнфордским образованием, один даже у Тао учился, хотя потом сразу ушли в IT-AI-бизнес (беспилотные машинки и прочая попса...).
Ну, да, прикрутили теорем-прувер (завтипчики) Lean4.
Хотя так-то на выходе у них как не было ничего, так и нету что потрогать вживую. Только красивый пиар :)
Вакансия их понравилось: Part-time Lean Expert. Яб пошёл.
Фронт ищут под Expo (классная кстати кросс-платформная либа, не знал про такую)
А Research Engineer, Formal Methods вот на фуллтайм.
The initial focus of this position will be on advancing mathematical theorem proving using cutting-edge AI techniques. The successful candidate will play a key role in developing new algorithms and models that integrate AI with formal methods to solve complex problems in theorem proving and beyond.
Apply formal verification techniques using Lean or similar frameworks to formally verify safety critical systems
А решатели свои они пишут на плюсах: 17 из 30 сложных геометрических задач в AG-30 решены за 0.4 секунды на одном ядре 3.1 ГГц, и кодера тоже ищут (но и Python обязателен; у меня в Лаборатории теперь, кстати, тоже :).
Да, но...
For a while during the IMO, we had nearly 500,000 CPUs running Lean code at the same time with 95-100% utilization, which shows that the solution we built worked.
Вообще у них действительно немало больших и сложных научных(?) статей, где они типа достаточно подробно разбирают свои подходы, хотя подобные тексты сегодня не сложно генерить с хорошим AI, всё равно никто ничего не разберёт :)
Например свежак Aristotle: IMO-level Automated Theorem Proving
Мои 2 коп что их система смотрится уж слишком многоуровневой и перегруженной, с кучей слоёв абстракций. Сами судите:
- LLM-ка, обученная на Lean/SMT
- proof-search agent с деревом поиска и тактиками (имхо, самая слабая часть всей архитектуры - это архитектура самого Lean4, прежде всего концепция тактик)
- интеграция с лином через JSON-RPC
- версионированный датапайплайн self-play/self-mining
- RL с обратной связью от пруф-ассистента
- кэш фактов, бустинг через эвристики выбора лемм
- IDE-оболочка: чат, редактор с подсветкой, step-through доказательств, интеграция с Lean infoview
...
Главные вопросики:
- долгий и дорогой proof‑search + kernel‑check, возможно ли в принципе масштабировать на реальные кодобазы хотя бы в десятки тысяч строк кода?
- хрупкость по версии/ядру/тактикам Lean 4, да и сама его хилая экосистема и слабенькие датасеты вне mathlib
Ну и в целом насколько вообще переносятся "скиллы" решения математических задач на формальную верификацию? Получится ли хоть что-то перенести из хорошо формализованных задачек MiniF2F в суровый прод, тем более КИИ?
Так-то пайпу "Lean + генерация verification conditions + SMT/модел-чекинг" в принципе должно быть пофиг, что задачки, что верификация, но без очень мощного инженерного моста тут не обойтись, а в их проекте и так уже дофига всего накручено.
Наблюдение продолжаю 😎
где два пацанчика пиарят свой Mathematical Superintelligence :)
Harmonic: AI for Formal Mathematical Reasoning
С тех пор они подорожали раз в 10, почти до миллиарда долларов.
Ну, да, 90% в задачках MiniF2F, золотая медаль на IMO 2025 (5 из 6) и т.д.
Ну, да, оба со стэнфордским образованием, один даже у Тао учился, хотя потом сразу ушли в IT-AI-бизнес (беспилотные машинки и прочая попса...).
Ну, да, прикрутили теорем-прувер (завтипчики) Lean4.
Хотя так-то на выходе у них как не было ничего, так и нету что потрогать вживую. Только красивый пиар :)
Вакансия их понравилось: Part-time Lean Expert. Яб пошёл.
Фронт ищут под Expo (классная кстати кросс-платформная либа, не знал про такую)
А Research Engineer, Formal Methods вот на фуллтайм.
The initial focus of this position will be on advancing mathematical theorem proving using cutting-edge AI techniques. The successful candidate will play a key role in developing new algorithms and models that integrate AI with formal methods to solve complex problems in theorem proving and beyond.
Apply formal verification techniques using Lean or similar frameworks to formally verify safety critical systems
А решатели свои они пишут на плюсах: 17 из 30 сложных геометрических задач в AG-30 решены за 0.4 секунды на одном ядре 3.1 ГГц, и кодера тоже ищут (но и Python обязателен; у меня в Лаборатории теперь, кстати, тоже :).
Да, но...
For a while during the IMO, we had nearly 500,000 CPUs running Lean code at the same time with 95-100% utilization, which shows that the solution we built worked.
Вообще у них действительно немало больших и сложных научных(?) статей, где они типа достаточно подробно разбирают свои подходы, хотя подобные тексты сегодня не сложно генерить с хорошим AI, всё равно никто ничего не разберёт :)
Например свежак Aristotle: IMO-level Automated Theorem Proving
Мои 2 коп что их система смотрится уж слишком многоуровневой и перегруженной, с кучей слоёв абстракций. Сами судите:
- LLM-ка, обученная на Lean/SMT
- proof-search agent с деревом поиска и тактиками (имхо, самая слабая часть всей архитектуры - это архитектура самого Lean4, прежде всего концепция тактик)
- интеграция с лином через JSON-RPC
- версионированный датапайплайн self-play/self-mining
- RL с обратной связью от пруф-ассистента
- кэш фактов, бустинг через эвристики выбора лемм
- IDE-оболочка: чат, редактор с подсветкой, step-through доказательств, интеграция с Lean infoview
...
Главные вопросики:
- долгий и дорогой proof‑search + kernel‑check, возможно ли в принципе масштабировать на реальные кодобазы хотя бы в десятки тысяч строк кода?
- хрупкость по версии/ядру/тактикам Lean 4, да и сама его хилая экосистема и слабенькие датасеты вне mathlib
Ну и в целом насколько вообще переносятся "скиллы" решения математических задач на формальную верификацию? Получится ли хоть что-то перенести из хорошо формализованных задачек MiniF2F в суровый прод, тем более КИИ?
Так-то пайпу "Lean + генерация verification conditions + SMT/модел-чекинг" в принципе должно быть пофиг, что задачки, что верификация, но без очень мощного инженерного моста тут не обойтись, а в их проекте и так уже дофига всего накручено.
Наблюдение продолжаю 😎
❤36😎12✍3🐳3
Будь у меня миллиард миллион долларов рублей,
я бы прежде всего конечно перенёс мой HoTT/кубический движок на питончик 3.14, уже имея в отличие от стэнфордских пацанов
- тесную интеграцию со всем стеком PyTorch/JAX/NumPy -- для обучения тактик, ретривера лемм, RL с фидбэком от проверяющего ядра;
- полный контроль над trusted kernel/аксиоматикой HoTT (Univalence, HITs, кубические Сигмы, Kan-композиция) + быстрые эксперименты;
- гибкую архитектуру термов (de Bruijn/HOAS);
- программируемую генерацию синтетики: пути/ кубы/системы → мощные датасеты и property-based тестирование "из коробки".
Дальше,
- допиливаем кэширование/мемоизацию, тонкое профилирование (py-spy, tracers),
- легко и просто склеиваем с SMT/ATP (z3-solver, cvc5);
- добавляем нейросимволические циклы Generate→Check→Learn на одном Питоне!!1 Трассы поиска/ошибки элаборации/метаданные обучающих эпизодов -- у меня все под руками прямо в Py.
Фигак фигак и в прод: notebooks с визуализацией кубиков, REST/gRPC, и деплой через pip/docker без кривейшего тулчейна Lean.
я бы прежде всего конечно перенёс мой HoTT/кубический движок на питончик 3.14, уже имея в отличие от стэнфордских пацанов
- тесную интеграцию со всем стеком PyTorch/JAX/NumPy -- для обучения тактик, ретривера лемм, RL с фидбэком от проверяющего ядра;
- полный контроль над trusted kernel/аксиоматикой HoTT (Univalence, HITs, кубические Сигмы, Kan-композиция) + быстрые эксперименты;
- гибкую архитектуру термов (de Bruijn/HOAS);
- программируемую генерацию синтетики: пути/ кубы/системы → мощные датасеты и property-based тестирование "из коробки".
Дальше,
- допиливаем кэширование/мемоизацию, тонкое профилирование (py-spy, tracers),
- легко и просто склеиваем с SMT/ATP (z3-solver, cvc5);
- добавляем нейросимволические циклы Generate→Check→Learn на одном Питоне!!1 Трассы поиска/ошибки элаборации/метаданные обучающих эпизодов -- у меня все под руками прямо в Py.
Фигак фигак и в прод: notebooks с визуализацией кубиков, REST/gRPC, и деплой через pip/docker без кривейшего тулчейна Lean.
1❤36🔥17⚡5
Встретил сегодня этот мем и вспомнил в тему вчерашние посты.
Aristotle (an AI system that combines formal verification with informal reasoning, achieving gold-medal-equivalent performance on the 2025 International Mathematical Olympiad problems) так-то внутри использует Монте-Карло, Карл!
пруф: "Aristotle: IMO-level Automated Theorem Proving"
Ну, да, Monte Carlo Graph Search вместо традиционного MCTS, когда разные пути могут приходить в один и тот же proof state (т.к. Lean-цели часто повторяются и можно избежать комбинаторного взрыва из-за дублирования узлов + легче распараллеливать), но нету никакой математической гарантии найти глобально оптимальную (минимальную) последовательность тактик. Цель MCGS -- найти хоть какое-то корректное доказательство...
Вот тебе, бабушка, Mathematical Superintelligence и формальные рассуждения...
Aristotle (an AI system that combines formal verification with informal reasoning, achieving gold-medal-equivalent performance on the 2025 International Mathematical Olympiad problems) так-то внутри использует Монте-Карло, Карл!
пруф: "Aristotle: IMO-level Automated Theorem Proving"
Ну, да, Monte Carlo Graph Search вместо традиционного MCTS, когда разные пути могут приходить в один и тот же proof state (т.к. Lean-цели часто повторяются и можно избежать комбинаторного взрыва из-за дублирования узлов + легче распараллеливать), но нету никакой математической гарантии найти глобально оптимальную (минимальную) последовательность тактик. Цель MCGS -- найти хоть какое-то корректное доказательство...
Вот тебе, бабушка, Mathematical Superintelligence и формальные рассуждения...
❤43✍9😁1😇1
...Но с другой стороны, давайте будем максимально честными: нафига нам "свой прувер"? Чтобы получилось точно такая же ситуация, как и со "свой игровой движок" -- потратим миллиарды, а на выходе карго-культ?
Причём ещё ладно если так, а если это будет что-то существенно хуже работающее, чем существующий опенсорс, и к нему будут принуждать насильно? Тогда вместо формальной верификации наши КИИ получат ужасающее количество бэкдоров :)
И главное, а кто это будет делать-то? Последний наш мировой спец по HoTT уехал в Европу в 2023-м, а тут требуется не только топовая математика, но и мощнейший инженерный бэкграунд, чтобы не получился в итоге ещё более слабый клон Lean4 (который сам по себе кривейший и архитектурно и концептуально).
...Впрочем, а я-то чего об этом волнуюсь? Я в этих темах никто, и звать меня никак. С моей стороны это чисто научпоп. Поэтому, надо просто принять и простить, что Lean4 стал на сегодня в отрасли фактически промышленным стандартом. Да, очень кривейшим, примерно как Java на фоне нормальных языков, но лучше-то нету! Ну, Coq/Rocq, Agda, F*, но они уже очень сильно отстают просто потому, что в лине есть мощнейшая mathlib, куда уже впилили кучу математики, и продолжают активно накачивать.
Поэтому надеюсь, что свой прувер у нас делать не будут, потому что без матлибы он будет пшиком... Ну ок, можно делать синтаксически совместимым с лином, это значит и потащить за собой все его кривые фичи. Или писать свой конвертер, который ещё надо формально верифицировать, и т.д. и т.п.
Всё, поезд ушёл.
В связи с вышеизложенным с глубоким прискорбием вынужден сообщить, что я буду обучать (вас:) Lean4, коли даже стартапы чётко под него собирают по миллиарду долларов. И, конечно, это musthave, если вы математик и хотите укатить в европы америки...
Причём ещё ладно если так, а если это будет что-то существенно хуже работающее, чем существующий опенсорс, и к нему будут принуждать насильно? Тогда вместо формальной верификации наши КИИ получат ужасающее количество бэкдоров :)
И главное, а кто это будет делать-то? Последний наш мировой спец по HoTT уехал в Европу в 2023-м, а тут требуется не только топовая математика, но и мощнейший инженерный бэкграунд, чтобы не получился в итоге ещё более слабый клон Lean4 (который сам по себе кривейший и архитектурно и концептуально).
...Впрочем, а я-то чего об этом волнуюсь? Я в этих темах никто, и звать меня никак. С моей стороны это чисто научпоп. Поэтому, надо просто принять и простить, что Lean4 стал на сегодня в отрасли фактически промышленным стандартом. Да, очень кривейшим, примерно как Java на фоне нормальных языков, но лучше-то нету! Ну, Coq/Rocq, Agda, F*, но они уже очень сильно отстают просто потому, что в лине есть мощнейшая mathlib, куда уже впилили кучу математики, и продолжают активно накачивать.
Поэтому надеюсь, что свой прувер у нас делать не будут, потому что без матлибы он будет пшиком... Ну ок, можно делать синтаксически совместимым с лином, это значит и потащить за собой все его кривые фичи. Или писать свой конвертер, который ещё надо формально верифицировать, и т.д. и т.п.
Всё, поезд ушёл.
В связи с вышеизложенным с глубоким прискорбием вынужден сообщить, что я буду обучать (вас:) Lean4, коли даже стартапы чётко под него собирают по миллиарду долларов. И, конечно, это musthave, если вы математик и хотите укатить в европы америки...
🤔34✍12❤5🤯4
Ну и что тут непонятного, если вы проходили мой курс по ФП на F# ?
(а тем более, если трек по HoTT :)
Это малышовый пример по монадам со Стэнфордского курса
"CS 99: Functional Programming and Theorem Proving in Lean 4"
Вот что примерно будем делать(похищаю смыслы:) =>
The course project involves formalizing a non-trivial piece of mathematics or computer science in Lean 4.
(Easy) Formalize a solution to a (at least undergraduate level) textbook math or CS problem
(Medium) Formalize a board game that has not been done before. e.g. chess. The formalization should be at a level where it is possible to prove winning conditions.
(Medium) Formalize program verification primitives
(Medium) Formalize natural languages
(Hard) Contribute to Mathlib4 or other Lean formalization libraries
(Hard) Fix a Lean bug
Скоро будете у меня круче Гарварда-Стэнфорда :)
Техлиды, заглянув в ваш гитхаб, будут шептать "что ты такое??" :)
(а тем более, если трек по HoTT :)
Это малышовый пример по монадам со Стэнфордского курса
"CS 99: Functional Programming and Theorem Proving in Lean 4"
Вот что примерно будем делать
The course project involves formalizing a non-trivial piece of mathematics or computer science in Lean 4.
(Easy) Formalize a solution to a (at least undergraduate level) textbook math or CS problem
(Medium) Formalize a board game that has not been done before. e.g. chess. The formalization should be at a level where it is possible to prove winning conditions.
(Medium) Formalize program verification primitives
(Medium) Formalize natural languages
(Hard) Contribute to Mathlib4 or other Lean formalization libraries
(Hard) Fix a Lean bug
Скоро будете у меня круче Гарварда-Стэнфорда :)
Техлиды, заглянув в ваш гитхаб, будут шептать "что ты такое??" :)
😁41❤12⚡4🏆1
Что такое мэйнстрим? Это бессистемное множество абстракций, каждая из которых "упрощает" разработку для глупеньких, но увеличивает накладные расходы.
Типа,
React → API Gateway → Spring Boot → Docker → Kubernetes → VM → СУБД
Каждый слой добавляет "всего 20-30-50...%", и вот вы уже получили в 3-10 раз больше затрат на то же самое поведение.
Вот почему в системах, созданных мэйнстримом, утечка ресурсов (например, слив десятков гигов оперативки) это норм. Не потому, что кто-то специально наговнокодил (хотя и не без этого), а в основном потому, что никто не замечал совокупных затрат, пока пользователи не начали жаловаться.
Типа,
React → API Gateway → Spring Boot → Docker → Kubernetes → VM → СУБД
Каждый слой добавляет "всего 20-30-50...%", и вот вы уже получили в 3-10 раз больше затрат на то же самое поведение.
Вот почему в системах, созданных мэйнстримом, утечка ресурсов (например, слив десятков гигов оперативки) это норм. Не потому, что кто-то специально наговнокодил (хотя и не без этого), а в основном потому, что никто не замечал совокупных затрат, пока пользователи не начали жаловаться.
❤🔥30💯17👏8🤔6❤3
Вот чем в частности станем заниматься: будем формализовывать интуицию, которая по определению просто какая-то бессистемная мешанина случайно нахватанных знаний by examples. Глупенькая индукция: если некоторые части решения покрыты тестами (кусочками опыта, вайб-кодом...), "следовательно" оно верное в целом. Ага.
Делаем такое (с)мутное понимание эксплицитным, что даёт возможность за счёт непрерывного фидбэка его невероятно прокачивать вообще без пределов!!1
Как профессиональный пианист с консерваторским образованием может легко и просто играть любую музыку, так ты после гайдов с практикой на Lean4 сможешь уверенно выстраивать сложнейшие композиции паттернов/абстракций в любом языке, где есть минимальная поддержка функционального стиля (Python, C#, Java, PHP :).
Что имею в виду: джун в голове может удерживать одновременно 2-3 абстракции, может их скомпозировать на 1-2 уровня, а о том, что есть математические правила композиции, даже и не знает(ну, если только не занимался в моей Лаборатории :) . На отладку такой композиции тратит до 8 часов.
Миддл: 4-7 абстракций, 3-4 уровня композиции. Знает, что есть какие-то правила, но не всегда помнит, какие именно подойдут в той или иной ситуации. На создание/отладку - 4 часа.
Сеньор: 6-9 абстракций, 4-7 уровней композиции. Понимание законов: 30-50% (знает основные, интуитивно применяет). В основном методом проб и ошибок, рефакторинг может сломать его художества легко и просто. На создание/отладку - 1.5-2 часа.
Лаборатория: 10-15++ абстракций, 8-10++ уровней композиции. Понимание законов: 90-95% (можешь доказать, почему работает). И создаёшь такое буквально в режиме непрерывного набора текста, за полчаса.
На картинках: максимально простой детский учебный пример, уровень джуна ))) Reader, State и Except.
Спека на лине, и рабочий код на F#.
А самое главное, что вы получите суперсилу и станете AI-повелителем: сможете уверенно проектировать систему любой сложности через подобные композиции чистых функций, каждая из которых задаётся формальной (и полностью доказанной при желании) спецификацией, и соответственно LLM-ка пишет по ней гарантированно безошибочный код (вдобавок, это легко распраллеливается).
Свежие прогнозы, что к концу текущего десятилетия 90% кода будет писано AI, и думаю, это реально. Главный вопрос, какой процент архитектуры, software design будет приходиться на долю AI :) Полагаю, он будет резко падать по мере роста проекта. 3-5 тысяч строк кода standalone-система - ну возможно, AI потянет архитектуру. Десятки тысяч строк -- уже почти невероятно, сотни тысяч - фактически нет.
В этом плане крайне показательно, что AI (ЖПТ5Кодер) совсем слабенько пишет код на лине. После десятка подсказок еле-еле выдаёт что-то работающее более-менее сложное. А Клод4.5, что удивительно, вообще не тянет, ну совсем практически. Не способны они в принципе мыслить проектными абстракциями :)
Чем мне крайне нравится такой подход? Тем, что он впервые в мире в обучении сложным темкам в проектировании даёт гарантированный критерий правильности решения (за счёт сильной системы типов). Условно говоря, программа либо "компилируется" (доказывается, что она гарантированно правильная), и её можно использовать, либо нет (неработающая).
Я мечтал об этом давно, но вот только сейчас понял, как это сделать. Благодаря Филдсовскому лауреату Теренсу Тао, кстати, инсайт был после его подкаста "Terence Tao: Hardest Problems in Mathematics, Physics & the Future of AI" (есть автоматическая озвучка на русском).
Делаем такое (с)мутное понимание эксплицитным, что даёт возможность за счёт непрерывного фидбэка его невероятно прокачивать вообще без пределов!!1
Как профессиональный пианист с консерваторским образованием может легко и просто играть любую музыку, так ты после гайдов с практикой на Lean4 сможешь уверенно выстраивать сложнейшие композиции паттернов/абстракций в любом языке, где есть минимальная поддержка функционального стиля (Python, C#, Java, PHP :).
Что имею в виду: джун в голове может удерживать одновременно 2-3 абстракции, может их скомпозировать на 1-2 уровня, а о том, что есть математические правила композиции, даже и не знает
Миддл: 4-7 абстракций, 3-4 уровня композиции. Знает, что есть какие-то правила, но не всегда помнит, какие именно подойдут в той или иной ситуации. На создание/отладку - 4 часа.
Сеньор: 6-9 абстракций, 4-7 уровней композиции. Понимание законов: 30-50% (знает основные, интуитивно применяет). В основном методом проб и ошибок, рефакторинг может сломать его художества легко и просто. На создание/отладку - 1.5-2 часа.
Лаборатория: 10-15++ абстракций, 8-10++ уровней композиции. Понимание законов: 90-95% (можешь доказать, почему работает). И создаёшь такое буквально в режиме непрерывного набора текста, за полчаса.
На картинках: максимально простой детский учебный пример, уровень джуна ))) Reader, State и Except.
Спека на лине, и рабочий код на F#.
А самое главное, что вы получите суперсилу и станете AI-повелителем: сможете уверенно проектировать систему любой сложности через подобные композиции чистых функций, каждая из которых задаётся формальной (и полностью доказанной при желании) спецификацией, и соответственно LLM-ка пишет по ней гарантированно безошибочный код (вдобавок, это легко распраллеливается).
Свежие прогнозы, что к концу текущего десятилетия 90% кода будет писано AI, и думаю, это реально. Главный вопрос, какой процент архитектуры, software design будет приходиться на долю AI :) Полагаю, он будет резко падать по мере роста проекта. 3-5 тысяч строк кода standalone-система - ну возможно, AI потянет архитектуру. Десятки тысяч строк -- уже почти невероятно, сотни тысяч - фактически нет.
В этом плане крайне показательно, что AI (ЖПТ5Кодер) совсем слабенько пишет код на лине. После десятка подсказок еле-еле выдаёт что-то работающее более-менее сложное. А Клод4.5, что удивительно, вообще не тянет, ну совсем практически. Не способны они в принципе мыслить проектными абстракциями :)
Чем мне крайне нравится такой подход? Тем, что он впервые в мире в обучении сложным темкам в проектировании даёт гарантированный критерий правильности решения (за счёт сильной системы типов). Условно говоря, программа либо "компилируется" (доказывается, что она гарантированно правильная), и её можно использовать, либо нет (неработающая).
Я мечтал об этом давно, но вот только сейчас понял, как это сделать. Благодаря Филдсовскому лауреату Теренсу Тао, кстати, инсайт был после его подкаста "Terence Tao: Hardest Problems in Mathematics, Physics & the Future of AI" (есть автоматическая озвучка на русском).
2❤35✍13👍6❤🔥1
Сами задачки на композицию в Lean4 -- это по сути логические паззлы в чистом виде! Но чётко заточенные под скилл software design, вдобавок при их решении целевым образом качаем профильную когнитивку! Я много изучал десятки тренажёров "развитие внимательности, памяти, ...", коих в сети немеряно, но таких что хоть немного подходили бы программистской работе, и близко не встречал. А тут такая удача.
...Но есть две мааалюсенькие проблемки :)
1. В создании соответствующих задачек, конкретно под темку software design, никакой AI, к сожалению не поможет. Практика показала, что он в основном больше вредит :) Проблема чисто техническая, просто потребуется вложить существенно больше времени (увы).
2. Платформа (Lean4) тоже имеет определённое значение. В частности большой вопрос, какие теории типов поддерживает прувер. Lean4 например не способен в HoTT из-за своего кривого ядра вывода. Ну и экосистема имеет значение: похоже, Лин взял всё самое худшее из экосистемы Хаскеля :) Попробуйте например собрать Mathlib в винде.
Поэтому сами задачки мне придётся сперва делать в некоторой мета-теории, без привязки к конкретным теорем-пруверам или языкам с зависимыми типами, чтобы их (как "реализацию" без изменения интерфейсов) можно было безболезненно заменять в случае чего. Можно теоркат (симплициальные ∞-категории), можно кубическую теорию типов, благо я сделал её "реализацию"...
Насколько это всё сложно в плане понимания? Ну, смотрю разные математические семинары, это например третий курс мехмата НГУ.
...Но есть две мааалюсенькие проблемки :)
1. В создании соответствующих задачек, конкретно под темку software design, никакой AI, к сожалению не поможет. Практика показала, что он в основном больше вредит :) Проблема чисто техническая, просто потребуется вложить существенно больше времени (увы).
2. Платформа (Lean4) тоже имеет определённое значение. В частности большой вопрос, какие теории типов поддерживает прувер. Lean4 например не способен в HoTT из-за своего кривого ядра вывода. Ну и экосистема имеет значение: похоже, Лин взял всё самое худшее из экосистемы Хаскеля :) Попробуйте например собрать Mathlib в винде.
Поэтому сами задачки мне придётся сперва делать в некоторой мета-теории, без привязки к конкретным теорем-пруверам или языкам с зависимыми типами, чтобы их (как "реализацию" без изменения интерфейсов) можно было безболезненно заменять в случае чего. Можно теоркат (симплициальные ∞-категории), можно кубическую теорию типов, благо я сделал её "реализацию"...
Насколько это всё сложно в плане понимания? Ну, смотрю разные математические семинары, это например третий курс мехмата НГУ.
❤36👍12⚡6✍1
.
Облако драгоценностей за неделю.
Для донов-начинающих:
На 98%, конечно, программирование — это просто ...
В мире конкуренции препятствия — ваш союзник. Чем труднее они, тем выше ваши шансы избавиться от конкурентов :) Если же эти препятствия заставляют и вас отступить, что ж, выходит, всё было зря...
Для донов-неначинающих:
Меня всегда поражало, сколь многого человек может достичь, если просто...
Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
58. О вреде форматов сериализации
Структуры данных, определяемые на языках вроде IDL и его расширения OpenAPI, или в конфигурационных файлах -- это формат сериализации. Но формат сериализации не имеет никакого отношения к модели данных проекта!..
59. Что делает тест хорошим
Есть прекрасная теория тестирования, которая объясняет, что делают тесты, что должно и что не должно проверяться при тестировании. Увы, это удивительно, но эта теория практически не была представлена в общедоступном виде для массовых разработчиков, хотя я подозреваю, что определённое количество инженеров, применяющих подходы из формальной верификации, имеют достаточно чёткое представление об этом...
(все старые материалы для донов постепенно сгорают)
=
Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
🚀
=
Новые материалы для ментатов Лаборатории.
В курс карьеры добавлен 115-й материал "Выбираем правильный путь для карьеры и жизни".
Вот главный урок, который я подсознательно усваивал на протяжении нескольких десятков лет своей карьеры, преодолевая бесчисленные оплошности и моменты сомнений (и только в последние годы я по-настоящему начал прислушиваться к своим собственным знаниям и советам, чему невероятно рад :)...
Python на сервере обновлён до 3.14 (и всем рекомендую перейти на эту версию).
В раздел "Элитный программист" добавлен материал
78) Почему Pomodoro -- лучшая техника для работы!
Почему техника помидорок структурирована именно так? Почему она состоит из 25-минутных фрагментов работы? На чём она основана на самом деле?
Продолжительность продуктивных циклов в Помодоро определяется двумя факторами...
💪🏻
Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.
=
Облако драгоценностей за неделю.
Для донов-начинающих:
На 98%, конечно, программирование — это просто ...
В мире конкуренции препятствия — ваш союзник. Чем труднее они, тем выше ваши шансы избавиться от конкурентов :) Если же эти препятствия заставляют и вас отступить, что ж, выходит, всё было зря...
Для донов-неначинающих:
Меня всегда поражало, сколь многого человек может достичь, если просто...
Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
58. О вреде форматов сериализации
Структуры данных, определяемые на языках вроде IDL и его расширения OpenAPI, или в конфигурационных файлах -- это формат сериализации. Но формат сериализации не имеет никакого отношения к модели данных проекта!..
59. Что делает тест хорошим
Есть прекрасная теория тестирования, которая объясняет, что делают тесты, что должно и что не должно проверяться при тестировании. Увы, это удивительно, но эта теория практически не была представлена в общедоступном виде для массовых разработчиков, хотя я подозреваю, что определённое количество инженеров, применяющих подходы из формальной верификации, имеют достаточно чёткое представление об этом...
(все старые материалы для донов постепенно сгорают)
=
Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
🚀
=
Новые материалы для ментатов Лаборатории.
В курс карьеры добавлен 115-й материал "Выбираем правильный путь для карьеры и жизни".
Вот главный урок, который я подсознательно усваивал на протяжении нескольких десятков лет своей карьеры, преодолевая бесчисленные оплошности и моменты сомнений (и только в последние годы я по-настоящему начал прислушиваться к своим собственным знаниям и советам, чему невероятно рад :)...
Python на сервере обновлён до 3.14 (и всем рекомендую перейти на эту версию).
В раздел "Элитный программист" добавлен материал
78) Почему Pomodoro -- лучшая техника для работы!
Почему техника помидорок структурирована именно так? Почему она состоит из 25-минутных фрагментов работы? На чём она основана на самом деле?
Продолжительность продуктивных циклов в Помодоро определяется двумя факторами...
💪🏻
Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.
=
❤33👍11
Давайте будем честны: быть программистом с быстрым, творческим умом, движимым сильными идеями -- это одновременно и благословение, и проклятие.
Бывают дни, когда тебя невозможно остановить.
В другие дни кажется, что ты работаешь в два раза усерднее, а успеваешь сделать в два раза меньше.
Если что-то из этого покажется вам знакомым…
Посмотрите, сколько этих пунктов для вас верны:
У вас больше идей, чем вы могли бы когда-либо воплотить в жизнь.
Вы начинаете успешно работать над проектами, но с трудом доводите их до конца.
Вы работаете допоздна, но ваши самые большие цели так и не достигаются.
Вы легко отвлекаетесь и теряете многие часы на "срочные" задачи.
Вы изо всех сил стараетесь оставаться последовательным, но мотивация приходит и уходит волнами.
Вы часто чувствуете вину за то, что делаете недостаточно, даже когда вымотаны.
Вы полагаетесь на всплески энергии… за которыми следуют сбои и эмоциональное выгорание.
Вы постоянно меняете инструменты, методики и стратегии в погоне за чем-то, что в конце концов, возможно, приживется.
Иногда вы задаётесь вопросом: "Почему я не могу просто делать то, что, как я знаю, мне нужно делать?"
В глубине души вы чувствуете, что способны на гораздо большее, но, похоже, не можете раскрыть это.
Если вы ответили "да" хотя бы на несколько из них… нет, вы не сломлены.
Вы просто управляете невероятно мощным мозгом без подходящей операционной системы.
А чтобы её себе инсталлировать, вам нужно заняться математикой и computer science! В частности, научиться глубокой функциональной композиции на языках λ-куба Барендрегта.
Бывают дни, когда тебя невозможно остановить.
В другие дни кажется, что ты работаешь в два раза усерднее, а успеваешь сделать в два раза меньше.
Если что-то из этого покажется вам знакомым…
Посмотрите, сколько этих пунктов для вас верны:
У вас больше идей, чем вы могли бы когда-либо воплотить в жизнь.
Вы начинаете успешно работать над проектами, но с трудом доводите их до конца.
Вы работаете допоздна, но ваши самые большие цели так и не достигаются.
Вы легко отвлекаетесь и теряете многие часы на "срочные" задачи.
Вы изо всех сил стараетесь оставаться последовательным, но мотивация приходит и уходит волнами.
Вы часто чувствуете вину за то, что делаете недостаточно, даже когда вымотаны.
Вы полагаетесь на всплески энергии… за которыми следуют сбои и эмоциональное выгорание.
Вы постоянно меняете инструменты, методики и стратегии в погоне за чем-то, что в конце концов, возможно, приживется.
Иногда вы задаётесь вопросом: "Почему я не могу просто делать то, что, как я знаю, мне нужно делать?"
В глубине души вы чувствуете, что способны на гораздо большее, но, похоже, не можете раскрыть это.
Если вы ответили "да" хотя бы на несколько из них… нет, вы не сломлены.
Вы просто управляете невероятно мощным мозгом без подходящей операционной системы.
А чтобы её себе инсталлировать, вам нужно заняться математикой и computer science! В частности, научиться глубокой функциональной композиции на языках λ-куба Барендрегта.
107👍42❤16🫡7💯2❤🔥1
Как делают игры. Краткая история.
2000 год - идут от технологий.
2008 - от картинки.
2016 - от сценария.
2025 - да вообще всё пофиг.
Сегодня в геймдеве сложилась крайне парадоксальная ситуация. Про то, что gamedev и в частности инди-разработка мертвы, я слышу стабильно лет 20 :) Собственно и топлю за эту тему многие годы ровно потому, что это хоть и очень маленький, но совершенно реальный шанс обычному разработчику соло заработать условный миллион долларов.
Так вот, необычность сегодняшней ситуации в том, что внезапно стали хорошо продаваться игры, сделанные на коленке в буквальном смысле. При том, что их дизайн откровенно 🤮
😁
Первой и самой известной в этом тренде стала, пожалуй, Vampire Survivors
Но вот сентябрьский свежак: Megabonk, в духе VS, только 3D.
Миллион продаж! Разработчики игру (справедливо) захейтили, но а вам-то кто мешал подобное сделать? Страх, что "не выстрелит"? Ну, шанс точно повыше, чем в лотерее.
Вот ещё (и везде кооп!) демки на многие сотни тысяч вишлистов (и будут миллионы продаж), с графикой 20-летней давности из каких-то бесплатных ассетов:
Misery (сделал 19-летний парнишка) постапокал
Final Sentence на скорость печати
Yapyap совместный штурм башни архимага
...
Я хз почему так; наверняка появятся умные статьи, которые всё разберут и "пояснят"... да только грош им цена, если авторы не докажут верность своих тезисов аналогичным успехом :)
2000 год - идут от технологий.
2008 - от картинки.
2016 - от сценария.
2025 - да вообще всё пофиг.
Сегодня в геймдеве сложилась крайне парадоксальная ситуация. Про то, что gamedev и в частности инди-разработка мертвы, я слышу стабильно лет 20 :) Собственно и топлю за эту тему многие годы ровно потому, что это хоть и очень маленький, но совершенно реальный шанс обычному разработчику соло заработать условный миллион долларов.
Так вот, необычность сегодняшней ситуации в том, что внезапно стали хорошо продаваться игры, сделанные на коленке в буквальном смысле. При том, что их дизайн откровенно 🤮
😁
Первой и самой известной в этом тренде стала, пожалуй, Vampire Survivors
Но вот сентябрьский свежак: Megabonk, в духе VS, только 3D.
Миллион продаж! Разработчики игру (справедливо) захейтили, но а вам-то кто мешал подобное сделать? Страх, что "не выстрелит"? Ну, шанс точно повыше, чем в лотерее.
Вот ещё (и везде кооп!) демки на многие сотни тысяч вишлистов (и будут миллионы продаж), с графикой 20-летней давности из каких-то бесплатных ассетов:
Misery (сделал 19-летний парнишка) постапокал
Final Sentence на скорость печати
Yapyap совместный штурм башни архимага
...
Я хз почему так; наверняка появятся умные статьи, которые всё разберут и "пояснят"... да только грош им цена, если авторы не докажут верность своих тезисов аналогичным успехом :)
❤49👏10
Есть вечная двойственность в продвинутом обучении программированию...
С одной стороны, мы можем сперва мощно прокачивать свою базу (базу в смысле Старкрафта/Варкрафта :), а затем выполнять молниеносный успешный раш вообще на любую проблему. Например прокачавшись как следует в профильной математике, в том же функциональном комбинировании -- развив пресловутое сильное рациональное мышление -- мы будем видеть любые повседневные архитектурные схемы как задачки для третьего класса, которые решаются просто в режиме непрерывного набора идеально работающего кода (Make Illegal States Unrepresentable) даже без особого думания на медленном мышлении S2 по Канеману. Главный минус -- для этого требуется существенное время, и имеет ли ради этого жертвовать несколькими годами карьеры, вопрос открытый.
На другом конце спектра раньше был такой тупой хак, что можно было отшлифовать один стек -- даже один фреймворк, даже его конкретную версию -- не умея особо кодить (физически не умея решать задачки уровня инвертирования связного списка), и влететь в айти. Теперь он к счастью сдулся, хотя совсем не исключено, что с явлением вайб-кодинга снова возродится.
Противоположное Computer Science сегодня -- это когда надо хорошо знать System Design, но тоже больше на уровне "зазубрить шаблоны" и скомбинировать десяток "квадратиков" на диаграмме (и хорошо ещё, если это C4). Уметь красиво рассказать на собесе "как написать свой нетфликс", для чего достаточно изучить три гайда (но технические знания конечно должны быть на уровне). Главный минус -- в результате имеем совсем узенькое системное мышление, крайне хрупкое понимание, сразу ломается на новом проекте, где на 15% другой стек, даже CRUD фиг перенесёшь. Но зато быстро.
=
Ну, так-то меня интересуют исключительно ментаты Лаборатории, есть хорошее понимание уровня их понимания, и их нужды. Тут моя задача конкретная:
повысить производственное мастерство x10..x100, не прокачивая скиллы.
База в cs конечно нужна, но тут вполне достаточно 3-4 первых треков второй части Лаборатории. Более теоретические темки буду постепенно добавлять однозначно (языки вроде Lean4 всё же тяжеловато ребятам осваивать, если в хороших университетах не обучались... хотя вот в SMT-солверы с моего гайда въезжают только так практически все :), но пожалуй
будет мудрее всё же придерживаться подхода, когда всю математику прячем под капотом, даём только соответствующие паттерны, которые надо просто брать и тупо применять (и, да, они могут выглядеть весьма странно и контринтуитивно).
И вот тут стоит добавить два уровня пояснения (опционально!): первый - это какой в них смысл с точки зрения функционального проектирования, что за функциональные паттерны, и второй - а как вообще эта механика устроена детально/формально - на теорем-прувере вроде Lean, или в гомотопической теории.
С одной стороны, мы можем сперва мощно прокачивать свою базу (базу в смысле Старкрафта/Варкрафта :), а затем выполнять молниеносный успешный раш вообще на любую проблему. Например прокачавшись как следует в профильной математике, в том же функциональном комбинировании -- развив пресловутое сильное рациональное мышление -- мы будем видеть любые повседневные архитектурные схемы как задачки для третьего класса, которые решаются просто в режиме непрерывного набора идеально работающего кода (Make Illegal States Unrepresentable) даже без особого думания на медленном мышлении S2 по Канеману. Главный минус -- для этого требуется существенное время, и имеет ли ради этого жертвовать несколькими годами карьеры, вопрос открытый.
На другом конце спектра раньше был такой тупой хак, что можно было отшлифовать один стек -- даже один фреймворк, даже его конкретную версию -- не умея особо кодить (физически не умея решать задачки уровня инвертирования связного списка), и влететь в айти. Теперь он к счастью сдулся, хотя совсем не исключено, что с явлением вайб-кодинга снова возродится.
Противоположное Computer Science сегодня -- это когда надо хорошо знать System Design, но тоже больше на уровне "зазубрить шаблоны" и скомбинировать десяток "квадратиков" на диаграмме (и хорошо ещё, если это C4). Уметь красиво рассказать на собесе "как написать свой нетфликс", для чего достаточно изучить три гайда (но технические знания конечно должны быть на уровне). Главный минус -- в результате имеем совсем узенькое системное мышление, крайне хрупкое понимание, сразу ломается на новом проекте, где на 15% другой стек, даже CRUD фиг перенесёшь. Но зато быстро.
=
Ну, так-то меня интересуют исключительно ментаты Лаборатории, есть хорошее понимание уровня их понимания, и их нужды. Тут моя задача конкретная:
повысить производственное мастерство x10..x100, не прокачивая скиллы.
База в cs конечно нужна, но тут вполне достаточно 3-4 первых треков второй части Лаборатории. Более теоретические темки буду постепенно добавлять однозначно (языки вроде Lean4 всё же тяжеловато ребятам осваивать, если в хороших университетах не обучались... хотя вот в SMT-солверы с моего гайда въезжают только так практически все :), но пожалуй
будет мудрее всё же придерживаться подхода, когда всю математику прячем под капотом, даём только соответствующие паттерны, которые надо просто брать и тупо применять (и, да, они могут выглядеть весьма странно и контринтуитивно).
И вот тут стоит добавить два уровня пояснения (опционально!): первый - это какой в них смысл с точки зрения функционального проектирования, что за функциональные паттерны, и второй - а как вообще эта механика устроена детально/формально - на теорем-прувере вроде Lean, или в гомотопической теории.
3⚡29❤16👍8✍2
...Потому что в 98% реальных проектов, даже на тысячу таблиц, программист мало когда использует 3-5 паттернов на одну фичу (да и то редко когда сознательно; как известно, в тысяче строк любого кода найдётся хотя бы одна монада, но кто об этом знает :).
7-9 -- уже сложный случай (порт/адаптер, оркестрация...), и как правило тут паттерны выражены аннотациями/конфигом, а не "ручным" кодом.
Ну например, этот ваш CRUD будет таким паттерном:
Сквозной путь запроса/кейса -- максимум 10–12 логических шагов (включая нутро фреймворка!). Переходов между bounded contexts при этом -- три максимум, хопов DI-зависимостей -- пять максимум. и т.д.
на эту тему в СильныхИдеях на днях выложу материал
"Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"
Вообще, если регулярно получаете >7 ручных слоёв на типовую фичу -- упрощайте модель, ищите подходящую библиотеку, пилите DSL...
...Ладно, спалю базу: хорошая архитектура -- это не больше слоёв/глубже комбинаций паттернов, а меньше "случайной" сложности при сохранении явных инвариантов. Держим сквозной путь ≤10-12 и автоматизируем всё, что не домен.
"Идеальность" архитектуры не связана с глубиной вложенности паттернов. Она растет, как считается в программной инженерии, пропорционально ясности сценариев по BDD, инкапсуляции и low coupling (хотя я писал целый сериал, почему low coupling -- это больше абстракция, чем практика).
Ставьте на чистую доменную модель с явными границами, конвейеры политик и Functional Core/Imperative Shell (максимум логики в чистом ядре, "эффекты" на границах, причём "эффектный" слой должен быть как можно тоньше).
+ Рекомендую capability-ориентированный дизайн: это когда глупенький пишет тупой CRUD...
...а умненький явно выражает бизнес-намерение:
=
Далее выявляем порты -- интерфейсы на границе домена, которая таким образом задаётся явно. Затем определяем соответствующую алгебру -- формальную сигнатуру операций на этой границе (что домен требует от внешнего мира? БД, REST, брокер?).
Алгебра в данном контексте -- это абстрактный набор операций предметной области (подписание платежа, чтение корзины, генерация UUID), заданных как чистая спецификация (а уж под каким эффектом это исполняется -- не важно). Мой гайд по абстрактным типам данных в ООП в помощь, а в ФП это что-то типа Tagless Final/Free Algebras (что тоже разбираю в соответствующем гайде :).
Ну и далее "интерпретатор" реализует алгебру поверх конкретных эффектов/технологий (DB/HTTP/...)...
=
Учимся по BDD распознавать (неявные) вариации и ограничения в ТЗ и маппить их на паттерны. По моим оценкам, таких паттернов около 50, ну может под сотню. Готовой теории, которая бы их охватывала и систематизировала, у меня нету, поэтому сперва их надо сформулировать и классифицировать, затем добавить функциональное описание, затем формальное, а потом и сама теория родится, полагаю, естественно и легко.
7-9 -- уже сложный случай (порт/адаптер, оркестрация...), и как правило тут паттерны выражены аннотациями/конфигом, а не "ручным" кодом.
Ну например, этот ваш CRUD будет таким паттерном:
controller/endpoint -> mapper (dto, entity) -> use case (service) -> repo -> dbСквозной путь запроса/кейса -- максимум 10–12 логических шагов (включая нутро фреймворка!). Переходов между bounded contexts при этом -- три максимум, хопов DI-зависимостей -- пять максимум. и т.д.
на эту тему в СильныхИдеях на днях выложу материал
"Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"
Вообще, если регулярно получаете >7 ручных слоёв на типовую фичу -- упрощайте модель, ищите подходящую библиотеку, пилите DSL...
...Ладно, спалю базу: хорошая архитектура -- это не больше слоёв/глубже комбинаций паттернов, а меньше "случайной" сложности при сохранении явных инвариантов. Держим сквозной путь ≤10-12 и автоматизируем всё, что не домен.
"Идеальность" архитектуры не связана с глубиной вложенности паттернов. Она растет, как считается в программной инженерии, пропорционально ясности сценариев по BDD, инкапсуляции и low coupling (хотя я писал целый сериал, почему low coupling -- это больше абстракция, чем практика).
Ставьте на чистую доменную модель с явными границами, конвейеры политик и Functional Core/Imperative Shell (максимум логики в чистом ядре, "эффекты" на границах, причём "эффектный" слой должен быть как можно тоньше).
+ Рекомендую capability-ориентированный дизайн: это когда глупенький пишет тупой CRUD...
user.setStatus("ACTIVE");
userRepository.save(user);
// да, но с какой целью??...а умненький явно выражает бизнес-намерение:
userActivationService.activateUser(userId);
=
Далее выявляем порты -- интерфейсы на границе домена, которая таким образом задаётся явно. Затем определяем соответствующую алгебру -- формальную сигнатуру операций на этой границе (что домен требует от внешнего мира? БД, REST, брокер?).
Алгебра в данном контексте -- это абстрактный набор операций предметной области (подписание платежа, чтение корзины, генерация UUID), заданных как чистая спецификация (а уж под каким эффектом это исполняется -- не важно). Мой гайд по абстрактным типам данных в ООП в помощь, а в ФП это что-то типа Tagless Final/Free Algebras (что тоже разбираю в соответствующем гайде :).
Ну и далее "интерпретатор" реализует алгебру поверх конкретных эффектов/технологий (DB/HTTP/...)...
=
Учимся по BDD распознавать (неявные) вариации и ограничения в ТЗ и маппить их на паттерны. По моим оценкам, таких паттернов около 50, ну может под сотню. Готовой теории, которая бы их охватывала и систематизировала, у меня нету, поэтому сперва их надо сформулировать и классифицировать, затем добавить функциональное описание, затем формальное, а потом и сама теория родится, полагаю, естественно и легко.
2⚡36👍9❤7✍1
Когда разные высокие чины говорят, что "AI, по сути, может выполнять работу джуниора", это признак полной некомпетентности в ИТ. Эти люди, видимо, никогда не работали с джуниорами.
Ценность младшего разработчика составляет, наверное, около 20% в виде написанного им кода, а 80% -- это аванс на ближайшие год-два, когда он уже не будет младшим. Всё, что тут может AI -- это лишь немножко заменить первые 20%...
Ценность младшего разработчика составляет, наверное, около 20% в виде написанного им кода, а 80% -- это аванс на ближайшие год-два, когда он уже не будет младшим. Всё, что тут может AI -- это лишь немножко заменить первые 20%...
💯45👍14⚡6❤2🤓1
Все сегодня стремятся внедрить модные фишки AI -- агенты, RAG, серверы MCP, инструментальные решения...
За шумихой скрывается мрачная правда: большинство команд идут на невидимый (и невероятный по потенциальной катастрофичности) риск.
Баги просачиваются через тесты и логи. Выдача LLM-ок не поддаётся проверке. Зависимости и контейнеры формируют цепочки мутных последствий, которые никогда не придут человеку в голову. Архитектура превращается в набор костылей вокруг "магии" чёрного ящика. Внешние сервисы получают неконтролируемый доступ к ядру данных, а стаи агентов самостоятельно принимают решения, о которых вы узнаёте постфактум, когда уже всё рухнуло безвозвратно. Идемпотентность и ACID-транзакции размываются в угоду "гибкости". Цепочки вызовов не имеют единой точки отказа -- но и не имеют единого состояния истины, и существуют словно в сферическом вакууме.
Мы строим системы, где безопасность стала робкой и во многом иллюзорной надеждой, а не инженерной гарантией. Мы создаём монстров с непредсказуемым поведением, где откатить ошибочное действие для человека становится невозможным.
"Хотя… скоро, на мой взгляд, вообще никаких тем не будет. Грядут крайне тяжелые времена и коснутся они всех, так или иначе. Впереди ждут долгие и многие годы, наполненные ужасом и унынием. Не думайте, что я какой-то паникер или специально смуту развожу. Вовсе нет. Просто делюсь внутренними ощущениями. И кажется мне, что ничего хорошего будущее не предвещает.
Да и когда в последний раз был хорошо и спокойно?"
-- Мэд
😁
За шумихой скрывается мрачная правда: большинство команд идут на невидимый (и невероятный по потенциальной катастрофичности) риск.
Баги просачиваются через тесты и логи. Выдача LLM-ок не поддаётся проверке. Зависимости и контейнеры формируют цепочки мутных последствий, которые никогда не придут человеку в голову. Архитектура превращается в набор костылей вокруг "магии" чёрного ящика. Внешние сервисы получают неконтролируемый доступ к ядру данных, а стаи агентов самостоятельно принимают решения, о которых вы узнаёте постфактум, когда уже всё рухнуло безвозвратно. Идемпотентность и ACID-транзакции размываются в угоду "гибкости". Цепочки вызовов не имеют единой точки отказа -- но и не имеют единого состояния истины, и существуют словно в сферическом вакууме.
Мы строим системы, где безопасность стала робкой и во многом иллюзорной надеждой, а не инженерной гарантией. Мы создаём монстров с непредсказуемым поведением, где откатить ошибочное действие для человека становится невозможным.
"Хотя… скоро, на мой взгляд, вообще никаких тем не будет. Грядут крайне тяжелые времена и коснутся они всех, так или иначе. Впереди ждут долгие и многие годы, наполненные ужасом и унынием. Не думайте, что я какой-то паникер или специально смуту развожу. Вовсе нет. Просто делюсь внутренними ощущениями. И кажется мне, что ничего хорошего будущее не предвещает.
Да и когда в последний раз был хорошо и спокойно?"
-- Мэд
😁
2✍44👍13🤔10⚡3❤1