Имел неосторожность сравнить переживания людей по поводу ЛЛМ с переживаниями программистов на ассемблере по поводу языка Си. Я-то имел в виду, что «молодежь не будет знать, как компьютеры работают» и «понапишут слопа, все тормозить будет». Но люди возбудились на другой аспект: мол, компиляторы-то детерменированые, а ЛЛМ нет. И тут уже я не понимаю. Этот детерминизм с нами в одной комнате? Понятно, что если ты будешь одну и ту же программу компилировать на одном и том же компьютере два раза подряд, ты получишь одно и то же (за исключением Джаваскрипта, но там у людей своя атмосфера). Но это неинтересный пример, потому что два раза одну и ту же программу компилировать обычно и не нужно. Что, с первого раза плохо получилось? Обычно ты программу меняешь — но тогда и результат компиляции меняется, и часто недетерминировано. Потом, есть разные компьютеры, на них разные версии ОС, компилятора, библиотек, окружения. Недетерминизм (а точнее непредсказуемость) вокруг этого, конечно, пытаются как-то поприжать, с переменным успехом, но сам этот факт говорит нам о том, что его там изначально не было. Сегодня я компилял одной версией Икскода, завтра она обновилась, и что получится (или не получится) не знает никто на этой планете, включая Тима Кука. Дальше можно посмотреть на всю систему целиком. Обычно программы возникают не из компилятора, их пишут люди. Вот ты даешь задачу Васе написать программу, и что, у тебя детерменированный результат? Нет конечно же. Иногда получится одно, иногда другое. Опять же, направление в целом, наверное, предсказать можно, но не с точностью до буквы. А если еще раз попросить, то получится что-то другое. И ничего, справляемся как-то. Короче, миф ваш этот детерминизм, и давным давно его нет никакого, задолго до ЛЛМов он испарился. Но! Это не мешало нам успешно делать программы и продукты. Вопрос вообще не в детерменизме, а в том, насколько предсказуемо можно направить вывод в нужное русло.

«Как я, учась в айти, работаю на 15-тонном советском станке и автоматизирую его без CAM-системы и комментариев» Парню 19. Днём он корпит над учёбой на айтишника, а в остальное время один на один с 15-тонным советским фрезерным ИР-500 1982 года выпуска. Мозги под стать эпохе, японская стойка Fanuc начала 90-х, память в килобайтах, а комментарии писать нельзя вообще, так что любой код превращается в месиво голых цифр на пузатом экране. Пока детали брались в пару проходов, жилось спокойно. А потом пошло глубокое торцевание, где программа пухнет в бесконечную портянку одинаковых строк, и достаточно забыть один минус перед координатой, чтобы фреза разнесла тиски за 150 тысяч. Стучать такой хардкод руками для айтишника — это ж почти преступление. Вот он и полез в стойку, которая старше его на 20 с лишним лет, и откопал там штуку, за которую заводы когда-то отдавали как за подержанную тачку.

Дмитрий Завалишин написал классный пост о преимуществах Java над другими языками программирования. Ниже — ключевая цитата.

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

Давайте сейчас забудем про AI, вернемся в первобытные времена до 2022 года. Всё же абсолютно правильно написано. Не поспорить ни с чем. Но мой личный опыт программиста — 100% Java проектов именно что неподдерживаемы, потому что нечитабельны. Ок, я Java не знаю, можно предположить, что поэтому и не читабельны. Но я и PHP с Python не знал никогда, а читал спокойно и поддерживал. Или, было время, я Си не знал (потом узнал), тоже всё нормально было. А с Java нет. Удивительное расхождение теории с практикой.

