Почему Smalltalk вместо Ruby

Ruby - популярный язык, во многом благодаря Rails. Ruby заимствует ООП из Smalltalk, но в остальном это совсем другой язык. Я собираюсь возразить, что Smalltalk по-прежнему технически лучше, чем Ruby.

Ruby привлекает программистов своим чистым и простым синтаксисом. Однако Smalltalk - это высшая степень чистоты, простоты и минимализма. Его синтаксис можно резюмировать на открытке! Он имеет три основных функции: объекты, лямбды (замыкания) и отражение. Язык исключительно простой для понимания. Руби, не очень.

Вот почему я всегда рекомендую Smalltalk новичкам. Он был разработан для обучения программированию детей. Алан Кей и др. имел правильную идею.

Несмотря на свою простоту, Smalltalk ничего не теряет с точки зрения возможностей программирования. Он был использован объединенными вооруженными силами США для написания программы моделирования сражений на миллион строк под названием JWARS (которая, кстати, превзошла аналогичную симуляцию под названием STORM, написанную на C ++ ВВС США). Smalltalk достаточно мощный, чтобы служить коммерческой индустрии более трех десятилетий!

Мощные языки не нуждаются во всевозможных специальных функциях, что характерно для C ++, Scala, Rust, Swift и, конечно же, Python и Ruby. Вот почему я также фанат Scheme, Forth и Go… маленький, простой, минималистичный.

Smalltalk является синонимом его IDE живого кодирования и отладки, что является основной причиной невероятной производительности. В два раза продуктивнее Руби. Более чем в три раза продуктивнее, чем JavaScript!

Постоянство «образа» Smalltalk также значительно экономит время: вы можете сохранить все состояние выполнения приложения и возобновить выполнение позже. Это очень удобно для поддержания непрерывности рабочего процесса.

Smalltalk обладает потрясающими возможностями для доменно-ориентированных языков. Это проще и приятнее, чем макросы Lisp или подход Ruby.

По сравнению со Smalltalk, Ruby немного неуклюже обрабатывает блоки. Ссылаясь на Lambda the Ultimate:

В Smalltalk существует простой синтаксис для создания замыкания и передачи его как обычного аргумента и получения этого аргумента с обычным параметром, а затем для вызова замыкания и / или его передачи. Семантически Ruby имеет одинаковые возможности для создания, передачи и использования замыканий. Однако Ruby использует для этих целей необычный синтаксис, который я не вижу никакой пользы. В вызове есть специально выделенная позиция аргумента, специально для передачи замыкания. Если вы собираетесь создать замыкание в этой позиции, синтаксис прост. Но замыкание в простейшем синтаксисе не является выражением. Он идет только в этой специальной позиции в синтаксисе или перед ним должно стоять слово «лямбда», чтобы преобразовать его в выражение, которое можно было бы поместить в позицию обычного аргумента или в любой другой контекст выражения (например, правая часть задания). Если метод ожидает получения блока в качестве аргумента, разработчик должен выбрать между тем, чтобы он принимал блок как обычный аргумент или как специальный аргумент блока (любой из них может быть выбран в мономорфном случае). И если методу нужно принять два блока, по крайней мере один из них должен быть передан как обычный аргумент, поэтому необходимо принять решение, передавать ли один в качестве специального аргумента, и если да, то какой. Преобразование в обоих направлениях доступно во всех контекстах, где это имеет смысл, между специальным аргументом или параметром и обычным выражением. Я думаю, что эта исключительность синтаксиса Ruby накладывает значительную дополнительную концептуальную нагрузку на понимание синтаксиса. Обработка блоков в Smalltalk очень экономична, независимо от того, передаются ли они в качестве аргументов прямо на этапе создания или нет.

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

Конечно, ни один язык программирования не идеален. На мой взгляд, из всех жалоб на Smalltalk, которые я когда-либо слышал, лишь небольшая часть имеет хоть какое-то значение. Большинство из них основаны на незнании.

Ruby больше всего известен своим фреймворком Rails. Smalltalk также имеет свои собственные Rails. Он называется Seaside (он же Heretic Web Framework). Seaside основан на многоразовых компонентах с отслеживанием состояния. Ключевая функция, поддерживающая это, называется продолжением. Продолжение - это снимок текущего состояния управления программой. Это позволяет вам перейти к другому выполнению, и когда вы вернетесь, текущее состояние будет восстановлено. Это обеспечивает стандартный механизм вызов / возврат для вашего веб-приложения. Это может помочь решить такие проблемы, как проблемы с двойным запросом и кнопкой "Назад".

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

Ruby и Python часто называют отличными решениями для стартапов. Я утверждаю, что Smalltalk ничем не хуже, если не лучше. Smalltalk не имеет себе равных в области быстрого прототипирования; Использование Smalltalk напоминает дзен. Я много слышу об этом от Smalltalkers.

Все вышеперечисленное было бы невозможно, если бы Smalltalk не был красивым, простым языком, IDE и средой выполнения, объединенными в одно и тесно связанными.

Брет Виктор в своем замечательном выступлении «Будущее программирования» указывает на Smalltalk как на предвестник того, как будет развиваться создание программного обеспечения через четыре десятилетия в будущем (с 1973 года):

Почему мы до сих пор используем файловые инструменты ??? Мы неандертальцы?

Разумеется, Smalltalk не так популярен, как Ruby. Это причина моего благовестия на Smalltalk. Однако популярность не должна закрывать вам глаза на другие возможности, на другие лучшие способы написания программного обеспечения.

Прочтите мою основополагающую статью о Smalltalk (которую просмотрели более 25 000 человек по всему миру!): Как изучение Smalltalk может сделать вас лучшим разработчиком.

Вы можете сделать создание программного обеспечения более простым, продуктивным и менее утомительным. Вы можете переделать будущее разработки программного обеспечения. Лекарство от недуга сегодняшнего допотопного стиля программирования с использованием слабо интегрированных файловых инструментов очень и очень простое: дать Smalltalk шанс.

Первоначально опубликовано на arkency.com.