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

Западный стиль обучения такой, что например
сперва вы вообще не знаете про существование некоторого фреймворка (вы не знаете, что вы не знаете),
затем вы узнаёте о его существовании и предназначении, но пока не умеете его использовать (вы знаете, что вы не знаете),
затем вы начинаете долго и мучительно его изучать :)
(вы знаете, что вы знаете -- запустился ресурсоёмкий и нагрузочный процесс сознательного обучения нейросетки в вашей голове),
и наконец после всех тренировок вы используете этот фреймворк свободно, без напряга, "автоматически" (нейронная моделька обучилась, и теперь вы не знаете, что вы знаете).

Восточный подход однако совсем другой, и на продвинутых темах по software design я стараюсь использовать уже его. Сперва учитель даёт множество странных задачек, решение которых вы находите с трудом, и фактически не понимаете, зачем они вообще нужны ("а что мне это даст на практике?" :). Однако со временем, через многие десятки задач, вы внезапно обнаруживаете, что казавшееся ранее сложным рабочее задание по проектированию или архитектурам выглядит совсем простым и лёгким для реализации.

Так, кстати, устроены некоторые топовые курсы по computer science лучших университетов мира.

Сейчас программистские вакансии на 300k/секмес хочут большую кучу всего, и при этом кандидатов отбирают (пока ещё) достаточно придирчиво. Да, но это всего лишь три тысячи долларов (и далее будет, вероятно, ещё меньше); в США джуниоры получают больше, а за аналогичное множество скиллов платят от 150 тыс. долл. в год.

Вдобавок, общемировая (и соответственно, российская) специфика ИТ такова, что половина опытных специалистов не имеют профильного высшего образования, поэтому ситуация выглядит совсем печально.

При отличной подготовке практически любой нормальный человек может превзойти талантливого человека с нормальной подготовкой.

Именно это я и стараюсь обеспечить.

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

А также всегда масштабируются вертикально.

"Intelligent Machines and Idiotic Humans: A Startup Story"
(идеи для AI-стартапов)

Серия 9. Больше программирования и оптимизации.

В предыдущих сериях я немного заблуждался стратегически, потому что у хороших разработчиков (особенно у моих курсантов :) есть уникальный скилл продвинутого кодинга, и предлагать им клепать по шаблону всяческие AI-генераторы логотипов или другие обёртки GPT API в виде конечных продуктов для масс, которые легко пилятся на коленке и через три месяца потонут в тысячах аналогов, ну такое.

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

Вот же она, золотая жила! :) Вдобавок хайп здесь легко ловится.

Скорострельность соответствующего софта играет очень большое значение, и вы можете сегодня (пока ещё) весьма легко войти в мировую AI-тусовку, стать в ней достаточно известным. Поизучайте нутрянку самых распространённых библиотек, последите за последними новостями в AI и LLM (в тг немало хороших авторов), и для начала точечно выберите буквально один файлик для оптимизации. Выложите в опенсорс, напишите авторам этих либ или любым другим известным заинтересованным, и можете получить в итоге огромный бонус как минимум в плане личного бренда (ведущие технологические компании любят хантить тех, кто делает достаточно стоящие пулл-риквесты в известные опенсорсные системы).

Например, один из самых популярных AI/ML фреймворков PyTorch (по нему у меня скоро будет курс) написан, очевидно, на Python :) что уже намекает.

Вот наглядный пример:
https://news.ycombinator.com/item?id=35171527

Некто переписал llama.cpp (это не файл, а порт фейсбуковской лламы на сишечке, для автономного запуска на своём компе, хотя по сути один основной файл и есть) на раст, и сразу привлёк к себе внимание. Посмотрите, он уже на 8-м месте в рейтинге, хорошо поднимается, и в мете его наверняка заметили:
https://ossinsight.io/collections/chat-gpt-alternatives/

llama . rs работает (вроде бы) быстрее чем порт на плюсах, экономнее в плане памяти и, что весьма важно, надёжно и безопасно (для чего раст и создавался). Оригинальный код llama.cpp кстати в целом простой, никакой особой логики, но надо хорошо понимать сам алгоритм и структуры данных. В данном случае на расте запилили высокоуровневые абстракции, где используются структуры данных из сишной тензорной либы ggml, и затем ей передаются веса для вычислений. PyTorch используется для конвертации оригинальных весов.

Где и что несложное для начала можно попробовать пооптимизировать, спросите например LLaMA, и попросите её помощь )

P.S. Карпатый, кстати, на днях нафигачил инференс llama2.c , впихнув его в автономные 500 строк кода, после чего запустил на какой-то овощеварке )))

Задачка на выходные:
- переписать эти 500 строк на расте,
- запустить на bare metal,
- запостить в комбинатор,
- профит

Ну и стратегически rust всё же полезно изучить как следует, одни аффинные типы чего стоят ) Даже просто в виде карго-культа переписывать на него си-код -- дескать получаем больше безопасности, инвесторы на это хорошо ведутся.

Программисты NASA явно не проходили мой курс Ясный код )))

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

Когда спроектировал правильную архитектуру, и тимлид тебя спрашивает:

- Как остановить работу наших serverless воркеров?

