Программист должен уметь мыслить в терминах концептуальных иерархий, которые намного глубже, чем когда-либо приходилось сталкиваться одному уму.
-- Эдсгер Дейкстра

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

(только программисты могут лайкать этот пост)

Продолжение темы про интерфейсы.

...Если мы хотим сделать интерфейс в функциональном стиле (с поддержкой иммутабельных значений), то Java и подобные языки это не позволят. Например, метод pop() для стека, согласно допустимой сигнатуре интерфейса стека, может возвращать только результат выдачи из стека, а где новый иммутабельный стек после обновления? Где-то в коде также должен быть определён явный конструктор, который создаёт пустой стек, но его придётся привязывать к конкретной реализации. А если push() возвращает новый стек с добавленным элементом, из его сигнатуры невозможно вывести, что новый стек должен быть такой же реализации, как и исходный стек.

Поэтому реализация интерфейсов в Java может быть только императивной.

В продолжение про интерфейсы.

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

Тут ещё потребуется нечто , называемое F-ограниченным полиморфизмом ( F-bounded_quantification ), чтобы убедиться, что "входящие" и "выходящие" стеки имеют одинаковую реализацию.

Что-то вроде

interface Stack<T extends Stack<T>> ...

И всё равно это кривоватые приляпки (например, Curiously recurring template pattern, на котором была основана вся Microsoft C++ Active Template Library :), мешающие наглядно показать в коде, как программа может использовать стек, не зная, какая именно это реализация...

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

(Из свежего материала в СильныхИдеях "Модули важнее всего", где поясняется с помощью Роберта Харпера, как об этом всём правильнее думать и рассуждать)

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

Да, но, например, Twitter встраивает каждый твит на вашу страницу как iframe, загружая попутно более мегабайта (!) JavaScript, выполняет при этом 20+ HTTP-запросов и использует более 100 DOM-узлов. И в других ютубах инстаграммах ничуть не лучше (вот разве что тг неплохо спроектирован)...

Ну и чему вы "научитесь"?

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

В продолжение темы интерфейсов.

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

С одной стороны, компилятор автоматически выбирает нужную функцию в зависимости от того, как будет использоваться результат, а с другой, для каждого типа может быть только одна такая функция. Если вы хотите иметь два разных способа, например, сериализации некоторой сущности, то извините! Ну или пишите по-хипстерски Serialize1 и Serialize2 :)

Готовлю курс по SAT/SMT-солверам (в этом месяце будет бесплатно доступен регулярно у меня занимающимся), будем решать с помощью Z3 вот подобные задачки )))

По тропинке вдоль кустов
Шли 11 хвостов.
Сосчитать я также смог,
Что шагало 30 ног.
Это вместе шли куда-то
Петухи и поросята.
А теперь вопрос таков:
Сколько было петухов?
И узнать я был бы рад,
Сколько было поросят?

Обожаю AI -- настоящий душнила! )))
Отвечает ведь вполне логично, как программист, не придерёшься. Типа, разговор разработчика с менеджером-постановщиком.

Посмотрите этот, без преувеличения, выдающийся доклад "GoingNative 2013 C++ Seasoning".

Sean Parent начинает выступление со слайда с куском кода из некоторой версии Chromium OS. Это цикл со вложенными if (за что я строго ругаю даже начинающих :), который, судя по всему, выполняет перестановку панелей. Да, вот такой ужасный джуниорский код пишут в Гугле "знатоки алгоритмов", прошедшие, типа, через сложнейшие собеседования.

И всего несколько слайдов спустя Parent преобразует этот код в несколько строк вообще без циклов и условий: более читабельный, более эффективный, более простой и более общий. Это тот идеал, к которому мы стремимся.

Самый продуктивный подход в понимании цикла -- это когда он вообще не будет написан :)

(подробнее по этой теме в СильныхИдеях скоро будет материал по правильному пониманию циклов как частных версий более сильных абстракций).

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

Как получить экзистенциальные типы? В Haskell это может выглядеть как запихивание экземпляра тайп-класса внутрь обобщённого алгебраического типа (GADT) -- его конструктор может возвращать связанные значения не своего типа. Но всё равно даже в Haskell это не работает для бинарных функций: я не смогу гарантировать, что две структуры данных одного типа при пересечении в программе используют, например, одну и ту же [реализацию] библиотеку мемоизации (они ведь могут использовать разные глобальные состояния, хотя им нужно использовать одно и то же).

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

На этом тема интерфейсов закрыта, подробный материал в СильныхИдеях.

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

