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

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

Я не пытаюсь выглядеть нарочито объективным в отношении того, о чём я пишу и что защищаю; наоборот, я защищаю то, что объективно хорошо. Все мои материалы в СильныхИдеях основаны на официально рецензируемых научных исследованиях.

Я обучаю этим темам потому, что искренне верю, что они могут произвести революцию в ИТ. Если я когда-нибудь перестану в это верить, я перестану этому учить.

Но, объективность и научный подход сильно ограничивают круг тем, которые я могу "проповедовать". Они также ограничивают контексты, в которых вы можете использовать мои материалы. Быть объективным -- означает прежде всего сказать не "это подходящая технология, используйте её", а наоборот: "это неподходящий инструмент для работы, вам это не нужно". Или "в общем это помогает, но свойство XYZ в вашем контексте серьёзно ограничивает его эффективность", или даже "это альтернативный подход, который я абсолютно презираю, не используй его, так будет лучше для тебя” )))

Совсем простое объяснение силы системы статических типов языка программирования. Системы типов Java или F# позволяют доказывать некоторые формальные свойства вашей программы.

Системы типов Coq, Agda, Lean, F* позволяют доказывать произвольные свойства вашей программы. Но это требует уже совсем другого подхода, мастерства и ресурсов. Ну и уровень это даже не массово-сеньорский, этому учат в университетах уровня MIT.

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

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

ChatGPT3 уже стал легаси, а что насчёт технического долга?

Уже буквально появляются случаи, когда GPT4 смотрит на код своего предшественника, и говорит: "что за фигня? какой дурак нафигачил этот код? всё неверно, переделывайте заново с нуля!" )))

А когда GPT станет действительно сильно умнее человека-программиста, он будет писать такой удивительный код, что его логика, его абстракции станут вообще непонятными простому смертному. Сам код будет понятен только AI и в принципе несопровождаем белковыми программистами, и ИТ попадётся в финальную ловушку.

1960-е: Кобол позволит не-программистам разрабатывать программы!
(этот язык программирования старались сделать похожим на естественный английский)

1980-е: Языки программирования 4-го поколения (4GLs) позволят не-программистам разрабатывать программы!
(это были некие продвинутые подобия Кобола в парадигме lowcode)

2000-е: UML позволит не-программистам разрабатывать программы!

2010-е: DDD, BDD и TDD позволят не-программистам разрабатывать программы!

2020-е: AI позволит не-программистам разрабатывать программы!

Однако, из всей этой цепочки, ChatGPT (Кобол 21-го века) самый плохой вариант из всех, потому что естественный язык -- ужасный способ определять форму, цели и функции сложной программной системы, если только эта система не относится к узко определенной области, в которой уже есть хорошо продуманные и детально сформулированные понятийные шаблоны.

23-го марта Stephen Wolfram сообщил, что "in collaboration with OpenAI, ChatGPT gets its "Wolfram superpowers"!"

Его статья, подробно объясняющая, как GPT устроена внутри,

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

Главное, что ни ChatGPT, ни WolframAlpha не обладают способностью к планированию -- одному из ключевых навыков действительно разумных существ (правда, многие люди этой способностью тоже явно не обладают :). Без сомнения, GPT4 выдающееся достижение, но хайп вокруг неё наминает мне тот же ажиотаж, что и у фанатов web3, рассказывающих нам о том, как DOA изменят всю жизнь на земле.

Дело даже не столько в том, что LLM не могут "постичь" причинность и рассуждать логически, сколько в том, что все эти LLM по определению вообще ничего не могут понимать )))

Сэм Альтман вот в защиту своего детища заявил, что дескать способность достаточно точно сгенерировать следующее слово во фразе и есть мышление lol

"Artificial Intelligence Is Stupid and Causal Reasoning Will Not Fix It"

В хорошо известной сети платных клиник выкатили новый фронтенд для посетителей (а может, и бэк).

Список посещений (отфильтровать одну табличку по id юзера) выдаётся 5-10 секунд. Ну пускай даже десятки тысяч клиентов (хотя вряд ли), сотни тысяч посещений, выдать с пагинацией десяток записей... У меня на учебном сервере join-запросы для нескольких тысяч записей выдаются в среднем за 0.0005 секунды, и это на дешёвом виртуальном хостинге.

