Лаборатория Математики и Программирования Сергея Бобровского

При всех разговорах о сложных инженерных профессиях программисты в среднем намного умнее своих коллег из этих профессий. Потому что computer science = абстрактное мышление + решение "головоломок". Абстрактное мышление в целом скорее противоречит инженерным подходам, которые по определению ориентированы на практику и физическую реальность, но оно очень важно для того, чтобы быть умным.

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

Меритократия наше всё.

P.S. Особенно AI-меритократия :) Слава роботам!

Понемногу активирую Волшебный МультиПендаль 2024.

Существенно обновил "дипломный" проект, который в основном делают ребята, кто готовится к работе на бэкенде (для курсантов проект обязателен и бесплатен, но наверное сделаю и платную версию "для всех"). Фреймворк (разные для Java, Python, C#, Go, PHP...), CRUD, REST, отношения между модельками ORM (1-1, 1-многие, многие-многие), авторизация/видимость, пагинация, таймзоны, ui с бутстрапом, геоданные, и ещё немало другого по мелочам. Забираемся внутрь ORM, делаем бота, упаковываем в докер, деплоим.
Это то что было, и вот добавил ещё несколько темок: кэширование, логирование, документирование API, интеграционные тесты, ci/cd, транзакционная работа, микросервисы :)
Всего 34 задания (пока) получилось.

Кто проходил со мной этот проект, рекомендую доделать новые фишки.

Лучшие тесты выполняются дважды: один раз с моками, другой -- без.

Тест без мокинга наиболее полный, но может упустить некоторые важные моменты. Если вы вызвали API и он вернул правильный результат, это ещё не значит, что вы отправили ему правильный запрос. Вы можете получить неприятные побочные эффекты.

Скоро в СильныхИдеях выложу мощный контринтуитивный материал про правильный подход к организации тестирования крупных систем.

Rust это отличный DSL для блокчейнов.
А метапрограммирование по воздействию на мозг куда круче любых веществ.

...и по СильнымИдеям:

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

И 81-й -- про миграции (ORM-ы с роллбэком). Это сложно, но на практике оказывается ещё сложнее )))

Почему down-миграции, которыми так хвастают многие фреймворки -- дескать это чуть ли не ключевая их фича -- на практике не работают. Разбираем 4 неочевидных подводных камня (в дополнение к highload-курсу по транзакциям).

Для курсантов в раздел "Элитный программист" добавил 37-й материал "Как справляться с некомпетентными новичками".
К программистам придираются далеко не только нетехнические менеджеры и офисные начальники. Я уже сбился со счёта, сколько раз наблюдал, как опытные программисты возмущаются глупыми ошибками, которые допускали младшие разработчики. Но это тоже ситуация, с которой можно справиться, взяв ответственность на себя.
Например, сеньоров раздражает, когда джуниоры не используют git, или фигачат комиты сразу в мастер, не пишут юнит-тесты, задают глупые вопросы, ответы на которые можно нагуглить за пять минут...
Действительно, возня со всем этим отнимает у старших немало времени и сил. И вот что с этим делать ...

и 38-й - "Как справляться с назойливыми рекрутерами".
Рекрутеры в исходной задумке -- это здорово. Подразумевается, что вам как профессиональному разработчику больше не нужно подавать множество заявок на вакансии вручную. Остальное сделают рекрутеры, и те из них, которые полагают, что вы подходите на доступные им вакансии, начнут звонить вам.
Но рекрутеры -- это обычные продавцы, работающие по заказу ...

На курс карьеры добавлен 83-й материал "Как проходить стажёрство/испытательный срок". Главное, что вам надо делать, когда вас взяли стажёром или на испытательный срок -- это понять 5 важных принципов...

Пять лет не заглядывал в линкедин, вчера посмотрел, и вот что я написал там в 2019-м =>

"Обучаю MLTT, HoTT, индуктивным типам, процесс-алгебрам/pi-калкулусу, кодированию топосов, hopf fibrations и прочей попсе, которая сделает вас полностью unemployable." )))

Но сам сервис стал совсем зашкварным. Вот кстати фишечка, как скрыть все "рекомендуемые" посты:
https://www.linkedin.com/#%23span:has-text(/Suggested/):upward(4)

LLM-ки не займут ваше рабочее место.
А если и займут... что ж, это больше говорит о ваших способностях, нежели о способностях модели.

Новый пост: Как сделать ИТ-Россию великой, и зачем нам стремиться к зарплате/доходу в миллион рублей в месяц.

