Hacker News Digest

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Автор рассказывает о своем пути к любви к Erlang, начавшегося с непонимания базовых концепций программирования в восемь лет, когда столкнулся с выражением "X = X + 1" в BASIC, показавшимся ему математической ложью. В университете он столкнулся с такими же трудностями при изучении C, но продолжил учиться через практику и эксперименты. Переломный момент наступил, когда партнер по бриджу спросил, как суммировать числа от 1 до 10 без циклов, что привело его к открытию рекурсии в Prolog — математически чистого подхода, где описывалось "что" является, а не "как" вычислять.

Знакомство с Erlang произошло случайно на турнире по бриджу от шведского игрока, который описал его как функциональный язык для распределенных, отказоустойчивых систем. Автор был поражен возможностью простого обмена сообщениями между разными узлами без сложных протоколов, демонстрируя пример ping-pong на Erlang. Этот язык, сочетающий функциональность, распределенность и отказоустойчивость, стал тем, что он искал с детства — способом программирования, где математика говорит правду.

• @az09mugen отмечает полезность функции > cd .. в конце статьи за простоту и мобильную доступность.
• @az09mugen предполагает наличие пасхалки (easter egg) в этой функции.
• @Gleamball выражает благодарность за выступление и обмен информацией.

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

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

• Обсуждение вращается вокруг идеи "functional core, imperative shell" (FCIS) и противоположного ей подхода "generic core, specific shell", а также влияния этих подходов на тестируемость, производительность и читаемость кода.
• Участники обсуждают, что FCIS делает код более тестируемым, но может привести к проблемам с производительностью при работе с большими объемами данных, особенно если язык не поддерживает ленивые коллекции.
• Также обсуждается, что важно разделять логику и эффекты, но пример кода в статье вызывает вопросы, потому что он не демонстрирует лучшие практики, такие как пагинация или фильтрация на уровне базы данных.
• Некоторые участники подчеркивают, что важно не только следовать паттерну, но и использовать здравый смысл, чтобы не плодить сущности, которые не масштабируются, и не создавать ситуаций, где пример кода в статье может быть использован как оправдание для плохого кода.

Кандидат на собеседовании решает задачу FizzBuzz с помощью комбинаторной логики и лямбда-исчисления в JavaScript, используя лишь базовые комбинаторы S, K и I. Интервьюер всё больше недоумевает, наблюдая, как соискатель последовательно реализует сложнейшие математические операции и структуры данных через композицию этих комбинаторов, включая числа Чёрча, арифметические операции и даже Y-комбинатор для рекурсии.

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

• Обсуждение началось с критики формата технического собеседования, где кандидат вместо решения задачи пишет «рассказ о лямбда-исчислении» и тем самым «проходит» тест.
• Дискуссия быстро перешла к тому, что автор статьи, возможно, сам не до конца понял, что именно он хотел показать читателям, и что именно они должны вынести из этого урока.
• Участники треда начали спорить о том, насколько полезно знание комбинаторной логики в повседневной работе программиста, и стоит ли вообще изучать её.
• Некоторые комментаторы отметили, что статья не дала никакого практического обоснования, почему стоит изучать эту тему.
• В итоге, обсуждение сошлось на то, что если кто-то и найдёт в этом какой-то практический смысл, то это будет уже его заслуга, а не автора статьи.

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

Язык предоставляет модули для ввода-вывода данных, примеры кода и справочник, облегчая освоение и применение. Knotty демонстрирует, как нишевые DSL могут решать специализированные задачи, сочетая программирование с ремеслом.

• Обсуждение исторических связей между программируемыми ткацкими станками (Жаккардовы машины) и современными компьютерами.
• Восхищение проектом как примером элегантного и практичного инженерного решения, продолжающего исторические традиции.
• Размышления о параллелях между вязанием и функциональным программированием, где физические ограничения сравниваются с системой типов.
• Интерес к современным DIY-станкам для вязания и возможностям автоматизации создания узоров с помощью ИИ.
• Шуточные комментарии об ожиданиях увидеть что-то другое (например, терминальный эмулятор) и отсылки к поп-культуре.