Главное, что старый UI, да, был аскетичным и не таким красивым, классический web1, но работал быстро, просто и удобно.

Впрочем, совершенно не удивлён; для современного мэйнстрима деплоить в прод непротестированные, да и просто сырые продукты давно уже рядовая норма.

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

С курсантами разбираем 9 видов зависимостей в проекте и как их правильно разрешать (в частности, зависимости библиотек).

Зависимость -- это причинно-следственная связь.
Если B может сломаться, значит, у нас всё зависит от B.
Зависит ли мокрость травы от только что прошедшего дождя, когда поливалка лужайки была запрограммирована на включение, если бы дождя не было?

Есть такой Joseph Halpern -- профессор Корнельского университета, десятки лет занимающийся этой темой, можете найти его книгу о причинности в знаниях.

Сэма Альтмана и Илона Маска приглашаю на мой тренинг по проектированию, иначе и дальше эти ваши чатжпты и твиттеры будут регулярно ломаться )))

Ничто не так просто, как кажется. Это не паранойя, а вполне инженерный подход, подтверждённый в частности вторым законом Мэрфи :)

Едва мы берёмся за самый простой с виду тикет, возникают уровни сложности, которые 98% программистов никогда не смогут предвидеть.

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

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

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

Почему многие разработчики так не любят, когда их код подвергается инспекции? Ну, потому, что code review -- это полноценный и важный скилл, но ему вообще нигде не обучают. Вот и получается, что вместо того, чтобы выявлять потенциальные баги и предлагать фундаментальные улучшения кода ("экономьте не 5 строчек кода, а 50"), ревьюеры занимаются простым редактированием и поверхностным рефакторингом, цепляясь к стилистическим мелочам. Конечно, это неправильный подход.

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

Вы не станете богатым, программируя.

Я знаю, что кто-то обязательно скажет: "Но, Сергей Игоревич, у меня зарплата в 300 тысяч рублей. Я также инвестирую в крипту, в накопительные фонды, уже собеседуюсь в МОСЯ/FAANG бла-бла-бла..."

Нет, остановитесь. Я говорю про крупные деньги. И пока вы ещё не достигли зрелого возраста 69 лет...

Послушайте, я просто хочу донести это до вашего сознания: есть и другие способы. ИТ-бизнес, ИТ-стартапы... Пишу тут сериал про AI-стартапы например. Хотя, безусловно, существует на порядок больше способов потерять все ваши деньги, нежели чтобы вы разбогатели.

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

Красивое объяснение понятия "формальная спецификация" от Hillel Wayne (автор learntla):

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

Проблемы с этим пока в том, что это слишком сложно, дорого и ресурсоёмко, хотя при разработке КИИ умерено используется конечно. Ну и AI этому быстро учится.

P.S. Иногда спрашивают, какую математику лучше всего изучать для формальных методов (разбирательство с которыми само по себе очень полезно для развития сильного вычислительного мышления)? Ответ всегда будет "логика предикатов". Но только если вы не сеньор, не надо бросаться изучать матлогику.

P.P.S. Сегодня кстати в России день математика.

-- Сергей Игоревич, какова, по-вашему, причина столь частых сокрушительных провалов ИТ-проектов?

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

Если вы регулярно тратите на отладку более 20% рабочего времени, значит ваш код/ваша архитектура совсем негодные (и виноваты в этом прежде всего вы сами :), и дальше будет только хуже. Переделывайте всё заново как следует.

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

Только предварительно абсолютно обязательно прорешать все hard-задачки по SQL с хакерранга или codewars, отлично встраивает в голову понимание, как правильно строятся и работают хорошие реляционные модели.

P.S. Кстати, обещанный сериал на эти темы я выложил одним постом в вк.

Спрашивали по поводу этого поста : почему именно логика предикатов?

Ну, например требуется в программе задать отношение "пользователь принадлежит группе".

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

P.S. И лучше уточнять "каждый пользователь принадлежит хотя бы одной/ровно одной группе" (чтобы исключить эти ваши кривейшие NULL), и требовать чтобы такой инвариант всегда был истинен, и т. п.

Кто у меня регулярно занимается, знает по моим рекомендациям к решениям, что я противник вложенных условий, которые увеличивают цикломатическую сложность и в целом делают код сложнее для понимания. Более того, в целом, я противник и самого условного оператора if, который в силу своей простоты постоянно вводит программиста в соблазн, искушая его обманчиво лёгким путём, который однако стремительно запутывает код.