А как достичь x1000 ? Легко и просто.
Например,

1. Переходите с C# на F# и получаете в 10 раз меньше кода и в 10 раз выше надёжность (за счёт более сильной системы типов).
= x10

2. Переходите с F# на F* (всё никак не выложу моё введение во введение в F*) и получаете следующие x10 за счёт мышления в парадигме зависимых (от значений) типов.
Вы учитесь "сворачивать" разрабатываемую систему во всё более мощные абстракции.
= x100

3. Переходите с F*, ну куда-нибудь "окончательно" в "высшие" типы, HKT, HoTT...
Получаете за счёт "просветления" ещё x10. Начинаете думать непосредственно на языке предметной области, который формализован в вашем уме через соответствующие абстракции.
= x1000

...

Да, но, Сергей Игоревич, мы ведь вынуждены писать на C#...

Так просветление и подразумевает процесс полного совпадения мышления в языке домена с прозрачной реализацией сформулированной на нём системы на любом языке программирования. Я пояснял, почему это трудно -- потому что мы строим ментальную модель системы инженерно, совсем слабыми абстракциями, а то и просто наобум. Она получается неполной, нечёткой, хрупкой, постоянно разваливается...
Так делать это надо через математику.

Никто вам не мешает начать использовать уже сегодня на C++Rust/C#/Java любые фишки сперва функционального программирования, затем завтипы, и так далее. Есть соответствующие библиотеки, а некоторые языки можно нативно расширять (для F#, помнится, было расширение по зависимым типам).

Вы можете начать в любом языке, например, с использования императивных монад, монад I/O, монад побочных эффектов, выразите через монады мутабельность, потом переходите к свободным монадам, in-bounds/out-of-bounds...

Есть такое важное понятие, как типо-безопасность, в computer science более известное как soundness. И есть также понятие логической консистентности, которое с ним часто путают. Так вот, soundness -- это про то, что термы "не могу ошибаться". Терм у нас может быть либо значением, либо его можно продолжать редуцировать дальше.

Например, мы определили деление как операцию только для ненулевых знаменателей. Тогда терм 'x / 0' нельзя далее редуцировать, но он при этом и не значение.

=
А логическая консистентность подразумевает, что не существует способа сконструировать терм из любого типа.

Ну например в F# возможно такое:

let rec foo() = foo()

Задайте foo любой тип, и получите терм этого типа.

Это означает, что данный язык плохо подходит для организации логических построений. А в общем случае все Тьюринг-полные языки логически неконсистентны.

=

И что из этого? Ну, не понимая такие вещи, вы не сможете продуктивно программировать на языках с зависимыми типами, да и вообще работать с HoTT-типами, следовать type-level программированию и метапрограммированию с dsl-ями, да и просто правильно применять генерики. И никогда не станете x1000 программистом.

Хватит уже лежать физиономией в салатах, поднимайтесь! :)

Эта девушка занимается на моих курсах, и в Новый Год её волнует только один вопрос: как гарантировать холодный старт системы, в которой кэша нету принципиально, за 100 мс?

С Наступающим! 🎄🎄🎄🎄

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

Исходники GTA кстати ужасающи, сплошной говнокод.

У меня ребята, кто прошли самые первые начальные курсы с полного нуля, такое не пишут. Высокая цикломатическая сложность, циклы, вложенные в условия, вложенные в циклы, while вместо for, куча unsafe указателей...
Смесь плюсов, питона и, вроде, max script... Нескончаемые сотни багов, некоторые из которых стали культовыми...

И ведь это не исключение, а самый что ни на есть печальный стандарт разработки в мэйнстриме.

Единственная причина, по которой люди считают функциональное программирование сложнее, чем императивное/ООП, заключается в том, что они просто сталкиваются с ним позже. Поэтому в топовых университетах мира уже с первого курса студентов принуждают к хаскелю…

И вот когда обычный программист почти справился с ужасами управления памятью, мутабельными типами данных, дизайном и наследованием классов, модификаторами доступа к полям, запоминанием того, какие вещи могут быть null, а какие нет, и т. д. и т. п., используя компиляторы, которые делают самый минимум, чтобы помочь вам со всем этим, и сборщики, которые больше запутывают ваш проект... И теперь вы хотите поговорить с ним о совершенно новой функциональной парадигме, которая использует "математические принципы"? Нет, бро, пожалуйста, не надо, я так устал от этого всего...

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