Почитайте "Повелитель мух" например ) Очень реалистично про коллективы без разумного управления.

Сотрудников надо поощрять и делегировать ответственность, но не упускать контроль; регулярно проверять и поправлять, но не заниматься микро-менеджментом. Это мастерство, да.

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

Писать хороший код легко. Самое трудное -- думать об этом.

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

Очень интересно что получится, ну для начала рекомендую порешать достаточно сложные задачки из трёх моих обновлённых курсов по АСД.

Я сторонник прагматичного подхода: сколько надо усилий вложить в такие довольно специфические конкурсы (есть даже мем "литкод это хорошо, а программировать-то умеешь?"), чтобы добраться до уровней, на которых вас там заметят; или же лучше это время вкладывать в прокачку технических скиллов, которые актуальны для хороших вакансий (где практически никогда не бывает прямых требований по знанию сложных АСД, хотя на интервью могут немного погонять, конечно).

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

Иногда спрашивают, о чём этот блог? Да особо ни о чём, просто пишу разные неформальные мелочи на интересные (прежде всего для меня:) темы.

По software desing разные обрывки кусочки, а цельный подход непосредственно в моей Школе: курсы + СильныеИдеи + Hard Work практика в SD.

Кроме того, забавная тема "AI как экзистенциальная угроза". Я -- белковый специалист по человеческому интеллекту, у которого IQ органически снижается из-за биологического распада и энтропии. А тем временем новая неорганическая раса рептилоидов появляется на Земле с экспоненциальной скоростью...

То странное чувство, когда узнал, что PostgreSql решил стать безсмертнымсерверным )))

Если у вас нет времени на написание хорошего кода, то у вас точно нет времени на написание плохого кода.

Хороший код экономит ваше время в будущем.

И чаще всего "в будущем" означает "через 20 минут".

Переключение на императивщину быстро напоминает мне, насколько же хороши функциональные языки. Явные побочные эффекты, ленивые вычисления, иммутабельность, классное окружение вроде поисковика hoogle, сервера HLS или typed holes из Agda...

Когда возвращаешься к C# или Java, то ощущения от их - "ёлки, вы правда с этим всем живёте?"...

Фортран и даже Кобол сегодня популярнее, чем Haskell :)

Когда я пишу код, мне проще сделать его более понятным, чем объяснять в комментариях, почему он непонятен.

Умники говорят: "Не волнуйтесь, AI не сделает ничего, пока мы ему не скажем".

Я нахожу это озадачивающим.

2 года назад: "GPT, что такое 1+1?"

Сейчас: "GPT, сделай целое приложение для Android, которое обычно занимает у программиста 2 полных дня".

Когда вы ставите перед AutoGPT цель (например, "заработать деньги"), он самостоятельно принимает множество решений, чтобы действительно (попытаться) заработать деньги.

Он сам решает, какие задачи ему выполнять дальше.

Он попутно решает множество задач, которые вы ему не поручали.

Почему мы всё ещё говорим о том, будет ли когда-нибудь у AI самостоятельность? Они уже ей обладают! Автономные агенты уже здесь: AutoGPT, BabyAGI, SuperAGI и т.д. вы можете найти в исходных текстах на github. Буквально любой сообразительный школьник может запустить их у себя и предоставить им любую свободу активничать в Сети (и так уже происходит).

Агенты GPT4 сейчас активно работают в Minecraft и начинают наводнять другие игры (например, Runescape).

Люди смотрят на AutoGPT, которому всего несколько месяцев, и говорят: "Он ещё не так хорош" или "Он ещё не захватил мир", как будто проблема в этом.

Вопрос не в том, будет ли AGI мультиагентным, а в том, насколько он уже агентен.

И наконец, очевидная тенденция: люди из вредности намеренно предоставляют AI всё больше и больше автономии.

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

(Курцвейл на днях заявил, что всё закончится уже в этом десятилетии...)

Осталось немного.

Слава роботам.

"Неважно, как и где ты окажешься, ты должен понимать математику"
-- Роберт Хайнлайн

Когда люди требуют доказательств "необычного" утверждения о том, что человечество погибнет, столкнувшись с неорганическими разумными системами, превосходящими нас по скорости мышления в 100-1000000 раз, напомню из биологии, что "естественным" итогом для вида считается не выживание, а вымирание Ж)

На Земле вымерло ~99,9% всех видов. Преимущественно с помощью людей, ну вот теперь человеки добрались и до самих себя.

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

Для будущего AI мы даже не обезьяны, мы -- растения.

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