- Никак. Они бессмертны.

- Можно ли убить узел, на котором они работают?

- Да, но он быстро вернётся и продолжит работу с того места, на котором остановился.

- Что же я могу сделать, чтобы вырубить воркеры??

- В любом случае ты сдашься раньше, чем они.

Весь мир сегодня работает на программном обеспечении.

Соответственно, невозможно изменить мир, не изменив его софт.

Поэтому мы должны максимально избегать создания "жёсткого" кода, который вообще трудно изменить.

Мы также не должны создавать хрупкий код, который можно слишком легко изменить так, что он превратится в нечто сломанное.

Хороший код легко расширять и трудно сломать. Сила проектного дизайна заключается не в том, что код может сделать, а в том, что код не может сделать.

Я посылаю моих учеников как матёрых волков среди толп овец: идите и изменяйте мир через изменение и улучшение программного обеспечения!

:)

Вы особенные, цените это.

Люди, активно использующие сервисы вроде AutoGPT, предлагая достаточно сложные задания AI-ботам, стали регулярно обнаруживать, что эти боты (видимо в целях облегчения своего труда и перекладывания ответственности :) пытаются создавать бесконечные копии самих себя. Пока неудачно, но... Агенты Смиты уже почти тут.

P.S. На днях AI за 6 часов придумал 40,000 новых вариантов химического оружия.

Dario Amodei (CEO of Anthropic) заявил в июле в Сенате США, что осталось 1-3 года до того, как AI обеспечит полноценную возможность "large-scale biological attacks" (супервирус, возможно, атакующий людей конкретной расы, или, например, активирующийся в конкретных географических регионах под воздействием какого-нибудь специфического излучения 6G :).

P.P.S. Государства и правительства по всему миру начали экспоненциально терять свою реальную силу. Стоимость обучения LLM стремительно снижается, и истинными властителями мира на некоторое время (до приближения технологической сингулярности) становятся крупнейшие ИТ-компании. Понятно, что они ещё несколько лет будут тотально контролироваться спецслужбами, но, во-первых, искушение шантажировать власть серьёзными угрозами слишком велико и соблазнительно, и далеко не каждый сможет этому искушению противостоять (недавно был тому яркий пример), а во-вторых, технологии, доступные сегодня только ИТ-гигантам, через считанные годы любой сможет запускать на своём ПК...

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

Однако часто довольно легко предсказать, что именно изменится в коде. Или даже где.

И это -- всё, что нужно для создания эволюционирующего кода.

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

Как именно воплощать эти что и где в своих проектах, разбираем в СильныхИдеях.

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

"Современные тренды" в развитии языков программирования -- это постепенное сдувание пыли с вечных математических открытий.

Алгебраические типы данных появились 40 лет назад, лямбда-исчисление -- 80 лет назад, экзистенциальные квантификаторы -- 128 лет назад...

Радостная (ли?) новость для питонистов ^^^

При этом Python получает все ужасы shared-state concurrency с тредами на уровне ОС, в то время как весь остальной мир переходит на структурированный concurrency и/или управляемые эффекты.

Хорошо спроектированная система -- это баланс объектно-ориентированного, функционального и структурного программирования.
-- Uncle Bob Martin

И всё же фундамент, если вы хотите наслаждаться своим кодом -- это ФП.

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

Формат данных (например, реляционный) стоит далеко на втором месте по сравнению с семантикой. Вся семантика находится в коде, но вы не можете написать всё приложение в хранимой процедуре. Поэтому предоставление всем желающим доступа к прямым SQL-запросам -- это кошмар, который быстро поставит приложение в тупик. Именно поэтому все команды, когда-либо предоставлявшие своим разработчикам прямой доступ к SQL в первой версии продукта, в конечном итоге быстро его отменяли.
(с нереляционкой, впрочем, ситуация ещё хуже)

Даже в легендарном "Счастливом Фермере" (где моя свинья 9-го уровня??) пришлось спешно добавлять минимальный middleware, потому что с клиентов отправлялись прямые SQL-запросы к базе (точнее, к одной гигантской таблице со всем чем только можно), которые очевидным способом хакались. Впрочем, даже такая ужасающе спроектированная система (один гигантский анти-паттерн) очень хорошо зарабатывала, и в этом огромная беда ИТ: код может быть сколь угодно кривым, и всё же продукт может стать успешным. Ну, до поры до времени...

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

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

Отвязаться от такого одержимого навязчивой идеей бывает сложно, лучший рецепт: придумайте для него самого самый первый технический шаг, не требующий программирования: подготовить подробное ТЗ (к которому можно потом бесконечно придираться:), настроить стек (машину с линуксом, java-фреймворки), посоветуйте использовать ChatGPT в помощь.

В 98% случаев вы больше никогда об этом человеке (как минимум, об этой идее) не услышите. А в оставшихся 2%, если он действительно это нормально сделает, ну... можно и попробовать совместными усилиями.

Старый легаси-софт сам по себе не умрёт, вам надо его убить.

"Проще написать новый код, нежели пытаться понять старый".

Джон фон Нейман в письме к Морсу Марстону (знаменитый американский математик), 1952

Смешное, тут много подобного.