Что такое мэйнстрим? Это бессистемное множество абстракций, каждая из которых "упрощает" разработку для глупеньких, но увеличивает накладные расходы.
Типа,
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
...Вообще, мэйнстрим -- это абсолютный абсурд. Буквально на каждом собеседовании куда угодно кандидатов могут долго и упорно пытать по базе SOLID, причём неформально: техлид искренне убеждён, что их-то многослойная/многоуровневая система полностью этому соответствует, и поэтому так важно знать SOLID и паттерны проектирования.
При том, что их система -- это когда фронтенд зависит от бизнес-логики (через тот же REST), а бизнес-логика в свою очередь зависит от базы данных "под ней" (то есть слой UI максимально удалён от слоя работы с данными, между ними есть промежуточный доменный слой).
Ну, а разве у вас по-другому? :)
Да, но это есть прямое нарушение DIP:
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
А у вас логика домена (концентрат всех ваших абстракций, вся ваша система типов) зависит от логики доступа к данным.
Ну и какой тут солид-шмолид...
Думайте.
При том, что их система -- это когда фронтенд зависит от бизнес-логики (через тот же REST), а бизнес-логика в свою очередь зависит от базы данных "под ней" (то есть слой UI максимально удалён от слоя работы с данными, между ними есть промежуточный доменный слой).
Ну, а разве у вас по-другому? :)
Да, но это есть прямое нарушение DIP:
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
А у вас логика домена (концентрат всех ваших абстракций, вся ваша система типов) зависит от логики доступа к данным.
Ну и какой тут солид-шмолид...
Думайте.
💯49✍13🤔6
Смешное: Nearly All Binary Searches and Mergesorts are Broken
Даже в легендарных "Жемчужинах программирования" Бентли, которыми я когда-то зачитывался, найдена ошибка, причём сама по себе детская - арифметическое переполнение. В восьмидесятые автор просто не предполагал, чтона год потребуется четыре цифры могут быть массивы размером в миллиард элементов. И многие десятилетия эта бага расползалась по всему миру.
Кстати, кто проходил мой курс "Незримые механизмы логики", мы там разбираем на примерах базу доказательства корректности кода (триплы Хоара...), попробуйте этот код верифицировать, чтобы таких ошибок не было.
И это из проверенного учебника, который AI считает весьма достоверным. А сколько забагованного кода AI тащит в твой прод из кривых проектов с гитхаба? (риторическое)
Никакое архитекторство тебя не спасёт, когда в твоём проде низкоуровневый говнокод :)
Никуда в конечном итоге будет не деться от формальной верификации...
Даже в легендарных "Жемчужинах программирования" Бентли, которыми я когда-то зачитывался, найдена ошибка, причём сама по себе детская - арифметическое переполнение. В восьмидесятые автор просто не предполагал, что
Кстати, кто проходил мой курс "Незримые механизмы логики", мы там разбираем на примерах базу доказательства корректности кода (триплы Хоара...), попробуйте этот код верифицировать, чтобы таких ошибок не было.
И это из проверенного учебника, который AI считает весьма достоверным. А сколько забагованного кода AI тащит в твой прод из кривых проектов с гитхаба? (риторическое)
Никакое архитекторство тебя не спасёт, когда в твоём проде низкоуровневый говнокод :)
Никуда в конечном итоге будет не деться от формальной верификации...
👍41❤11✍8⚡2
.
Облако драгоценностей за неделю.
Приватный клуб:
...В следующий раз, когда вы подумаете о создании "служебного" статического класса XYZUtils, спросите себя: может ли это быть объект моего домена?
Для донов-начинающих:
Делайте больше сложных дел — это один из лучших способов усвоить важные уроки о своей карьере, да и о жизни...
75%+ взрослых людей от 25 лет могли бы выбрать любой интеллектуальный/инженерный навык и пробиться в топ-10% в мире, просто работая исключительно над этим каждый день в течение двух-трёх лет. И это с нуля...
Ни Оксфорд ни Гарвард ни МГУ никаким "реальным проектам" и скорейшему применению информатики "на практике" принципиально не учат, наоборот: на протяжении всех 4-6 лет даётся всё больше теории computer science и математики...
Для донов-неначинающих:
Почему вам не получается расти?..
Есть один малоизвестный красный флаг, который на протяжении и моей карьеры, и карьеры знакомых, подтверждался много раз. Он касается в первую очередь вашего непосредственного начальника, но так же хорошо работает в плане последствий и в отношении самого главного (гендир, владелец...)...
(все старые материалы для донов постепенно сгорают)
=
Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
🚀
=
Новые материалы для ментатов Лаборатории.
Важно: уточнены правила занятий п.10.1.2.8: каждые календарные полгода вы должны (бесплатно) перепроходить три первых курса АСД, а затем дополнительные курсы АСД...
В СильныеИдеи добавлен материал "125) Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"
На первый взгляд эти два понятия выглядят прямо противоположными.
Проектирование -- это высокоуровневая бизнес-логика, абстракции, модели домена, семантика... Рефакторинг -- это чисто механическая схема работы с кодом по форме, не затрагивая реализацию.
Но разработка крупных систем столь сложная тема, что лучше всего её рассматривать через квантовую призму -- всё запутано со всем :)
В курс карьеры добавлен 116-й материал "Плохой ли вы сотрудник?".
Одно время я списывал такую двойственность (что решил посвятить свое время чему-то ещё, кроме компании-работодателя) на то, что работал не в тех немногих избранных компаниях мечты. Ну или как минимум не в той сфере. Но вот что случилось, когда я в них поработал...
💪🏻
Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.
=
"ЛаМПовое": стратегема Agile-Манифеста, vim, "Диспетчер", внешние API, 60% неудачных сборок CI, "Алиса в Странечудес невыученных уроков". ...
Облако драгоценностей за неделю.
Приватный клуб:
...В следующий раз, когда вы подумаете о создании "служебного" статического класса XYZUtils, спросите себя: может ли это быть объект моего домена?
Для донов-начинающих:
Делайте больше сложных дел — это один из лучших способов усвоить важные уроки о своей карьере, да и о жизни...
75%+ взрослых людей от 25 лет могли бы выбрать любой интеллектуальный/инженерный навык и пробиться в топ-10% в мире, просто работая исключительно над этим каждый день в течение двух-трёх лет. И это с нуля...
Ни Оксфорд ни Гарвард ни МГУ никаким "реальным проектам" и скорейшему применению информатики "на практике" принципиально не учат, наоборот: на протяжении всех 4-6 лет даётся всё больше теории computer science и математики...
Для донов-неначинающих:
Почему вам не получается расти?..
Есть один малоизвестный красный флаг, который на протяжении и моей карьеры, и карьеры знакомых, подтверждался много раз. Он касается в первую очередь вашего непосредственного начальника, но так же хорошо работает в плане последствий и в отношении самого главного (гендир, владелец...)...
(все старые материалы для донов постепенно сгорают)
=
Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
🚀
=
Новые материалы для ментатов Лаборатории.
Важно: уточнены правила занятий п.10.1.2.8: каждые календарные полгода вы должны (бесплатно) перепроходить три первых курса АСД, а затем дополнительные курсы АСД...
В СильныеИдеи добавлен материал "125) Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"
На первый взгляд эти два понятия выглядят прямо противоположными.
Проектирование -- это высокоуровневая бизнес-логика, абстракции, модели домена, семантика... Рефакторинг -- это чисто механическая схема работы с кодом по форме, не затрагивая реализацию.
Но разработка крупных систем столь сложная тема, что лучше всего её рассматривать через квантовую призму -- всё запутано со всем :)
В курс карьеры добавлен 116-й материал "Плохой ли вы сотрудник?".
Одно время я списывал такую двойственность (что решил посвятить свое время чему-то ещё, кроме компании-работодателя) на то, что работал не в тех немногих избранных компаниях мечты. Ну или как минимум не в той сфере. Но вот что случилось, когда я в них поработал...
💪🏻
Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.
=
"ЛаМПовое": стратегема Agile-Манифеста, vim, "Диспетчер", внешние API, 60% неудачных сборок CI, "Алиса в Стране
❤31🔥6👏5
"...В [...] сходил на техническое собеседование. В целом прошло неплохо, но не хватило уверенности в решении задач на кодирование. В целом все как обычно. Видимо, надо целенаправленно усиливать это направление. Первая вакансия за долгое время, где жалею, что не прошел. По крайней мере по описанию вакансии там должно было быть интересно.
Была еще третья компания. Сами написали, давно такого не было. Хотели опыт в процессинге/эквайринге, которого у меня нет, поэтому дальше разговора с HR'ом не пошло.
Спросили бы отказоустойчивый кластер Kafka настроить, тут я с закрытыми глазами...
...На Kotlin надо было функциональную цепочку написать, но я забыл сигнатуры методов.
И алгоритмическая задачка с подсчётом разных видов скобок. Забыл, что там идея класть открытые скобки в стек, а при нахождении закрытой скобки доставать их из стека."
Мы же это ещё на первом курсе АСД проходили!!1 )))
+ с тех пор я добавил в каждый курс АСД десятки новых задачек посложнее, и теперь периодически всем ментатам надо будет перепроходить эти курсы (а также дополнительные, которые я делал по лекциям ШАД), дабы быть готовым к лайв-кодингу 💪🏻
АСД -- вечная база для собесов!
Была еще третья компания. Сами написали, давно такого не было. Хотели опыт в процессинге/эквайринге, которого у меня нет, поэтому дальше разговора с HR'ом не пошло.
Спросили бы отказоустойчивый кластер Kafka настроить, тут я с закрытыми глазами...
...На Kotlin надо было функциональную цепочку написать, но я забыл сигнатуры методов.
И алгоритмическая задачка с подсчётом разных видов скобок. Забыл, что там идея класть открытые скобки в стек, а при нахождении закрытой скобки доставать их из стека."
Мы же это ещё на первом курсе АСД проходили!!1 )))
+ с тех пор я добавил в каждый курс АСД десятки новых задачек посложнее, и теперь периодически всем ментатам надо будет перепроходить эти курсы (а также дополнительные, которые я делал по лекциям ШАД), дабы быть готовым к лайв-кодингу 💪🏻
АСД -- вечная база для собесов!
2❤51👍5
Интеллект не может быть обобщён в виде 5-шагового видеоролика продолжительностью в 1 минуту, поэтому, если вы здесь не для того, чтобы регулярно изучать что-то сложное для ума, пожалуйста, найдите свой быстрый дофамин где-нибудь в другом месте.
Если же вы будете упорствовать в правильных темках, этот блог радикально изменит направление вашей жизни.
Смысл мема =>R⁴ -- группа вращений квадрата (циклическая группа порядка 4). Поразительно, но Филдсовская медаль была вручена за Exotic Smooth Structures, бесконечным числом коих обладает только R4. Для любого другого пространства Rn при n != 4 существует ровно одна гладкая структура (только один "естественный" способ определить на нём понятие гладкости и производной).
Exotic Smooth Structures -- это такие чрезвычайно странные пространства, которые гомеоморфны R4 (т.е. с т.зр. топологии это то же самое), но не диффеоморфны ему (с т.зр. гладкого исчисления это совершенно другие объекты, в них нельзя гладко преобразовать одну систему координат в другую). Выглядят одинаково, но плавной трансформации между ними нету.
Кто изучал матан, знает, что анализ в R4 особенно сложный.
В 3D-графике точки часто представляют в однородных координатах (вектор в R4 [x,y,z,w]).
Можно поизучать применение Exotic Smooth Structures в этих ваших нейросетках (гладкие структуры на огромном пространстве параметров). Траектория градиентного спуска, вполне возможно, будет в этих странных штуках вести себя совершенно по-другому -- например, избегая локальных минимумов или находя более качественные решения, которые недоступны при "стандартной" настройке...
p.s. Математики подправили: "R^4 - это не группа вращений квадрата и не циклическая группа порядка 4. Группа вращений квадрата - это частный случай группы диэддра, она конечна, у нее порядок 8."
Конечная группа вращений квадрата — это C4. А R⁴ — это четырёхмерное топологическое многообразие, гомеоморфное стандартному четырёхмерному евклидову пространству.
Exotic differentiable structures on R^4
Если же вы будете упорствовать в правильных темках, этот блог радикально изменит направление вашей жизни.
Смысл мема =>
Exotic Smooth Structures -- это такие чрезвычайно странные пространства, которые гомеоморфны R4 (т.е. с т.зр. топологии это то же самое), но не диффеоморфны ему (с т.зр. гладкого исчисления это совершенно другие объекты, в них нельзя гладко преобразовать одну систему координат в другую). Выглядят одинаково, но плавной трансформации между ними нету.
Кто изучал матан, знает, что анализ в R4 особенно сложный.
В 3D-графике точки часто представляют в однородных координатах (вектор в R4 [x,y,z,w]).
Можно поизучать применение Exotic Smooth Structures в этих ваших нейросетках (гладкие структуры на огромном пространстве параметров). Траектория градиентного спуска, вполне возможно, будет в этих странных штуках вести себя совершенно по-другому -- например, избегая локальных минимумов или находя более качественные решения, которые недоступны при "стандартной" настройке...
p.s. Математики подправили: "R^4 - это не группа вращений квадрата и не циклическая группа порядка 4. Группа вращений квадрата - это частный случай группы диэддра, она конечна, у нее порядок 8."
Конечная группа вращений квадрата — это C4. А R⁴ — это четырёхмерное топологическое многообразие, гомеоморфное стандартному четырёхмерному евклидову пространству.
Exotic differentiable structures on R^4
🤓41❤14👍5🤔4