...В течение десятилетий мы боролись с использованием объектно-ориентированных языков, таких как Java или C++, чтоб объяснить эти простые идеи, и все время терпели неудачу. И я могу сказать тем из вас кто не вовлечен в сферу академического образования в данный момент, многие из моих коллег по всему миру находятся в той же ситуации, и отчаялись найти выход из нее. Уродливая методология, "шаблоны проектирования", "руководства по стилю", все они мешают преподавать принципы программирования. И даже если это отодвинуть в сторону, вы по-прежнему придерживаетесь императивного программирования на эфемерных структурах данных. Это просто не работает, поскольку это фундаментально неправильная вещь. Просто попробуйте преподать, скажем, удаление в двоичном дереве поиска; это ужасающая путаница! Вы закончите абсурдной ерундой "null-указателей", и сложной путаницей вызванной методологией, а не самой задачей. Очень скоро вам придется прибегнуть к "шаблонам" просто чтобы дать студентам шанс довести до конца что-нибудь вообще, отдаляя их от существа идей и создавая впечатление, что программирование болезненно и уродливо, что является огромной трагедией.

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

...Следуя словам моих коллег из MIT, студенты абсолютно влюбляются в программирование и в красоту кода, при условии что код который вы просите их написать, красив на самом деле. Нет ничего более мрачного, чем корпоративная бюрократия ООП, и мало вещей более привлекательных, чем математическая элегантность ФП.

-- Роберт Харпер

Выложил в СильныеИдеи два больших материала, где разбираем его подходы, хотя бы на уровне базового понимания.

Ну и в целом вся моя Школа построена по схемам Харпера и других святых computer science из лучших университетов мира -- обучаю фундаментальным принципам программирования.

Девушки учатся "программированию"

(и вообще у автора неплохие ролики про карьеру программиста)

Может ли AI работать в паре по XP + TDD вместо белковых ?

Рекомендовано Кентом Беком => can-ai-play-the-tdd-pairing-game

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

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

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

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

...Если мы хотим сделать интерфейс в функциональном стиле (с поддержкой иммутабельных значений), то 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 :)

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