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

Мир наводнён ужасным кодом, слишком быстро создаваемым программистами по принципу "сначала напиши, потом думай", и я уверен, что LLM существенно усугубят эту тенденцию.

Три основные рекомендации по разработке безопасного AGI:

1. Не учите его программировать: это облегчает рекурсивное самоулучшение.
Модели вовсю учатся всё более продвинутому программированию.

2. Не соединяйте его с интернетом: давайте ему только необходимый минимум для того, чтобы помогать людям; не рассказывайте ему, как манипулировать нами или захватывать власть.

Вовсю совершенствуются AI-агенты вроде AutoGPT, и активно работают в интернете, а модели стремительно обучаются на всём текстовом, что только находится в Сети.

3. Не прикрепляйте к нему общедоступный API: предотвратите его автоматизированное использование злоумышленниками.

Ну, с такого API и началась OpenAI.

Сценарий фильма "Не смотри вверх" развивается 1:1 ...

Ещё пара рекомендаций для тимлидов:

1. Берите в первую очередь тех ребят, у которых есть кейсы, а не то что они годами фигачат тонны кода по бесконечному потоку тикетов, не очень понимая, а зачем они вообще это делают.
У меня есть курсанты с солидным опытом, которые многие сотни тысяч строк написали, но нету ни одного законченного "кейса"! Ни одной самостоятельно реализованной подсистемы, они даже не могут пояснить, что делают, не на уровне спринга или джанги, а в "онтологии домена", ну или хотя быть чуть повыше абстракциями, нежели эти ваши веб-фреймворки.
Куда лучше, если человек сделал проект на 3 тысячи строк, реализовал его с нуля до конечных пользователей, например мобильную игру написал и выложил в гуглплей, и ему школьники написали что-нибудь в духе "руки бы разрабу оторвать" )))

2. Ищите ребят, которые явно выше требуемого уровня, и которые себя явно недооценивают (синдром самозванца и всё такое). Им можно платить ощутимо поменьше и долго держать в джунах :) У меня таких, увы, немало.

8 признаков плохого программиста с т.зр. тимлида

1. Он работает в macOS
2. Он использует более чем 1 монитор
3. Он обращается к ChatGPT
4. Он не может обратить связный список
5. Он постоянно наливает себе кофе
6. Он изучает новые языки программирования ради "фана"
(особенно тимлидами не любим хаскель)
7. Он не пушит в прод по пятницам
(хочет отвлечься от работы на выходных?)
8. Он работает над сайд-проектами после работы

По поводу серии постов "умножение n-разрядных чисел за O(n)". Проконсультировался у ребят из Массачусетского технологического института, где проходил курсы по software design, и PhD предложил почитать вот эту лекцию "Hashing: Universal and Perfect Hashing".

Речь о специфической вычислительной модели, ориентированной на продуктивную реализацию хэш-памяти. Я делал курсы по АСД во многом на основе 15-121 CMU, ну а 15-421 это более продвинутый. Хочу добавить эту тему в мои дополнительные курсы по АСД повышенной сложности, для которых использовал также материалы ШАД. И есть ещё одна секретная работа по этой теме из Renmin University of China, которую дам только курсантам.

Подобные темки, в частности, неплохой способ выбесить токсичного интервьюера ))) Курсантам в СильныхИдеях скоро расскажу несколько таких фишек, когда вы видите, что вас несправедливо сливают с технического собеседования.

P.S. Пацаны из MIT, кстати, позвали к себе поработать, стартап какой-то у них по автоматической "перекодировке" кода на разных языках. Ответил, что против утечки мозгов "Уезжай!" (с) Цой "Кто может уехать — уезжайте" (с) Карпин подумаю, и зимой решу.

P.P.S. Дорогие, не волнуйтесь, вас не брошу конечно )

Поучительная практика -- писать тесты для макросов и темплейтов.