😐 Ультимативный разбор... Go 1.27? Честно, не знаю зачем я это сделал, но я сделал.. Ну почти. https://golang.guide/go-1-27/ Сначала я решил просто написать базовый обзор релиза. Но потом я увлёкся и не смог вовремя остановиться. Мне хотелось не просто сухо рассказать об изменениях, а добиться глубокого понимания читателя — причины этих изменений, какие проблемы они решают, как реализовано, почему именно сейчас, какая история стоит за самыми интересными фичами. При этом, я старался писать так, чтобы всё это читалось интересно и легко. В итоге, работа над статьёй так сильно затянулась, что когда она выйдет, сам релиз уже никому не будет интересен. Поэтому я решил опубликовать ту её часть, которая уже готова — это примерно 60%, и туда вошло всё самое интересное и важное: - Дженерик-методы, которые десять лет обещали не добавлять - Новый движок JSON v2 - Пакет uuid наконец-то в стандартной библиотеке - Детектор утечек горутин, который переиспользует сборщик мусора — на мой взгляд, самое красивое, что есть в этом релизе Во вторую половину войдут: постквантовые подписи, рантайм, net/http, SIMD и тулинг. Это я дописываю прямо сейчас, оно появится в той же статье. Все код-сниппеты запускаются прямо из статьи на актуальном go1.27. Каждый из них можно редактировать и экспериментировать — не нужно открывать отдельный плэйграунд. А ещё я подготовил для вас наглядный виджет с демонстрацией механики работы детектора утечки горутин. Я потратил на эту статью ОЧЕНЬ много времени. Возможно, стоило потратить на более фундаментальный гайд — тот же GC, над которым я также сейчас работаю. Но надеюсь, вам всё же понравится ❤️ Стоит ли писать подобные обзоры про новые релизы? ———— А ещё я прикрутил к сайту email-рассылку (и письмо про Go 1.27 туда ушло сильно раньше этого поста) и комментарии к статьям. Если вдруг заметите какие-то баги, пишите в комментариях, постараюсь оперативно поправить. И не хулиганьте в комментариях на сайте! 👍 #article #go1_27

Назад в машинный зал: как собрать эмулятор PDP-11/70 с телетайпом, блэкджеком и без Rust Программист «за пятьдесят» решил вернуть свой 1984-й и написал браузерный эмулятор PDP-11 — с дрожащим блоком питания, стрекочущим телетайпом и передней панелью, где тумблерами вручную нащёлкивается загрузчик. За время игр с настоящими операционками той эпохи всплыла деталь, от которой привычные вещи выглядят иначе. Оказывается, концепция пайпа родилась буквально из перфоленты. Керниган и Пайк сначала просто пробивали выдачу одной программы на ленте и заправляли её на вход другой. Только потом это переехало в программный буфер. Тот самый вертикальный слэш, который мы ставим в консоли каждый день, начинался как физическая операция с бумажной лентой в восемь дорожек. Посмотрим, что ещё вскрывается, когда трогаешь Unix V5 руками.

Vercel выпустила курс по построению рабочего каркаса ИИ-агента для кодинга Build Your Own AI Coding Agent Harness. Я решил скормить этот курс клоду, и попросить сравнить с тем, что у меня уже реализовано в Lovarus. Был приятно удивлен, что бОльшая часть была закрыта, и где-то даже выше уровня курса. Например, я много внимания уделял детерминированным проверкам кода. Но вот одну вещь я упустил, и она сломала кеширование. Я каждый раз пересобирал системный промпт агента, с учетом некоторых обновлений в структуре приложения. Также подчерпнул из курса классную вещь - санитайзер результатов устаревших вызовов инструментов. Например, агент в самом начале работы прочитал большой файл, потом переписал его, и по сути он больше не нужен в истории, а он там лежит. Буду исправлять.

Системная память в AI-харнессе — это плохо Мне кажется, что память в клоде — это зло. Конечно большой кайф в том, что агент под тебя подстраивается — запоминает привычные имена переменных, просьбы писать меньше буллшита в комментах и способы называть миграции. Но проблема в том, что все эти инструкции остаются внутри ~/.claude. То есть у другого программиста в том же репозитории и переменные будут названы по-другому, и буллшит будет другой формы. Со временем твой агент посмотрит на чужие примеры, и начнёт писать так же. Потом, наверное, и память незаметно подменит, если долго его не ругать. Кароч, считаю что любые инструкции для агента должны быть воспроизводимыми — лежать прямо в репозитории, для которого они предназначены. А глобальный CLAUDE.md должен быть вообще пустым.