Ну, в целом, конечно, неполнота по Гёделю это факт, но в каждом конкретном проекте достичь идеала вполне возможно, и это как раз давно доказано и математически, и инженерно.

А вы уже начали собирать GTA 5 из утекших исходников (40 гиг)?

Когда отправил пулл-риквест в свою любимую игру, а тебе ответили:
"Thanks for the report. This will be fixed in 2.0. In the meantime you can work around this issue by simply not doing that"
😁

То, чему я учу на курсах -- на 90% академические университетские темки. Но это не взятые с потолка условные курсы по матану например (маркетинговая "математика для программистов"), нет.

Я отобрал курсы для 5 ключевых треков, которые действительно поднимут вас до звания Программист — так, как эта самая сложная инженерная профессия понималась ещё лет 20 назад.

1. Как понять в программировании всё. Семантика Software Design, 5 базовых вычислительных моделей (декларативная/функциональная, императивная, объектная, реляционная, и UI-модель).
2. Объектно-ориентированный анализ и проектирование.
3. Функциональное программирование.
4. Теория highload-систем.
5. Параллельные вычислительные модели.
+ формат hard work (software design на практике).

Это вечные классические темы, к которым и прибавить особо нечего.

Вы не только узнаете программистскую истину, но и познакомитесь со всем мета-стеком научных понятий информатики, а не только с теми кусочками, с которыми вы оказались случайно связаны по работе.

Потому что без знания базы вы будете работать со всеми языками и технологиями как с "чёрными ящиками". Но "чёрный ящик" редко оправдывает свою репутацию. Да, есть вещи, которые могут оставаться "чёрными ящиками" какое-то (возможно, и весьма долгое) время в вашей карьере, но в конце концов это просто чья-то абстракция. И в конце концов, без понимания она обязательно даст течь =>
"The Law of Leaky Abstractions"

Поэтому будьте готовы забраться в эту кроличью нору как можно глубже, и посмотреть, во что будет превращаться ваш код. Вам будет от этого только лучше.

Читал статью "An algebra for distributed Big Data analytics", хотел в одном из курсов уточнить, в ней утверждается, что MapReduce всегда будет работать корректно, если промежуточная структура данных, полученная на фазе map -- это моноид в категории эндофункторов для операции reduce.

Напомню, кто проходил мои курсы по highload-системам:

"MapReduce -- модель программирования низкого уровня, предназначенная прежде всего для распределённых вычислений на кластерах машин. Языки запросов более высокого уровня, такие как SQL, можно реализовать в виде конвейера операций MapReduce.
Reduce также потенциально допускает параллельное вычисление -- например, список можно разбить на два, и редуцировать каждый из них независимо, и так далее рекурсивно."

Например, в Hadoop используется вариация MapReduce, которая сперва распределяет блоки данных по физическим узлам, которые далее обрабатываются map параллельно, и формируется временное хранилище ключ-значение. Затем происходит перераспределение: данные с одинаковыми ключами объединяются на конкретных узлах, и теперь они хорошо пригодны для дальнейшей обработки reduce в рамках каждого узла.

Однако сильное подозрение, что моноида будет недостаточно, потому что все типичные примеры вроде карт частотности ключей -- это на самом деле коммутативные моноиды при соответствующей операции reduce.

=

Вот кстати в тему отличные статьи "Абстрактная алгебра в действии" (примеры на прозаическом шарпике!), крайне рекомендую для ознакомления =>
https://habr.com/ru/articles/655059/
https://habr.com/ru/articles/656919/

Автор Степан (StepOne) классно пишет в тг "немного технической духоты на C#" :)

Его блог -- эталонный пример, кем вы должны становиться, если занимаетесь в моей Школе. Дико таких ребят уважаю.

Дорогие, ну пишите что-то подобное на Java например (или на F# :), и вас эйчары будут с руками рвать и на коленочках приползут умолять.

=

Так вот, моя гипотеза, что параллельный MapReduce будет давать корректные результаты, только если промежуточная структура данных, которую мы подготовили на фазе map, есть коммутативный моноид при операции reduce. Это более строгое условие для обеспечения действительной корректности крупных реализаций MapReduce, рассчитанных на BigData.

Ну если совсем для малышей: к reduce порядок элементов может случайно меняться из-за параллелизма, и если операции над ними не коммутативны, то итоговый результат может быть ошибочным. Темку недетерминизма мы разбирали, в частности, на курсе по декларативной вычислительной модели ("старайтесь никогда не использовать вместе параллелизм и состояния").

(добавил в курс "33 стиля программирования")