Hacker News Digest

Проектирование языка программирования — это итеративный процесс, включающий четыре фазы, которые необходимо повторять многократно. При реализации компилятора часто обнаруживается, что некоторые части языка спроектированы некорректно, что требует возврата к предыдущим этапам. Успех в создании языка зависит от глубоких знаний в трех ключевых областях: программных парадигмах (императивной, декларативной, объектно-ориентированной и др.), концепциях языков (последовательность выполнения, типизация, параллелизм и др.) и знакомстве с существующими языками. Автор рекомендует изучить десятки языков — от Python и Smalltalk до Haskell и Rust, а также ознакомиться с классическими работами по проектированию языков.

• Предложение включить Raku в список языков из-за встроенных грамматик для парсинга и объектно-ориентированной природы.
• Вопросы о компиляции целевых языков, их пайплайне сборки и контексте выполнения.
• Размышления о создании нового языка: необходимость, наличие ресурсов/команды, сроки выпуска MVP.
• Критика исходного материала как "AI slop", рекомендация использовать "programming language checklist".
• Споры об AI-происхождении текста (находки 2017 года) и упоминание забавного элемента (SnekQL).

Фраза "предпочитай композицию наследованию" стала клише, но её происхождение точно известно — это второй принцип объектно-ориентированного дизайна из книги "Design Patterns" "банды четырёх" (Gamma, Helm, Johnson, Vlissides). Оригинальная формулировка гласила: "Favor object composition over class inheritance". Авторы противопоставляли наследование ("белая коробка", где подкласс видит детали реализации) и композицию ("чёрная коробка", где объект взаимодействует только через интерфейс). Однако этот аргумент зависит от языка: в Java можно ограничить видимость для подклассов, а в Smalltalk и Python доступ к внутренностям возможен через рефлексию.

Более весомый аргумент касается гибкости: наследование статично и определяется на этапе компиляции, что затрудняет изменение, тогда как композиция динамична и позволяет заменять компоненты во время выполнения. Это меняет архитектурные зависимости — система опирается на отношения объектов в рантайме, а не на иерархию наследования. В контексте современного тренда к статической типизации и проверке компилятором, этот подход требует баланса. Интересно, что Barbara Liskov ещё в 1987 предлагала альтернативу: вместо жёсткой иерархии позволять полиморфным модулям использовать любые типы с нужными операциями, без формального отношения подтипа.

• Inheritance can lead to complex, fragile hierarchies and "co-recursion" issues where subclass methods override parent methods in unpredictable ways.
• Composition is generally preferred for flexibility and maintainability, as it avoids tight coupling and allows "black box" reuse without exposing implementation details.
• Both approaches have valid use cases: inheritance suits "is-a" relationships with clear invariants, while composition excels at combining independent behaviors ("has-a").
• Modern best practices favor interfaces + composition to decouple polymorphism from behavior sharing, reducing brittleness compared to deep inheritance chains.
• Over-reliance on inheritance often stems from cargo-culting; it should be reserved for cases where it genuinely simplifies the design rather than complicating it.

Smalltalk оказал значительное влияние на Ruby, хотя его синтаксис практически не перешёл в Ruby. Основное влияние проявилось в объектно-ориентированных принципах, особенно в идее, что все данные являются частью объектной системы. В отличие от Perl, автор статьи работал с Smalltalk несколько лет и считает его одним из любимых языков, хотя вряд ли будет использовать его снова.

Smalltalk возник в Xerox PARC, той же команде, что создала графический интерфейс, Ethernet и лазерный принтер. В 80-90-х годах Smalltalk был коммерческим продуктом (ObjectWorks/VisualWorks), широко использовался в авиационной промышленности и для проектов, лёгших в основу экстремального программирования. В 1995 году бывшие сотрудники Xerox PARC в Apple выпустили Squeak — открытую реализацию Smalltalk, написанную в основном на самом себе, что обеспечило её лёгкую переносимость. В отличие от большинства современных языков, Smalltalk развивался независимо от Unix/C, представляя собой собственную операционную систему с уникальным синтаксисом и интегрированной средой разработки.

• Smalltalk-80 и его наследие: образ системы (image) как способ распространения состояния, но его нет в современных системах, что делает Smalltalk-80 уникальным.
• Проблема в том, что Smalltalk-80 не имеет синтаксиса, который бы соответствовал современным ожиданиям, и это делает его непривлекательным для новых разработчиков.
• Ruby унаследовал объектную модель Smalltalk, но не его среду разработки, что делает Smalltalk-80 уникальным в своем роде.
• Сообщество Smalltalk активно разрабатывает Pharo и другие современные реализации, но они не могут конкурировать с уже устоявшимися языками, потому что не имеют большой экосистемы.
• Проект, который начинал как Smalltalk-80, теперь может быть выжившимся только как встроенный язык в некоторых проприетарных системах.

Статья представляет собой воображаемый список курсов компьютерных наук, которых не существует, но должны. Автор предлагает такие курсы, как "Отказ от объектно-ориентированного программирования", где студенты изучат переменные вне иерархии объектов и "функции", а также "Классические исследования программного обеспечения", посвященные исторически значимым продуктам вроде VisiCalc и Zork. Особый интерес представляет курс "Написание быстрого кода на медленных языках", где учат писать на Python, который по производительности может превзойти C++, и "Пользовательский опыт командной строки", анализирующий принципы UX для консольных программ.

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

• Обсуждение показало, что академическая программа CS часто не охватывает такие темы, как история ПО, философия вычислений, практика командной работы и даже базовые навыки работы в консоли.
• Участники подчеркнули, что курсы вроде "Unlearning OOP" и "Classical Software Studies" должны быть обязательной частью образования, но их нет.
• Обсуждение подняло вопрос о том, что не хватает курсов по фундаментальным навыкам, таким как CI/CD, системное администрирование и работа с консолью.
• Было отмечено, что студенты часто не получают практических навыков, необходимых для работы в отрасли, и что курсы по таким темам как "как писать быстрый код на медленных языках" или "как не страдать от внутренних конфликтов в команде" отсутствуют.
• В конце концов, обсуждение подтолкнуло к тому, что вместо того, чтобы учить студентов тому, как создавать и поддерживать сложные системы, которые уже работают, они вместо этого вынуждены изучать фреймворки, которые могут исчезнуть через 5 лет.