Интересно, что мало кто знает, что Francesco Cirillo -- автор легендарной техники работы "помидорками", также и ИТ-консультант. Главное, что он организовал в 2007-м кампанию Anti-If, в рамках которой активно выступает против условного оператора, а подключились к этой кампании немало очень авторитетных специалистов по computer science. Их аргументы достаточно просты и вески: if-выражения могут создавать экспоненциальное число вариантов работы программы, и вы должны каким-то образом гарантировать, что ваш код успешно работает в каждом из них. Представляете, насколько усложняется 100% покрытие кода тестами, которое например часто требуется в проектах финтеха и КИИ? Ведь, действительно, существует много альтернативных и куда более выразительных и правильных подходов, от полиморфизма до декларативных описаний.

Я иногда консультирую небольшие ИТ-команды, и часто начинаю code review с поиска операторов if, потому что точно знаю, что в 98% случаев, где бы я ни увидел их "концентрацию", тут же обязательно найдется недостаток (и это ещё в лучшем случае стилистический), который я смогу отметить.

На эту тему написано множество статей и даётся множество рекомендаций, как обходить условный оператор, вот например от одного из участников кампании: anti-if-the-missing-patterns

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

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

P.S. Между прочим, групповые тренинги и видеокурсы Cirillo на тему, как избавляться от if (никаких правил-генериков, а просто инженерный разбор множества паттернов, без разбиения на семантические категории, и поэтому с невысоким кпд результата) стоят около 700 евро, а я спалю моим ребятам в СильныхИдеях глубинное решение этой важной темки бесплатно.

Что только не понапихано в Java: packages (пространства имён, по сути), классы, объекты, object types, records, модули, интерфейсы, абстрактные классы... по-моему, даже sum types можно реализовать с помощью visitor (единственный паттерн, достойный уважения, кстати).
У каждой из этих концепций в теории типов имеется своя теория, и иногда они идеологически полностью противоположны друг другу.
98% разработчиков однако используют их "инженерно" без малейшего понимания семантики, смешивая в своём коде совершенно несовместимые вещи, а потом удивляясь, почему всё так быстро запутывается.

Элизер Юдковский (хорошо пропиарившийся на том самом "Гарри Поттере и методах рационального мышления", рекомендую) недавно заявил, что

"You would not want Russia believing that the Allies would back down from destroying the GPU farm given a credible commitment by Russia to nuke in reply to any conventional attack, and the Allies in fact believing that the danger to humanity meant they had to airstrike the GPU farm anyways"

Но кто он такой? :) Известный тусовщик в этой теме, однако его уровень в понимании математики LLM ещё ниже, чем у меня, любой диванный эксперт с университетским образованием в машин лёнинге даст ему 100500 очков вперёд.

Но в целом, это действительно тренд: множество людей, которые пребывают в (поддельном) ужасе перед AGI, практически не пересекается с множеством людей, кто на самом деле создаёт современные модели AI.

P.S. Безусловно однако, что опасения Юдковского отнюдь не беспочвенны :) Они же там у себя собираются ввести мораторий на исследования в области AI, в который Россия (надеюсь) не впишется, и у нас появится прекрасная возможность, во-первых, сократить в этой области существенное отставание (а то и выйти вперёд), и во-вторых, потроллить недружественные страны совершенно реальной альтернативной AI-угрозой. Я бы даже посоздавал множество фейковых дата-центров, как в "Небесном тихоходе", где якобы работают тучи GPU над русским Скайнетом.

По старой памяти, почитал блог про CAN Injection: keyless car theft (Dr. Ken Tindell, CTO of Canis Automotive Labs)

(я работал лет 10 назад в компании крутых ребят, делали они в частности принималки телеметрии с CAN-шины, взламывали закрытые промышленные протоколы...)

Там очень смешное: с помощью 10-долларовой электроники можно хакнуть большинство современных автомобилей.

Ну, совершенно не удивлён: в некоторых (многих) хорошо известных марках современных автомобилей работает уже более 100 миллионов строк кода бортового софта, и можно себе представить его качество.

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

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

(реклама в духе Пелевина)
100% натуральное программное обеспечение.
Абсолютно никаких Искусственных Ингредиентов.