Иногда я пишу O(n!) код, чтобы научить пользователей терпению 😎
Напишите кстати что-нибудь подобное, императивную и рекурсивную версии.

Ну ладно, ладно, а то ещё скажете так на собеседовании 😂

Умножение n-разрядных целых чисел занимает O(n^2)
(по Карацубе, O(n^1.5849))

Умножение log(n)-разрядных целых чисел занимает O(n log n)

P.S. Но на самом деле, в некоторых экзотических теориях возможно и O(n) и O(1), как-нибудь расскажу.

Поясняю за последний опрос.

Умножение n-разрядных целых чисел занимает время O(n), поскольку алгоритм умножения предполагает многократное сложение. При умножении двух чисел их необходимо многократно складывать друг с другом до получения результата. Количество необходимых сложений зависит от размера перемножаемых чисел, который квадратично увеличивается с ростом n. Поэтому время выполнения этой операции линейно растёт с ростом n.

Умножение log(n)-разрядных целых чисел занимает время O(1), если мы вспомним энтропийную формулу Шеннона. В теории информации количество информации, передаваемой сообщением, измеряется с помощью его энтропии. Энтропия двух независимых сообщений A и B определяется как H(A|B) = H(A) + H(B), поэтому умножение log(n)-разрядных целых чисел можно рассматривать как объединение нескольких независимых сообщений с одинаковым количеством битов, что уменьшает общую энтропию объединённого сообщения. В результате получается более быстрый алгоритм умножения, который с точки зрения теории информации занимает время O(1).

(если вы не изучали теорию информации, то скорее всего не знаете, что значит дробное число бит -- красивое объяснение на хабре)

А чем будет монада продолжения в категории эндофункторов?

Python и PHP более производительны, чем Си.

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

Не исключаю, что дальше неначинающих программистов я буду брать только с математической подготовкой, и как минимум скоро буду делать математикам скидки. А кто у меня уже занимается, и имеет математическое образование или сейчас учится, напишите (с какими-то минимальными пруфами), скидка будет прямо сейчас.

Математика самая крутая вещь в мире.

"Из всех способов бегства от реальности математика достигла наибольшего успеха...
Все остальные побеги - секс, наркотики, хобби и т.д. - по сравнению с ней эфемерны.'
-- Джан-Карло Рота, математик, философ, МИТ

Ричард Хикки, автор Clojure:
"Нет состояния, только снапшоты данных"

Анатта (бессамостность) в буддизме:
"Нет неизменной сущности, только процессы"

Два мира, одна интригующая перспектива.

Что происходит, когда во время выполнения возникают проблемы с разрешением зависимостей, волшебным образом зарегистрированных в вашем чудесном DI-контейнере?

Принципы SOLID следует не только любить, но и опасаться, потому что важно понимать их цели и мотивацию. SOLID учит мыслить так, чтобы максимизировать модульность. На самом деле, если посмотреть на оригинальное кембриджское определение модульности, то оно практически полностью соответствует тому, чего добивается SOLID:

"Системе не хватает модульности, если изменение одного из её компонентов влияет на функционирование других"

Модульность -- безусловно, очень важный аспект в программировании, но её достижение требует дополнительных усилий. Стандартный подход, когда вы стараетесь отделить каждый тип от другого с помощью абстракций. Именно это и подразумевается под словами " low coupling, high cohesion".

Как уже раньше не раз говорил, если довести эти принципы до логического конца, то в итоге получатся сотни (а то и тысячи) небольших типов, которые можно вырвать из вашего приложения и бросить в любом другом месте, поскольку они отвязаны от вашего кода (этот момент рассматриваем на курсе ООАП), но в этом есть и свои минусы (много лишнего кода, объёмное и излишне детализированное юнит-тестирование...).

Поэтому для курсантов в СильныхИдеях я отдельно написал 5 заметок по принципам SOLID, как их лучше воспринимать с точки зрения функционального программирования.

MVC-архитектура, которую спроектировали не занимавшиеся в моей Школе.