Hacker News Digest

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, теперь может быть выжившимся только как встроенный язык в некоторых проприетарных системах.

Wren — это маленький, быстрый, объектно-ориентированный скриптовый язык с поддержкой concurrency. Его реализация занимает менее 4000 строк кода, что позволяет изучить весь код за один день. Язык сочетает в себе идеи Smalltalk, Lua и Erlang, предлагая современный и понятный синтаксис. Wren использует быстрые однопроходный компилятор в байт-код и компактное представление объектов, что позволяет ему конкурировать с другими динамическими языками.

Особенностью Wren является акцент на классах как основной парадигме и встроенная поддержка легковесных волокон (fibers) для организации программы в набор взаимодействующих корутин. Язык создан для встраивания в приложения — он не имеет зависимостей, имеет небольшую стандартную библиотеку и простой C API. Wren компилируется как C99, C++98 или более новые версии, доступен для запуска в браузере и открыт на GitHub под руководством Боба Нистрома.

• Wren — язык, который сочетает в себе лаконичность Lua и объектно-ориентированный синтаксис, но при этом остаётся компактным и легко встраиваемым.
• Пользователи отмечают, что Wren легко встраивается в C/C++ проекты, но при этом не требует сложных зависимостей, что делает его привлекательным для встраиваемых скриптовых языков.
• Некоторые участники обсуждения упоминают, что Wren может быть использован как альтернатива Lua, особенно в контексте встраивания в игровые движки и другие приложения.
• Обсуждается также, что Wren имеет активное и дружелюбное сообщество, что способствует его развитию и поддержке.

Исследователь из Карлова университета предлагает отождествить Unix-исполняемые файлы с методами Smalltalk, открывая путь к объединению этих систем. Хотя Unix и Smalltalk существенно различаются в деталях, они демонстрируют поразительные сходства в своей общей структуре. Автор утверждает, что если файлы Unix соответствуют объектам Smalltalk, то исполняемые файлы должны соответствовать методам, а процессы — активациям этих методов. Это позволяет легко реализовать Smalltalk VM через файловую систему Unix.

Однако серьезные накладные расходы, связанные с Unix-процессами, ставят под сомнение практическую реализацию этого подхода. Тем не менее, автор видит несколько путей решения этой проблемы, которые позволят реализовать преимущества Smalltalk в Unix без изоляции в герметичной среде. Такое объединение сохранит плюральность языков Unix, в отличие от необходимости писать все методы на Smalltalk, и позволит преодолеть фрустрацию от существующих, но недостаточно развитых возможностей Unix в области персистентности, динамического обновления ПО, единообразия и открытости GUI.

• Пользователи обсуждают, что Xerox PARC мог бы стать основой для UNIX, но вместо этого остался в истории как упущенная возможность.
• Конференция ICFP/SPLASH 2024 стала поводом вспомнить о том, как давно не было никаких прорывов в области ОС и языков программирования.
• Участники обсуждают, что современные исследования в области ОС и языков программирования не предлагают ничего нового, а лишь переосмысливают старые идеи.
• Участники также отмечают, что даже такие концепции как компонентное программирование и модулярность, которые когда-то были новаторскими, сегодня являются лишь переосмыслением старых идей.
• В обсуждении также поднимается вопрос о том, что сообщество открытого кода могло бы внедрить эти идеи, но вместо этого сосредотачивается на полемике вокруг лицензий и "open source"-а.

Как MVC стало таким бардаком

Классическое Smalltalk-MVC:

• Model — данные, ничего не знает об UI.
• View — рисует Model, подписывается на её изменения.
• Controller — переводит клики/клавиши в команды Model.

Связь Model→View только через наблюдение (observer), поэтому Model переиспользуема.

Apple (и большинство фреймворков) всё перепутали:

• View и Controller слили в «View-Controller» — толстый монстр, который одновременно держит UI-элементы и кучу логики.
• Controller превратился в мусорный бак кода, «непереиспользуемый — но это нормально».
• Model зачастую делают пассивной структурой, а состояние хранят в самом виджете (чекбокс знает своё значение).

Итог: вместо «Model как источник истины» получаем размазанное состояние по View-Controller’ам, гонки данных и невозможность тестировать.

Почему случилось: в C/Pascal сделать observable-Model было больно, поэтому в Xerox Lisa пожертвовали чистотой ради скорости. За ними потянулись все.

