Относительно мышления на условном уровне проектирования/ programming in large, всё что Terence Tao упоминает -- это сплошные эвристики. В проекте Lean4-Analysis-Tao Тао много занимался глубокой медитацией мысленными экспериментами-"симуляциями", чтобы определить, какие леммы нужны для доказательства сходимости рядов. По его словам, он мысленно проигрывал в голове возможные пути доказательства, выделяя ключевые шаги.
(Попробуйте-ка попросить своего менеджера выделить вам время на обдумывание структуры проекта -- в виде например "гулять по парку" или "сидеть в уличном кафе в медитации за чашечкой кофэ" :)
Интересно что Тао использовал подходы к декомпозиции, характерные сегодня для нейросеток: "Decompose-ToM: Enhancing Theory of Mind Reasoning in Large Language Models through Simulation and Task Decomposition"
=
И снова и снова Тао повторяет мантру, что процесс выделения лемм — это искусство, а не алгоритм. Дескать,
- контекстная зависимость
- нет универсальных правил для выбора лемм
- математик часто опирается на неявные знания и аналогии, которые сложно выразить в виде формальных шагов
- cлишком мелкие леммы усложняют общую структуру, слишком крупные - теряют ценность для повторного использования.
Тао подчеркивает, что декомпозиция — это не столько технический метод, сколь "думательная/мыслительная дисциплина". Он рекомендуетприменять SOLID
- начинать с простых аналогий (например, разбить доказательство теоремы Пифагора на 3-4 леммы);
- использовать пруф-ассистенты вроде Lean для визуализации связей между леммами;
- избегать чрезмерной детализации: леммы должны быть достаточно общими для повторного использования.
Лемма должна решать одну конкретную подзадачу, которая повторяется или критически важна для доказательства (SRP).
Леммы формулируются так, чтобы их можно было применять в разных контекстах.
Если промежуточная теорема требует многошагового доказательства, её разбивают на леммы. И т.д.
Ничего не напоминает? :)
Леммы — "библиотечные функции": однажды доказанные, они применяются в новых теоремах. Функции легко и просто вызываются в разных контекстах, если соблюдаются их контракты. и т.п.
Всё это фактически украдено, причём в весьма лайтовой версии, у программной инженерии, cтабильно рекомендующей это всё последние лет 50 с гаком.
В формализации PFR например леммы были организованы как модули с интерфейсами в Lean.
Математики, что с лицом? :)
=
В проекте PFR была введена таксономия лемм -- они классифицировались по типам:
- технические (например, оценки сумм),
- структурные (связь между объектами),
- вспомогательные (подготовка данных для следующих шагов).
Кто проходил мой трек по объектно-ориентирному анализу и проектированию, должен вспомнить третий курс, где мы вводили фактически такую же таксономию классов: классы анализа, классы проектирования и классы реализации.
Ну и зачем нам изоморфизм к этой никакой не математике, а по сути, чистой инженерии с эвристиками?
В айтишке это всё работает давно и на порядок качественнее и продуктивнее.
(потерпите, немного додумать осталось :)
(Попробуйте-ка попросить своего менеджера выделить вам время на обдумывание структуры проекта -- в виде например "гулять по парку" или "сидеть в уличном кафе в медитации за чашечкой кофэ" :)
Интересно что Тао использовал подходы к декомпозиции, характерные сегодня для нейросеток: "Decompose-ToM: Enhancing Theory of Mind Reasoning in Large Language Models through Simulation and Task Decomposition"
=
И снова и снова Тао повторяет мантру, что процесс выделения лемм — это искусство, а не алгоритм. Дескать,
- контекстная зависимость
- нет универсальных правил для выбора лемм
- математик часто опирается на неявные знания и аналогии, которые сложно выразить в виде формальных шагов
- cлишком мелкие леммы усложняют общую структуру, слишком крупные - теряют ценность для повторного использования.
Тао подчеркивает, что декомпозиция — это не столько технический метод, сколь "думательная/мыслительная дисциплина". Он рекомендует
- начинать с простых аналогий (например, разбить доказательство теоремы Пифагора на 3-4 леммы);
- использовать пруф-ассистенты вроде Lean для визуализации связей между леммами;
- избегать чрезмерной детализации: леммы должны быть достаточно общими для повторного использования.
Лемма должна решать одну конкретную подзадачу, которая повторяется или критически важна для доказательства (SRP).
Леммы формулируются так, чтобы их можно было применять в разных контекстах.
Если промежуточная теорема требует многошагового доказательства, её разбивают на леммы. И т.д.
Ничего не напоминает? :)
Леммы — "библиотечные функции": однажды доказанные, они применяются в новых теоремах. Функции легко и просто вызываются в разных контекстах, если соблюдаются их контракты. и т.п.
Всё это фактически украдено, причём в весьма лайтовой версии, у программной инженерии, cтабильно рекомендующей это всё последние лет 50 с гаком.
В формализации PFR например леммы были организованы как модули с интерфейсами в Lean.
Математики, что с лицом? :)
=
В проекте PFR была введена таксономия лемм -- они классифицировались по типам:
- технические (например, оценки сумм),
- структурные (связь между объектами),
- вспомогательные (подготовка данных для следующих шагов).
Кто проходил мой трек по объектно-ориентирному анализу и проектированию, должен вспомнить третий курс, где мы вводили фактически такую же таксономию классов: классы анализа, классы проектирования и классы реализации.
Ну и зачем нам изоморфизм к этой никакой не математике, а по сути, чистой инженерии с эвристиками?
В айтишке это всё работает давно и на порядок качественнее и продуктивнее.
(потерпите, немного додумать осталось :)
🤓34❤12✍8👍6🔥1
...В принципе, для этого всего можно найти много близких аналогий: категорная дуальность (леммы -- это морфизмы в категории доказательств, функции -- морфизмы в категории типов), абстрактная интерпретация (доказательства - типа, спецификации; функции - типа, их реализации), Карри-Ховард конечно классика — да только нафига.
Как не было толку от хаскелеподобных подходов, так и нету, разве что совсем нишевые ниши вроде формальной верификации (например, из Lean в Rust), документирования кода через "контракты" (как в Eiffel/Dafny), ну и обучение конечно.
Для практики нужен язык как минимум с поддержкой зависимых типов, и чтобы он был распространён хотя бы как F#.
=
Короче говоря, резюме такое, что даже самая топовая на сегодня математика уровня филдсовских лауреатов пока что только-только пытается выбраться из детсадовских штанишек programming in small. Забавно смотреть, как математики изобретают велосипед, открывая для себя например гитхаб, где леммы распределялись между участниками как issues, с PR, а их доказательства проверялись через CI/CD )))
Взять нам у них нечего, а вот дать можем очень много.
=
Соответственно итоговая цель получается такая, что вместо утверждений Тао, по сути, по теме programming in large, что
- процесс выделения лемм (классов, функций) — это искусство
- декомпозиция — это не столько технический метод, сколь "думательная дисциплина"
мы должны получить такую базу:
- процесс выделения лемм (классов, функций) — это алгоритм
- декомпозиция — это не столько думательная дисциплина, сколько технический метод, причём реализуемый на быстром мышлении (прокачки скиллов не требуется).
Думаю, что тут пока вполне можно остановиться на ООАП по Бертрану Мейеру, усиленному моделью акторов по Алану Кэю и Карлу Хьюитту, и получить очень хороший практический результат. Для начала, первый шаг -- отшлифовать немного мой трек ООАП теоркатом, GADT и HoTT.
Закроем сейчас programming in small гомотопическими типами, и возьмёмся за финальную темку в программировании :)
Как не было толку от хаскелеподобных подходов, так и нету, разве что совсем нишевые ниши вроде формальной верификации (например, из Lean в Rust), документирования кода через "контракты" (как в Eiffel/Dafny), ну и обучение конечно.
Для практики нужен язык как минимум с поддержкой зависимых типов, и чтобы он был распространён хотя бы как F#.
=
Короче говоря, резюме такое, что даже самая топовая на сегодня математика уровня филдсовских лауреатов пока что только-только пытается выбраться из детсадовских штанишек programming in small. Забавно смотреть, как математики изобретают велосипед, открывая для себя например гитхаб, где леммы распределялись между участниками как issues, с PR, а их доказательства проверялись через CI/CD )))
Взять нам у них нечего, а вот дать можем очень много.
=
Соответственно итоговая цель получается такая, что вместо утверждений Тао, по сути, по теме programming in large, что
- процесс выделения лемм (классов, функций) — это искусство
- декомпозиция — это не столько технический метод, сколь "думательная дисциплина"
мы должны получить такую базу:
- процесс выделения лемм (классов, функций) — это алгоритм
- декомпозиция — это не столько думательная дисциплина, сколько технический метод, причём реализуемый на быстром мышлении (прокачки скиллов не требуется).
Думаю, что тут пока вполне можно остановиться на ООАП по Бертрану Мейеру, усиленному моделью акторов по Алану Кэю и Карлу Хьюитту, и получить очень хороший практический результат. Для начала, первый шаг -- отшлифовать немного мой трек ООАП теоркатом, GADT и HoTT.
Закроем сейчас programming in small гомотопическими типами, и возьмёмся за финальную темку в программировании :)
❤36👍20✍5
Нейросетки в модели акторов, да и вообще в асинхронщине, тупят очень жёстко. Пробовал несколько самых последних, вот например Клод 3.7 MAX быстро начал проситься обратно на синхронный формат:
...Ошибка указывает на то, что актор GameEngineActor был остановлен до того, как смог обработать сообщение. Это может происходить по нескольким причинам:
1. Актор мог завершить свою работу из-за необработанного исключения внутри его методов
2. Другой код мог явно остановить актор раньше времени
3. Возможен конфликт при инициализации акторов
Для решения этой проблемы рекомендую следующие шаги:
[... бла бла бла добавить логирование и обработку исключений ...]
Если проблема не решится, можно временно отказаться от модели акторов и вернуться к синхронной обработке для отладки: ...
Ну так ты же сам этот код и написал, вот и разбирайся в причинах :)
Впрочем совершенно не удивлён: для этого надо хотя бы немножечко понимать семантику недетерминированности (например, в рамках моих курсов по параллельным вычислительным моделям:). Трансформеры весь обучаются на линейных последовательностях, а тут надомоделировать аппроксимировать динамические зависимости между асинхронными задачами, порядок работы которых непредсказуем.
Асинхронщина -- это часто работа с (около)глобальным состоянием (например, обновление интерфейса или кэша). В параллельном режиме надо уметь отслеживать и синхронизировать такие состояния, понимать временнЫе зависимости (от внешних факторов --- время ответа сервера), состояния гонки, различать контекстные нюансы асинхронных вызовов (колбэки внутри колбэков, цепочки промисов...).
Как даже хорошо подобранные обучающие примеры помогут в условном "обобщении" этих тем для AI в реальных проектах, не представляю.
...Ошибка указывает на то, что актор GameEngineActor был остановлен до того, как смог обработать сообщение. Это может происходить по нескольким причинам:
1. Актор мог завершить свою работу из-за необработанного исключения внутри его методов
2. Другой код мог явно остановить актор раньше времени
3. Возможен конфликт при инициализации акторов
Для решения этой проблемы рекомендую следующие шаги:
[... бла бла бла добавить логирование и обработку исключений ...]
Если проблема не решится, можно временно отказаться от модели акторов и вернуться к синхронной обработке для отладки: ...
Ну так ты же сам этот код и написал, вот и разбирайся в причинах :)
Впрочем совершенно не удивлён: для этого надо хотя бы немножечко понимать семантику недетерминированности (например, в рамках моих курсов по параллельным вычислительным моделям:). Трансформеры весь обучаются на линейных последовательностях, а тут надо
Асинхронщина -- это часто работа с (около)глобальным состоянием (например, обновление интерфейса или кэша). В параллельном режиме надо уметь отслеживать и синхронизировать такие состояния, понимать временнЫе зависимости (от внешних факторов --- время ответа сервера), состояния гонки, различать контекстные нюансы асинхронных вызовов (колбэки внутри колбэков, цепочки промисов...).
Как даже хорошо подобранные обучающие примеры помогут в условном "обобщении" этих тем для AI в реальных проектах, не представляю.
❤🔥26✍22❤4👍3🫡2
This media is not supported in your browser
VIEW IN TELEGRAM
Пока одни занимаются вайб-кодингом, другие оптимизируют микросекунды ручного набора кода в vim-е, плагин hardtime.nvim в помощь 💪🏻
👍28🤓15😁8🔥3✍2
SaaS is Dead.
SaaS сегодня -- это один из наиболее трудных и ресурсозатратных путей вхождения в микро-ит-предпринимательство.
Чем острее некоторая компания нуждается в вашем SaaS-инструменте, тем более эээ своеобразным будет их Big Ball of Mud(попросту говоря, здоровенная куча устаревшего говнокода) , и тем более эээ неожиданными и нестандартными (попросту говоря, откровенно дерьмовыми) будут их рабочие процессы.
Вы потратите сотни часов на поддержку этих "уникальных" случаев, чтобы получить убедительные саксесс стори, и при этом 98% таких случаев не приведут к покупке SaaS-подписки.
Невероятно велика пропасть между "Похоже, это действительно классная идея, надо запилить СааС!" и "Кто-то реально собирается потратить время и ресурсы на внедрение этого сервиса в свои воркфлоу."
Если же идея в самом деле окажется с неплохим спросом, то крупные компании моментально её скопируют и превратят в нормальный товар в хорошей маркетинговой упаковке, который станет частью их новой базовой линейки продуктов.
Что, скорее всего, сразу вернёт вас к исходной точке. Точнее даже не к исходной, а к большому минусу как минимум по расходу времени.
Есть 2%, что вашу технологию удастся продать компании, пока рынок для неё не рухнул, но если коммодитизация пройдёт в форме действительно отличной альтернативы с открытым исходным кодом от большой корпорации, даже такой вариант может оказаться невозможным.
Вы же помните, как Пончик в НнЛ создал свой стартап по продаже соли, пока об этом не прознали корпорации? Хорошо ещё, что в кутузку в итоге не попал.
SaaS сегодня -- это один из наиболее трудных и ресурсозатратных путей вхождения в микро-ит-предпринимательство.
Чем острее некоторая компания нуждается в вашем SaaS-инструменте, тем более эээ своеобразным будет их Big Ball of Mud
Вы потратите сотни часов на поддержку этих "уникальных" случаев, чтобы получить убедительные саксесс стори, и при этом 98% таких случаев не приведут к покупке SaaS-подписки.
Невероятно велика пропасть между "Похоже, это действительно классная идея, надо запилить СааС!" и "Кто-то реально собирается потратить время и ресурсы на внедрение этого сервиса в свои воркфлоу."
Если же идея в самом деле окажется с неплохим спросом, то крупные компании моментально её скопируют и превратят в нормальный товар в хорошей маркетинговой упаковке, который станет частью их новой базовой линейки продуктов.
Что, скорее всего, сразу вернёт вас к исходной точке. Точнее даже не к исходной, а к большому минусу как минимум по расходу времени.
Есть 2%, что вашу технологию удастся продать компании, пока рынок для неё не рухнул, но если коммодитизация пройдёт в форме действительно отличной альтернативы с открытым исходным кодом от большой корпорации, даже такой вариант может оказаться невозможным.
Вы же помните, как Пончик в НнЛ создал свой стартап по продаже соли, пока об этом не прознали корпорации? Хорошо ещё, что в кутузку в итоге не попал.
🤔36💯13✍9👍5❤4
Вчера истеричные белки 🤪 прогнали очередную волну хайпа по поводу сами знаете чего. Ну это уже как в той древней истории про волков: столько накричали волки-волки вышел-убийца-кодеров , что все это воспринимают так как и есть: это просто очередной фейк.
Кодекс-l и Опус-4 за 200 долларов я тестить не планирую, ну и как бы то что он "думает часами над задачей и рефакторингом" отнюдь не плюс в его пользу, а здоровенный минус. По полдня ждать его результатов... Это сколько же гигабайтов кода он сгенерит или перелопатит за такое время с абсолютно непредсказуемыми последствиями 🤡
В AI сегодня ценен именно реайлайм в плане фидбека.
=
А Клоду 4 я дал простую задачку: сделать консольную Змейку в модели акторов. Сперва он затупил с версией pykka, сделал на каком-то старье 3.x, которое давно задепрекачено(при том что конечно менять API популярной библиотеки западло само по себе) .
Потом Клод стал доказывать, что он такой бедный несчастный обучен на данных 24-го года и не в курсе про новую версию, а в гугле забанен ☠️ после чего я потыкал его мордой в собственные какашки 💩 => версия пукки 4.0 вышла ещё в 23-м году. Он извинился и выдал нагора 330 строк кода, которые вроде бы запустились норм.
Но потом Змейка стала просто случайно завершаться (не вылетать). Я даже на асинхронщину не стал грешить, а просто повнимательнее посмотрел код, и оказалось, что в одном месте (в середине файла) размер игрового поля тупо захардкожен 🤮 20 x 17, а в другом месте, где рендер, используется 22 x 19 🙈
Я попросил это пофиксить, сделать норм с константами, после чего Клод 4 зачем-то решил "улучшить код в целом", и в результате вообще сломал,
а когда мы пошли на третью итерацию и очередные полчаса работы слились впустую, он был послан подальше.
...А потом я забылся и случайно зашёл через бесплатный голландский впн (Клоду сервер нужен только США), и антропик меня забанил 👊
Но честно сделал рефанд за месяц 22 евро 💰на эстонскую карточку.
Кодекс-l и Опус-4 за 200 долларов я тестить не планирую, ну и как бы то что он "думает часами над задачей и рефакторингом" отнюдь не плюс в его пользу, а здоровенный минус. По полдня ждать его результатов... Это сколько же гигабайтов кода он сгенерит или перелопатит за такое время с абсолютно непредсказуемыми последствиями 🤡
В AI сегодня ценен именно реайлайм в плане фидбека.
=
А Клоду 4 я дал простую задачку: сделать консольную Змейку в модели акторов. Сперва он затупил с версией pykka, сделал на каком-то старье 3.x, которое давно задепрекачено
Потом Клод стал доказывать, что он такой бедный несчастный обучен на данных 24-го года и не в курсе про новую версию, а в гугле забанен ☠️ после чего я потыкал его мордой в собственные какашки 💩 => версия пукки 4.0 вышла ещё в 23-м году. Он извинился и выдал нагора 330 строк кода, которые вроде бы запустились норм.
Но потом Змейка стала просто случайно завершаться (не вылетать). Я даже на асинхронщину не стал грешить, а просто повнимательнее посмотрел код, и оказалось, что в одном месте (в середине файла) размер игрового поля тупо захардкожен 🤮 20 x 17, а в другом месте, где рендер, используется 22 x 19 🙈
Я попросил это пофиксить, сделать норм с константами, после чего Клод 4 зачем-то решил "улучшить код в целом", и в результате вообще сломал,
а когда мы пошли на третью итерацию и очередные полчаса работы слились впустую, он был послан подальше.
...А потом я забылся и случайно зашёл через бесплатный голландский впн (Клоду сервер нужен только США), и антропик меня забанил 👊
Но честно сделал рефанд за месяц 22 евро 💰на эстонскую карточку.
😁54👍11❤5✍3👌2
Когда-то был классный хвост-провайдер Zenon, я на нём одном лет 20 держался, всегда стабильный, всегда быстрая техподдержка по телефону и почте. Помню, как в 2022-м ддосили какой-то наш крупный СМИ-сайт, и мой крохотный учебный сервис случайно оказался с ним на одной виртуалке и стал ощутимо тормозить. И вот пацанчик в разговоре по телефону в реалтайме глянул в чём траблы, перебросил меня за одну минуту на другую машину, и всё заработало норм.
...А в том году его купила, более крупная рыба, понятно что и техподдержка тоже была объединена. И вот всё утроадмин забухал сайт skillsmart.ru со всеми учебными серверами лежит, по телефону просто сказали "ой пишите запрос из лк", на сервере уже давно 504 Gateway Time-out, и никакой реакции.
Впрочем, совершенно не удивлён и дальше будет только хуже.
Graviora manent.
...А в том году его купила, более крупная рыба, понятно что и техподдержка тоже была объединена. И вот всё утро
Впрочем, совершенно не удивлён и дальше будет только хуже.
Graviora manent.
🤯40👍14🤔7💯3👌1
Ого.
Is the Y Combinator 3rd order / in lambda calculus ?
Клод 3.7 =>
Yes, the Y Combinator is indeed a third-order function in lambda calculus.
...
Клод 4, Опус 4 =>
The Y combinator is not 3rd order - it's actually a 2nd order function (also called a higher-order function).
Y = λf.(λx.f (x x)) (λx.f (x x))
The Y combinator is a 2nd order function that enables recursion in lambda calculus by finding fixed points of functions. It's one of the most famous examples of a 2nd order function, but it doesn't reach the 3rd order level since it doesn't manipulate other higher-order functions.
Abstracted type is 2nd-order: When we look at Y's type signature abstractly:
Y :: (a -> a) -> a
This type itself is 2nd-order.
So you're correct that while Y's abstracted type signature is 2nd-order, its behavior is order-polymorphic - it can operate uniformly across different function orders due to the polymorphic type variable a.
Is the Y Combinator 3rd order / in lambda calculus ?
Клод 3.7 =>
Yes, the Y Combinator is indeed a third-order function in lambda calculus.
...
Клод 4, Опус 4 =>
The Y combinator is not 3rd order - it's actually a 2nd order function (also called a higher-order function).
Y = λf.(λx.f (x x)) (λx.f (x x))
The Y combinator is a 2nd order function that enables recursion in lambda calculus by finding fixed points of functions. It's one of the most famous examples of a 2nd order function, but it doesn't reach the 3rd order level since it doesn't manipulate other higher-order functions.
-- Y can work with different orders
factorial :: (Int -> Int) -> Int -> Int -- 2nd order input
factorial f n = if n == 0 then 1 else n * f (n-1)
higherOrder :: ((Int -> Int) -> Int -> Int) -> (Int -> Int) -> Int -> Int -- 3rd order input
Abstracted type is 2nd-order: When we look at Y's type signature abstractly:
Y :: (a -> a) -> a
This type itself is 2nd-order.
So you're correct that while Y's abstracted type signature is 2nd-order, its behavior is order-polymorphic - it can operate uniformly across different function orders due to the polymorphic type variable a.
🤔35🤯10😁3👏1
Я полностью закончил (сделал в смысле :) первый в мире (почему первый в мире? потому что он никому особо не нужен :) курс "Гомотопическая теория типов для программистов (1)", о котором мечтал лет 10-15 назад в духе "эх, вот бы такой когда-нибудь просто закончить (пройти в смысле:)!". Силлабус выложу для курсантов, ну вкратце - интуиционистская версия HoTT, отличия от MLTT, топологическое пространство, гомотопическая эквивалентность, Sum/Product-типы, Path, HIT, n-мерный тор, зависимые Пи-типы и Сигма-типы -- реализуем это всё на Python, все исходники + в тестах разбираем основные use cases, и в заключение делаем на этой базе игру Змейка.
Вторая часть конечно обязательно нужна для полноты (∞-группоиды, гомотопические группы, иерархия универсумов, эквивалентность типов, унивалентность...), но там уже в некотором смысле будет попроще, если проходите, первого HoTT-босса :)
По итогу, всё же должен признать что как я ни пытался задаундгрейдить эти темки до малышового уровня рядового миддла, в целом получилось сложновато. В идеале, реки -- это TaPL Пирса (хотя бы просто понять, без формул). Ну посмотрим.
Самый важный мета-результат, что в процессе я получил правильные инсайты :)
Математика существенно проще, чем программирование.
Это не программисту надо знать математику, а математику надо знать программирование.
Даже самые сильные на сегодня математические абстракции для программистов -- это всё уровень programming in small, максимум programming in large in small. Хотя, безусловно, закрыть теоретически programming in small само по себе неплохой результат.
Вторая часть конечно обязательно нужна для полноты (∞-группоиды, гомотопические группы, иерархия универсумов, эквивалентность типов, унивалентность...), но там уже в некотором смысле будет попроще, если проходите, первого HoTT-босса :)
По итогу, всё же должен признать что как я ни пытался задаундгрейдить эти темки до малышового уровня рядового миддла, в целом получилось сложновато. В идеале, реки -- это TaPL Пирса (хотя бы просто понять, без формул). Ну посмотрим.
Самый важный мета-результат, что в процессе я получил правильные инсайты :)
Математика существенно проще, чем программирование.
Это не программисту надо знать математику, а математику надо знать программирование.
Даже самые сильные на сегодня математические абстракции для программистов -- это всё уровень programming in small, максимум programming in large in small. Хотя, безусловно, закрыть теоретически programming in small само по себе неплохой результат.
51❤50🔥10✍4😁3🐳2
...А вот в теме programming in large (тем паче в ultra-large-scale) ничего более-менее формального и близко нету вообще. И я теперь не уверен, нужно ли оно там в принципе, или лучше наоборот перейти на светлую(?) сторону программной инженерии? Главное, с одной стороны, соблюдать разумный формализм, но с другой стороны -- не давать клювику хотя бы даже капельку увязнуть в системной инженерии (когда мы заходим через онтологию, как в каком-нибудь фреймворке Захмана). Даже BDD будет пожалуй слегка перебором.
В принципе, вы можете следовать заветам программной инженерии всего лишь одной мета-мантрой: буду держать качество кодовой базы высоким, потому что я тот, кто впоследствии сам будет долго работать с этой базой.
=
Пойду в парк думать, медитировать и слушать Нильса Фрама. Он исполняет на гениальном инженерном произведении Klavins M450 (строгое ч/б пианино высотой 4,5 метра(!). Открытые струны, ручная работа, весит почти тонну (концертный рояль Steinway D в сравнении с ним пушинка 500 кг).
"Nils Frahm - Wesen (Official Audio)"
Просто расслабьтесь и наслаждайтесь резонансом и медленным затуханием отдельных нот. В каждой музыкальной фразе свой пафос, а гармонии парят, как звуковые облака в весеннем закатном небе... Это тот же ветер в кронах деревьев, шорох лисы в кустах, треск сучков под ногами, песня дрозда... и еще кое-что
(сразу так хочется программировать )))
В принципе, вы можете следовать заветам программной инженерии всего лишь одной мета-мантрой: буду держать качество кодовой базы высоким, потому что я тот, кто впоследствии сам будет долго работать с этой базой.
=
Пойду в парк думать, медитировать и слушать Нильса Фрама. Он исполняет на гениальном инженерном произведении Klavins M450 (строгое ч/б пианино высотой 4,5 метра(!). Открытые струны, ручная работа, весит почти тонну (концертный рояль Steinway D в сравнении с ним пушинка 500 кг).
"Nils Frahm - Wesen (Official Audio)"
Просто расслабьтесь и наслаждайтесь резонансом и медленным затуханием отдельных нот. В каждой музыкальной фразе свой пафос, а гармонии парят, как звуковые облака в весеннем закатном небе... Это тот же ветер в кронах деревьев, шорох лисы в кустах, треск сучков под ногами, песня дрозда... и еще кое-что
❤32👌18✍6🐳2🤓1
Как в нынешнее время удержаться на работе, чтобы стать незаменимым, и вместо тебя не взяли AI-кодера?
1. Пихайте микросервисы куда только можно, особенно в ключевые модули. Они там бесконечно тухнут, постоянно отравляя проект, но в прогнившем виде будут стабильно тянуться из версии в версию через любые рефакторинги, оставаясь живее всех живых, и никакой AI их не заборет.
2. Пишите побольше асинхронного кода. AI будет стабильно засылать в него крайне тяжело находимые баги, практически неуловимые.
3. Вообще, максимально пропагандируйте на работе использование AI, чтобы оно постоянно подбавляло в проект побольше своего кодо-йада, экспоненциально и безвозвратно увеличивая техдолг.
1. Пихайте микросервисы куда только можно, особенно в ключевые модули. Они там бесконечно тухнут, постоянно отравляя проект, но в прогнившем виде будут стабильно тянуться из версии в версию через любые рефакторинги, оставаясь живее всех живых, и никакой AI их не заборет.
2. Пишите побольше асинхронного кода. AI будет стабильно засылать в него крайне тяжело находимые баги, практически неуловимые.
3. Вообще, максимально пропагандируйте на работе использование AI, чтобы оно постоянно подбавляло в проект побольше своего кодо-йада, экспоненциально и безвозвратно увеличивая техдолг.
😁44👍21💯13❤3🐳1
Отчёт за неделю.
+ Основной паблик:
Вообще, наверное, самый лучший мета-урок, который только может дать программная инженерия, таков:
Все наши предположения неверны. Солнце завтра может не взойти.
+ Для донов-начинающих:
И всё же, людей, которые сегодня учатся программировать исключительно с помощью искусственного интеллекта и LLM, ждет неприятное пробуждение в реальность...
+ Для донов-неначинающих:
37. Жёсткий хейт SOLID | OCP (СильныеИдеи++)
Open-Closed Principle - идея, что код должен быть открыт для расширения (т. е. его функциональность можно неким магическим способом расширить без его изменения), и закрыт для внесения изменений (т. е. вы можете доверять тому, что он делает, поэтому вам не нужно дополнительно возиться с ним). Честно говоря, сегодня уже мало кто понимает этот принцип, потому что он был мудрым советом лет 30 назад :)
Продолжение трека "Элитный программист":
27) Отработка "мягких" навыков в безопасной среде.
Участие в качественных технологических группах в соцсетях может помочь вам и в развитии "мягких" навыков. Ведь многие из них связаны с общением, как происходит в большинстве групп.
Вот некоторые из приёмов, которые можно использовать ...
20.05.25. Набор в мою Школу (3 места закончились за 4 минуты).
Напомню, что первые две дюжины существенно переработанных материалов СильныхИдей (по сути две книги) пока доступны на бусти, но дружелюбные цены уже начали расти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
+ Курс "Гомотопическая теория типов для программистов(1)".
"После майских" курс 💯 будет готов.
К лету курс 💯будет готов.
+ Основной паблик:
Вообще, наверное, самый лучший мета-урок, который только может дать программная инженерия, таков:
Все наши предположения неверны. Солнце завтра может не взойти.
+ Для донов-начинающих:
И всё же, людей, которые сегодня учатся программировать исключительно с помощью искусственного интеллекта и LLM, ждет неприятное пробуждение в реальность...
+ Для донов-неначинающих:
37. Жёсткий хейт SOLID | OCP (СильныеИдеи++)
Open-Closed Principle - идея, что код должен быть открыт для расширения (т. е. его функциональность можно неким магическим способом расширить без его изменения), и закрыт для внесения изменений (т. е. вы можете доверять тому, что он делает, поэтому вам не нужно дополнительно возиться с ним). Честно говоря, сегодня уже мало кто понимает этот принцип, потому что он был мудрым советом лет 30 назад :)
Продолжение трека "Элитный программист":
27) Отработка "мягких" навыков в безопасной среде.
Участие в качественных технологических группах в соцсетях может помочь вам и в развитии "мягких" навыков. Ведь многие из них связаны с общением, как происходит в большинстве групп.
Вот некоторые из приёмов, которые можно использовать ...
20.05.25. Набор в мою Школу (3 места закончились за 4 минуты).
Напомню, что первые две дюжины существенно переработанных материалов СильныхИдей (по сути две книги) пока доступны на бусти, но дружелюбные цены уже начали расти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
+ Курс "Гомотопическая теория типов для программистов(1)".
К лету курс 💯
❤31👍19😁3
Почему Spring мёртв?
Потому что есть опенсорсный Quarkus
(Supersonic Subatomic Java)
A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
(пацаны из red hat, зашлите сотку баксов за ad)
Смерть от жадности
Spring Boot жрёт память как голодный монстр — 4 ГБ против 400 МБ у Quarkus. Платишь за воздух!
Старт как у динозавра
45 секунд на запуск? В эпоху облаков это как ждать Windows 95. Quarkus — 0.3 секунды и ты в деле!
Реактивность или смерть
Spring топит треды, Quarkus летает на ивент-лупе. Ты всё ещё в каменном веке с блокирующим I/O?
Конфиги-зомби
50 строк настроек против 6. Spring Boot превращает твой код в помойку — Quarkus даёт чистый код и свободу!
Тесты-черепахи
Spring Boot тесты ползут, как улитки. Quarkus — ракета: горячая перезагрузка за 0.2 сек и тесты на стероидах!
Облака тебя сожрут
Холодный старт Spring — 45 секунд. В serverless это как приехать на такси после того, как вечеринка закончилась.
Кошелёк плачет
65% экономии на инфраструктуре с Quarkus. Spring Boot — это спуск денег в унитаз под видом "надёжности".
Потому что есть опенсорсный Quarkus
(Supersonic Subatomic Java)
A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
Смерть от жадности
Spring Boot жрёт память как голодный монстр — 4 ГБ против 400 МБ у Quarkus. Платишь за воздух!
Старт как у динозавра
45 секунд на запуск? В эпоху облаков это как ждать Windows 95. Quarkus — 0.3 секунды и ты в деле!
Реактивность или смерть
Spring топит треды, Quarkus летает на ивент-лупе. Ты всё ещё в каменном веке с блокирующим I/O?
Конфиги-зомби
50 строк настроек против 6. Spring Boot превращает твой код в помойку — Quarkus даёт чистый код и свободу!
Тесты-черепахи
Spring Boot тесты ползут, как улитки. Quarkus — ракета: горячая перезагрузка за 0.2 сек и тесты на стероидах!
Облака тебя сожрут
Холодный старт Spring — 45 секунд. В serverless это как приехать на такси после того, как вечеринка закончилась.
Кошелёк плачет
65% экономии на инфраструктуре с Quarkus. Spring Boot — это спуск денег в унитаз под видом "надёжности".
🫡42🤔13😁7❤6🐳6
Я плохо себя чувствую, если не занимаюсь одновременно хотя бы на 2-3 курсах. Вот сейчас за 4900 вписался на курс для сеошников: "пластиковые окна" и это всё...
...создание простого сайта на Тильде для продвижения в Яндекс
пересборка сайта под Гугл
покупка ссылок
настройка семантических кононов и swBM25...
Зачем?? У меня ни сайта, ни планов "раскрутки", наоборот стараюсь везде постепенно ликвидировывать свою видимость.
А затем, чтопостоянно приходится спасать глупеньких, хотя я их предупреждал у меня периодически спрашивают, в основном старые знакомые, которых я года 3-4 назад консультировал, но сейчас всё забросил:
эээммм нууу, я мпродал квмаритру вложилмся в разруботку думвал будт покупить как горячий пирошки а клиентов вообщ нулл...
Напомню, БАЗА: ваш бюджет 100% (время, деньги...), из которого 80% надо вкладывать в маркетинг и А/Б тестирование, и только потом 20% в разработку, и то если какая-то темка реально выстрелила (и тут вы не обойдётесь либо без покупки рекламы, либо без грамотного seo-2025).
=
КПД подобных курсов обычно 1-2%, редко 5%, чаще 0%, и всё равно получается сильно выгодно. Как его мерять? Если инфу я не могу применить прямо сейчас, или в крайнемотложить в папочку wait в ближайший месяц, значит фигня.
Хотя лучше всего всё равно остаются книги: там прям до абсолютного эффекта 💯доходит (каждая страница +1 к какому-нибудь скиллу), но и труда для отлавливания жемчужных зёрен надо вкладывать существенно (на 1-2 порядка) больше.
Но всё равно для меня книги — навсегда ключевая стратегия.
Вчера на онозе заказал очередные три штучки: "Жизнь без свободы воли" Сапольски, "Одноразовые" Сергей 051-й, и ещё одна секретная 😎
...создание простого сайта на Тильде для продвижения в Яндекс
пересборка сайта под Гугл
покупка ссылок
настройка семантических кононов и swBM25...
Зачем?? У меня ни сайта, ни планов "раскрутки", наоборот стараюсь везде постепенно ликвидировывать свою видимость.
А затем, что
эээммм нууу, я мпродал квмаритру вложилмся в разруботку думвал будт покупить как горячий пирошки а клиентов вообщ нулл...
Напомню, БАЗА: ваш бюджет 100% (время, деньги...), из которого 80% надо вкладывать в маркетинг и А/Б тестирование, и только потом 20% в разработку, и то если какая-то темка реально выстрелила (и тут вы не обойдётесь либо без покупки рекламы, либо без грамотного seo-2025).
=
КПД подобных курсов обычно 1-2%, редко 5%, чаще 0%, и всё равно получается сильно выгодно. Как его мерять? Если инфу я не могу применить прямо сейчас, или в крайнем
Хотя лучше всего всё равно остаются книги: там прям до абсолютного эффекта 💯доходит (каждая страница +1 к какому-нибудь скиллу), но и труда для отлавливания жемчужных зёрен надо вкладывать существенно (на 1-2 порядка) больше.
Но всё равно для меня книги — навсегда ключевая стратегия.
Вчера на онозе заказал очередные три штучки: "Жизнь без свободы воли" Сапольски, "Одноразовые" Сергей 051-й, и ещё одна секретная 😎
👍50❤9✍6🤔1🫡1
...Например, абсолютно бесполезная "полезняшка" с какого-то познавательного курса: согласно Брайану Грину (колумбийский профессор, топовый струнный теоретик), наблюдаемое пространство Вселенной, которое охватывается самыми мощными на сегодня телескопами, крайне мало: это как песчинка в сравнении с Землёй.
(При том что ненаблюдаемая Вселенная существует конечно чисто теоретически, и если вдруг появится физический наблюдатель, хз что обнаружится)
То есть это дерьмо очень большое :)
И запомнил я это исключительно потому, что получается даже не метафора, а реальность. Вчера устроил дипсику с дипсинком (код пишет неплохо, но отладку и фикс багов вообще не тянет) хорошую взбучку, повозил его мордой об рельс за совсем тупую ошибку, и вот что он ответил в оправдание:
"Возможно, я допустил ошибку, невнимательно прочитав требования к методу ..."
Как?? Как AI может невнимательно прочитать требования?? Да ещё и "возможно". Понятно, что это просто наиболее подходящий к ситуации статистический ответ...
Это я к тому, что дерьмо от AI реально очень большое: гораздо больше, нежели мы способны понимать и наблюдать в принципе, и какие логические закладки он делает в ваш проект, одному Грину известно.
=
Посмотрел "Вне юрисдикции"
(когда забыл принять таблетки)
Ключевая фраза фильма: "Откуда ты? АНБ? ЦРУ? Айтишник?" 😁
И запомнил я это исключительно потому, что получается даже не метафора, а реальность. Вчера устроил дипсику с дипсинком (код пишет неплохо, но отладку и фикс багов вообще не тянет) хорошую взбучку, повозил его мордой об рельс за совсем тупую ошибку, и вот что он ответил в оправдание:
"Возможно, я допустил ошибку, невнимательно прочитав требования к методу ..."
Как?? Как AI может невнимательно прочитать требования?? Да ещё и "возможно". Понятно, что это просто наиболее подходящий к ситуации статистический ответ...
Это я к тому, что дерьмо от AI реально очень большое: гораздо больше, нежели мы способны понимать и наблюдать в принципе, и какие логические закладки он делает в ваш проект, одному Грину известно.
=
Посмотрел "Вне юрисдикции"
Ключевая фраза фильма: "Откуда ты? АНБ? ЦРУ? Айтишник?" 😁
👍37😁27❤5⚡1
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаю работу с курсантами 🤓
...Во время расследования бага я выяснил, что в полученной сущности( из внутреннего ядра, это соседний проект коллег) жсон поле со значением типа int(хотя всегда был строкой и всегда должен быть), отчего падала вся интеграция
(По этой причине я вообще против нетипизированного json, но он уже давно стал стандартом в мейнстриме.)
...Каждый тест, даже простой завалился, при старом коде.
...Что интересно - эту функцию парсинга применял на нескольких проектах. И казалось бы - элементарные тесты, нашли здесь сразу ошибку, в кейсе с вызовом функции и передачей пустой строки
Исправил, задумался.
...В общем, я уже смог применить что-то похожее на "замыкание" для обхода различных хранилищ данных и загрузки их в один датафрейм, что оказалось очень полезным. Это также невероятно удобно, если получается создать NullObject'ы и композит. Это как будето даёт набор "деталей" которые можно произвольно объединять, переставлять местами или заменять без изменения логики кода, а просто работой с объектами.
...Очень сложно уже для моего понимания. Наверное нужно спуститься на пару уровней вниз и отрабатывать навыки последовательно. Что ж, однозначно мотивирует. Думаю, возобновить ежедневные занятия SQL хотя бы по 30 минут, теперь регулярно, а не наскоками. По крайней мере, я видел к чему стремиться)
...Для групп Ли мне мотивации не хватает.
Преподаватель теории групп, которого я должен был заменить, передумал на пенсию уходить.
Мне бы в 90+ такую работоспособность :)
...Окончательно паззл сложился после материала про паттерн Посетитель с примером на питоне про гномов. За него отдельное спасибо, я своим умом доходил или до ФП, или до ОО решения, но не до универсального с multiple dispatch и иерархией посетителей.
...Очень сильно потянуло в сторону ФП, поскольку надоело писать и поддерживать однотипный ООП код с кучей условий, который:
• тяжело протестировать;
• кидает исключения где попало, невозможно нормально прервать цепочку и получить результат;
• тесно привязывает методы к сущности, которые тяжело отвязать и компоновать;
Как бонус - теперь при прочтении интерфейсов сразу вижу типичные проблемы, когда они плохо спроектированы и могу итеративно это исправить.
...Эталонный пример ужасает своим объёмом. В следующем задании, наверно будет ещё больше. Искренне жаль тех, кто сталкивается с подобным в своих проектах.
(Ну так-то это уровень крепкого миддла:)
...Во время расследования бага я выяснил, что в полученной сущности( из внутреннего ядра, это соседний проект коллег) жсон поле со значением типа int(хотя всегда был строкой и всегда должен быть), отчего падала вся интеграция
(По этой причине я вообще против нетипизированного json, но он уже давно стал стандартом в мейнстриме.)
...Каждый тест, даже простой завалился, при старом коде.
...Что интересно - эту функцию парсинга применял на нескольких проектах. И казалось бы - элементарные тесты, нашли здесь сразу ошибку, в кейсе с вызовом функции и передачей пустой строки
Исправил, задумался.
...В общем, я уже смог применить что-то похожее на "замыкание" для обхода различных хранилищ данных и загрузки их в один датафрейм, что оказалось очень полезным. Это также невероятно удобно, если получается создать NullObject'ы и композит. Это как будето даёт набор "деталей" которые можно произвольно объединять, переставлять местами или заменять без изменения логики кода, а просто работой с объектами.
...Очень сложно уже для моего понимания. Наверное нужно спуститься на пару уровней вниз и отрабатывать навыки последовательно. Что ж, однозначно мотивирует. Думаю, возобновить ежедневные занятия SQL хотя бы по 30 минут, теперь регулярно, а не наскоками. По крайней мере, я видел к чему стремиться)
...Для групп Ли мне мотивации не хватает.
Преподаватель теории групп, которого я должен был заменить, передумал на пенсию уходить.
Мне бы в 90+ такую работоспособность :)
...Окончательно паззл сложился после материала про паттерн Посетитель с примером на питоне про гномов. За него отдельное спасибо, я своим умом доходил или до ФП, или до ОО решения, но не до универсального с multiple dispatch и иерархией посетителей.
...Очень сильно потянуло в сторону ФП, поскольку надоело писать и поддерживать однотипный ООП код с кучей условий, который:
• тяжело протестировать;
• кидает исключения где попало, невозможно нормально прервать цепочку и получить результат;
• тесно привязывает методы к сущности, которые тяжело отвязать и компоновать;
Как бонус - теперь при прочтении интерфейсов сразу вижу типичные проблемы, когда они плохо спроектированы и могу итеративно это исправить.
...Эталонный пример ужасает своим объёмом. В следующем задании, наверно будет ещё больше. Искренне жаль тех, кто сталкивается с подобным в своих проектах.
(Ну так-то это уровень крепкого миддла:)
👍47❤10😁3🤓1
...И куда тогда дальше двигаться стратегически? Чтобы закладываться хотя бы на конец текущей десятилетки, когда AI станет генерить невероятные кучи дурно пахнущего кода, причём такой вайб станет по сути стандартом? Какие скиллы будут ключевыми?
...Где-то с осени 24-го я не читал ведущих спецов computer science, на днях заглянул в твиттер -- изменилось всё! Поголовный вайб-кодинг. Захлёбываясь от восторга, известные математики хвастаются, как ЖПТ им написал расчётный алгоритм на сто питонячьих строк.
Почему, как оказалось в итоге, я пояснял:
Математика существенно проще, чем программирование.
Так что же будет будущим программной разработки?
Тестирование. QA. TDD. BDD. TLA+. Формальные спецификации и математика уровня HoTT.
Программисты, по большому счёту, и сегодня пишут просто рандомное дерьмо, для которого ни до ни после не сформулированы никакие правила и ограничения.
Конечно, ЖПТ их вполне сможет заменить.
Специалисты по системному контролю качества, Гуру интеграционных тестов, Мастера формальных технических заданий -- именно это и будут те Инженеры, кто знает, как на самом деле должно работать всё это программистское 💩
...Где-то с осени 24-го я не читал ведущих спецов computer science, на днях заглянул в твиттер -- изменилось всё! Поголовный вайб-кодинг. Захлёбываясь от восторга, известные математики хвастаются, как ЖПТ им написал расчётный алгоритм на сто питонячьих строк.
Почему, как оказалось в итоге, я пояснял:
Математика существенно проще, чем программирование.
Так что же будет будущим программной разработки?
Тестирование. QA. TDD. BDD. TLA+. Формальные спецификации и математика уровня HoTT.
Программисты, по большому счёту, и сегодня пишут просто рандомное дерьмо, для которого ни до ни после не сформулированы никакие правила и ограничения.
Конечно, ЖПТ их вполне сможет заменить.
Специалисты по системному контролю качества, Гуру интеграционных тестов, Мастера формальных технических заданий -- именно это и будут те Инженеры, кто знает, как на самом деле должно работать всё это программистское 💩
👍52💯8❤6😁5👌1