"Москва первой в мире снизила интервал движения поездов метро до 80 секунд...
В начале года на Кольцевой линии установили новую микропроцессорную централизацию... Недавно провели испытания системы на отечественном ПО в режиме максимальной нагрузки, и удалось добиться самого короткого в мире интервала движения между поездами -- порядка 80 секунд... С помощью новой автоматики движения на Кольцевой линии столичного метрополитена поезда сменяли друг друга на станциях быстрее, чем в метро Парижа, Токио, Гонконга и Пекина..."

40 лет назад моим дипломным проектом в институте была программа на PL/I (а в тексте ее логика подробно разбиралась на псевдокоде в духе Алгола 68 (кстати, очень хороший и по сегодняшним меркам язык, допускавший например моделирование символьных вычислений на фазе компиляции), которая рассчитывала оптимальное расположение светофоров на перегоне метро с целью минимизации интервалов между поездами. Сам алгоритм выдавал математически оптимальный вариант. Придумал его не я конечно, а умники с кафедры. Но программировать тогда вообще никто не умел, и эта программа для кафедры была реально ценной.

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

Машинное время тогда было очень дорогое, 1 час счета в неделю на ЕС ЭВМ считалось счастьем, поэтому быстро привыкаешь делать очень качественную инспекцию кода :) А мне жутко хотелось программировать, и когда появилась возможность покодить на одном из первых 8-разрядных микропроцессоров, я быстренько переписал логику на его ассемблере...

Ну и вот, в 2023-м автоматизация критически важной транспортной инфраструктуры Москвы достигла наконец уровня 1983-го года. Хотя совсем не факт, что светофорчики на перегонах и сегодня расставляются автоматически; вполне возможно, что по прежнему вручную на глазок.

Я иногда упоминаю гомотопическую теорию типов Воеводского как абсолютный топчик в computer science. Однако 100% сильно недооценивают уровень, требуемый для её понимания. Бедолаги начинают читать научпоп вроде "Нового Розеттского камня" Баеза...

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

Самый первый, входной пропуск на пути к HoTT -- Shape Modality (и это ещё задолго до теорката). Если не понимаете вообще что там пишут, забудьте и про хотт и про теоркат, это просто не ваше. Просто спокойно пишите обычный код, изучайте мои СильныеИдеи по Higher Work, и будет вам счастье.

В феврале сего года в правительстве России было объявлено о создании национального проекта по беспилотным системам. О стратегической важности этого направления я много лет писал еще с середины 1990-х в бумажном еженедельнике PC Week/RE, а читали его даже в Госдуме.

Вот например (2004-й год):

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

Всего-то 20 лет потребовалось ЛПР наверху, чтобы осознать важность очевидного.

=

Сегодня ситуация аналогичная стратегически уже с AI двойного назначения.

Оттуда же (2004-й год):

Элементы искусственного интеллекта сегодня пытаются придать даже минам. Последнее для российских специалистов на выставке Eurosatory-2004 в Париже стало настоящим откровением. Беда наших заказчиков не только в постоянной нехватке финансов, но и в полном отсутствии долговременных идей...

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

Яндекс Мэйл Сбер, где русская GPT? Китайцы на днях свою версию выкатывают, и GPT4 уже вышла.

Не можете сами сделать, хакните OpenAI (инструкция, как это сделать за 600 долларов) и локально дообучите русскому языку.

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

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

- всяческие пауки для парсинга сайтов - AI нагенерит их код под конкретный сайт легко и просто, а заказов в этой теме обычно много;

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

- умные чатботы под конкретные наборы товаров/услуг + рекомендательные системы. Интегрируются хорошо с пауками, которые парсят сайты, вытаскивая и токенизируя из них нужные сведения автоматически. Я кстати в тг уже рекламу таких ботов встречаю, пока другие спят; значит доходное дело;

- обработка естественных языков в разных доменах (инженерные, медицинские, ...), можно формальные грамматики задавать;

- автоматическая генерация кода и документации под конкретную кодовую базу с "пониманием" истории проекта;

- автоматическое тестирование API;

- автоматическая генерация тестовых скриптов для системы тестирования UI;

- автоматическая генерация кода специфической визуализации сложноструктурированных данных, OLAP....

P.S. Не могу не упомянуть модный стартап Adept

Adept aims to build AI that can automate any software process...

We’re training a neural network to use every software tool in the world, building on the vast amount of existing capabilities that people have already created...

Собралась пара десятков AI-спецов, сбежавших из FAANG, замутили свою нейронку, и вот уже набрали 350 млн. долл. инвестиций.

Всё, расходимся.

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

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

Структуры данных, определяемые на языках вроде IDL и его расширения OpenAPI, или в конфигурационных файлах -- это формат сериализации.
Но формат сериализации не имеет никакого отношения к модели данных проекта.
Такие языки создавались для других целей (понижение связанности, в частности), а главное, что когда вы используете сериализационные форматы для представления своих данных, вы наносите своему проекту два тяжёлых удара, от которых он вряд ли оправится :) и которые разберём с курсантами на формате higher work (бывший hard work).

Кстати, я давно уже выкладывал в СильныхИдеях мощный материал на эту тему "Смысл и моделирование данных в проекте", сейчас ещё пару занятий в higher work по нему добавлю.

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

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

Из переписки с курсантами, с курса карьеры, буквально на неделе. Обратите внимание, что зарплаты фактически идентичные. Совпадение? Не думаю :)

Кажется, план не пригодится, я 3-4 статьи успел прочесть. Мне сегодня сделали оффер с релокацией в Париж на 65 тыс. евро в год, завтра я с ним соглашусь...

Рынок стагнировал, предлагают не более 350к на сеньорские позиции. МЯСО совсем оборзели, уже требует четыре интервью, при том, что рынок опустел и остались совсем зелёные юнцы. Меня пока ценят на текущем проекте, сейчас веду переговоры об увеличении зп...

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

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

Я хочу зарабатывать деньги, чтобы поддерживать и развивать мою аутентичную схему преподавания, а не наоборот.

Когда я начал обучать/повышать квалификацию профессиональных разработчиков, то обнаружил, что я один из совсем немногих людей не то что в России, но и в мире, кто проводит продвинутые тренинги (сейчас это формат Higher Work) по программной инженерии и проектированию, не связанные с техническими темами, на хорошей математической базе.

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

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

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

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

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

Но, объективность и научный подход сильно ограничивают круг тем, которые я могу "проповедовать". Они также ограничивают контексты, в которых вы можете использовать мои материалы. Быть объективным -- означает прежде всего сказать не "это подходящая технология, используйте её", а наоборот: "это неподходящий инструмент для работы, вам это не нужно". Или "в общем это помогает, но свойство 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. Сегодня кстати в России день математика.

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

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