Как надо:
Model — любой observable-объект (даже bool в обёртке). View подписывается и рисует текущее значение; никогда не спрашивает «каков чекбокс?» — он знает только Model. Controller лишь говорит Model «переключись». Можно цеплять сколько угодно View к одной Model без изменения кода.

• MVC — «религия без евангелия»: все уверены, что знают, что такое Model и View, но Controller — у каждого свой.
• Исходные определения настолько абстрактны, что под MVC подгоняют любую структуру из трёх классов; реальные кодовые базы показывают 1:1 связь V-C, что уничтожает пользу разделения.
• Контроллер быстро превращается в «всё, что не влезло в M или V», из-за чего страдает тестируемость и масштабируемость; 15 лет рефакторинга iOS-проектов подтверждают: 100 % проблем — в недостаточной проработке Model.
• RAD-фреймворки и визуальные редакторы ускорили искажение: код-behind стал контроллером, а «настоящий» MVC остался только в Smalltalk-историях.
• Практический выход: оставить MV, убрать лишний C или превратить его в тонкий «GluePuppy», который просто связывает наблюдаемую Model с реактивной View; всё остальное — следствие Expression Problem и отсутствия языковой поддержки композиции.

Я пишу свой язык Baba Yaga — чисто из любви к эстетике кода. Рабочий интерпретатор есть, но полноценной среды пока нет; планирую браузерный «бесконечный холст» в духе Smalltalk.

Язык — эксперимент ради удовольствия: неизменяемость, функциональный стиль, минимальный синтаксис, базовые «батарейки». Это Toki Pona для Haskell.

Синтаксис и типы

Объявления переменных и функций одинаковы; скобки не нужны, каррирование бесплатно.

transport : "Chicken House"
add : x y -> x + y
add5 : add 5

Базовые неизменяемые типы: Int, Float, String, Bool, List, Table.

numbers : [1, 2, 3]
person : {name: "Lucy", age: 23}

Типы можно указать явно; без аннотаций всё проверяется только во время вызова.

Управление потоком

Единственный способ — when (pattern matching). Нет if/else или switch.

describe : x ->
  when x is
    0 then "Zero"
    _ then "Something else"

processUser : user ->
  when user is
    {name: n, age: a, active: true} -> "Adult: " .. n
    _ -> "Unknown"

Пример: жизнь Конвея уже работает.

• Участники делятся опытом создания языков: @codr7 показал фреймворк Shi, @aldousd666 рассказал о своих интерпретаторах, начавшихся в 2006-м.
• Разгорелся спор о синтаксисе: одни хвалят «:» для присваивания, другие защищают «=» как уже устоявшийся символ.
• Кто-то предлагает отказаться от точек с запятой, кто-то считает их полезным разделителем.
• Обсуждаются математические корни обозначений: одни считают «=» сравнением, другие — утверждением.
• Предлагаются альтернативы: «:=», «<-», «=>», а также идея вызывать функции в порядке чтения.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

• Автор рассказал, как после появления VSCode и LSP перестал использовать языки без типов и теперь не хочет возвращаться к Ruby без нормальной типизации.
• Участники обсуждают, что Ruby остаётся элегантным и «радостным», но его отказ от постепенной типизации (включая Sorbet) отталкивает многих.
• Python, напротив, эволюционирует: появились аннотации типов, LSP, но язык стал сложнее и уже не «выучить за выходные».
• Некоторые считают, что страсть к Ruby — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

SmallJS — свободная реализация Smalltalk-80, компилирующаяся в JavaScript для браузеров и Node.js.

• v1.7 уже доступна (GitHub).
• Работа ведётся в файлах, а не образах; отлично сочетается с VS Code (подсветка, отладка).
• Используются привычные JS-имена классов и методов; в комплекте обёртки для DOM, Express, БД, потоков.

Быстрый старт — примеры проектов и Todo-приложение.

Хотите помочь? Пишите на info@small-js.org.

• SmallJS вызвал всплеск интереса; автор @Smalltalker-80 откликается на вопросы.
• Проект файл-ориентирован, без образа; VSCode вместо браузерной IDE.
• flavio81 и wild_egg сожалеют о потере «живого» Smalltalk-опыта и сложностях синхронизации образов в Lisp.
• Playground SmallJS компилирует выражения прямо в браузере, но полноценной live-среды нет.
• Упомянуты Amber (застой), Pharo (монолитная VM) и Chrome Workspace для хот-релоада.