Я знаю, что многие люди Java начали смотреть на Scala, поскольку он работает на JVM, и многие люди в мире Microsoft смотрят на F #, но что делает Ruby как естественный функциональный преемник?
В чистом смысле FP Ruby не испытывает недостатка в чем-либо, вместо этого он может сказать слишком много. Функциональный язык заставляет программиста не использовать глобальные переменные и другие идиомы так много (хотя можно использовать глобалы в функциональных языках)
Существуют два очень разных определения того, что означает "функциональное программирование". Вы можете сделать один из них в Ruby, но вы не можете сделать другого.
Эти два определения:
Вы можете иметь вид программы с первоклассными функциями в Ruby. Он поддерживает первоклассные функции. На самом деле это слишком много для них: есть Proc.new, proc, lambda, Method, UnboundMethod, blocks, #to_proc и ->() (и, возможно, некоторые другие, которые я забыл).
Все эти ведут себя несколько иначе, имеют немного отличающийся синтаксис, немного другое поведение и несколько иные ограничения. Например: единственный из них, который является синтаксически достаточно легким, что вы действительно можете использовать его плотно, - это блоки. Но блоки имеют довольно жесткие ограничения: вы можете передавать только один блок методу, блоки - это не объекты (которые на объектно-ориентированном языке, в котором "все является объектом", является очень серьезным ограничением) и, по крайней мере, в Ruby 1.8 есть также некоторые ограничения по параметрам.
Ссылаясь на метод, это еще одна вещь, которая довольно неудобна. В Python или ECMAScript, например, я можно просто сказать baz = foo.bar для ссылки на метод bar объекта foo. В Ruby foo.bar - вызов метода, если я хочу обратиться к методу bar foo, я должен сказать baz = foo.method(:bar). И если я теперь хочу назвать этот метод, я не могу просто сказать baz(), я должен сказать baz.call или baz[] или (в Ruby 1.9) baz.().
Итак, первоклассные функции в Ruby не являются действительно первоклассными. Они намного лучше, чем второсортные, и они достаточно хороши и торгуют, но они не полностью первоклассны.
Но, как правило, рубисты не оставляют Ruby только для первоклассных функций. Поддержка Ruby достаточно хороша, что любые преимущества, которые вы могли бы получить от лучшей поддержки на другом языке, обычно съедают усилия по обучению новому языку или чему-то еще, к чему вы привыкли, что теперь вы должны отказаться. Например, скажем RubyGems или жесткая интеграция Unix или Ruby on Rails или синтаксис или & hellip;
Однако второе определение FP - это то, где Ruby падает на его лице. Если вы хотите выполнять программирование с помощью математических функций в Ruby, вы находитесь в мире боли. Вы не можете использовать абсолютное большинство библиотек Ruby, потому что большинство из них являются работоспособными, эффективными, способствуют мутации или иным образом нечисты. Вы не можете использовать стандартную библиотеку по тем же причинам. Вы не можете использовать основную библиотеку. Вы не можете использовать какие-либо базовые типы данных, потому что все они изменяемы. Вы могли бы просто сказать: "Мне все равно, что они изменяемы, я просто не буду мутировать их и всегда их копировать", но проблема в том, что кто-то еще может их мутировать. Кроме того, поскольку они изменяемы, Ruby не может оптимизировать копирование, и сборщик мусора не настроен на такую рабочую нагрузку.
Он просто не работает.
Существует также несколько функций, которые действительно не имеют никакого отношения к функциональному программированию, но большинство функциональных языков имеют тенденцию иметь, что Ruby отсутствует. Например, сопоставление шаблонов. Лень также было не так легко достичь, прежде чем Enumerator были более агрессивно использованы в Ruby 1.9. И еще есть материал, который работает со строгим Enumerable или Array, но не с ленивым Enumerator s, хотя на самом деле нет причин для их требовать строгости.
И для этого определения FP, определенно имеет смысл оставить Ruby позади.
Двумя основными языками, с которыми рубисты стекались, являются Erlang и Clojure. Они являются относительно хорошими совпадениями для Ruby, потому что они оба динамически типизированы, имеют аналогичную культуру REPL как Ruby, и (это больше Rails, чем вещь Ruby) также очень хороши в Интернете. У них все еще довольно маленькие и приветливые сообщества, оригинальные разработчики языка по-прежнему активны в сообществе, здесь сосредоточено внимание на новых, захватывающих и резких вещах, все из которых являются чертами, которые также имеют сообщество Ruby.
Интерес к Erlang начался, когда кто-то показал оригинальное видео в 1993 году "Erlang: The Movie "на RubyConf 2006. Пара высоких -profile Проекты Rails начали использовать Erlang, например PowerSetи GitHub. Эрланг также легко освоить для рубистов, потому что он не принимает чистоты до тех пор, пока Haskell или Clean. Внутри актера довольно чисто, но сам акт отправки сообщений, конечно, является побочным эффектом. Другое дело, что Эрланг легко понять, что актеры и объекты на самом деле то же самое, когда вы следуете определение объектно-ориентированного программирования Алана Кей.
Clojure был недавним дополнением к инструментальной панели Rubyist. Его популярность, по-моему, в основном обусловлена тем фактом, что сообщество Ruby, наконец, разогрело идею о том, что JVM ≠ Java и охватывает JRuby и затем они начали осматривать то, что было интересным в JVM. И снова Clojure гораздо более прагматичен, чем другие функциональные языки, такие как Haskell и другие Lisps, такие как Scheme и гораздо более простые и современные, чем CommonLisp, поэтому он естественным образом подходит для рубистов.
Еще одна интересная вещь о Clojure заключается в том, что, поскольку оба Clojure и Ruby запускаются на JVM, вы можете их комбинировать.
Автор Программирование Clojure "(Стюарт Хэллоуэй) является (бывшим?) рубистом, например, как Фил Хагельберг, автор инструмента Leiningen для Clojure.
Однако, рубисты также смотрят на Scala (как один из наиболее прагматичных статически типизированных языков FP) и Haskell (как один из более элегантных). Тогда есть проекты, такие как Scuby и Hubris которые являются мостами, которые позволяют интегрировать Ruby с Scala и Haskell, соответственно. Решение Twitter перенести часть своей низкоуровневой инфраструктуры обмена сообщениями сначала с MySQL на Ruby, а затем с Ruby на Scala также широко известно.
F #, похоже, вообще не играет никакой роли, возможно, из-за иррационального страха ко всем вещам, которые имеет сообщество Microsoft Ruby. (Что, BTW, кажется, в основном необоснованным, учитывая, что команда F # всегда делала версии доступными для Mono.)
Java-люди используют язык JVM и хотят иметь более функциональный, совместимый с их временем выполнения, поэтому они переходят к Scala.
Люди С# используют язык в CLR и хотят, чтобы более функциональный, совместимый с их временем выполнения, поэтому они переходят к F #.
Пользователи Ruby используют язык, который уже довольно функциональный, и используют его на нескольких основных этапах работы (JRuby, IronRuby, MRI, MacRuby, Rubinius и т.д.). Я не думаю, что у него есть естественный функциональный преемник или даже нужен.
Любая версия Lisp должна быть в порядке.
Ruby it self - это своего рода функциональный язык программирования, поэтому я не вижу специальных диалектов для FP, использующих ruby.
В уровне hype, Haskell.
Ruby не так функциональен, как сказать Lisp, но он достаточно функциональный, чтобы вы могли выполнить какое-то функциональное программирование. (в отличие от попыток выполнить функциональное программирование в чем-то вроде С#)
Кроме того, он фактически заставляет вас использовать функциональные парадигмы в некоторых своих синтаксисах, таких как интенсивное использование блоков и выход. (который я полюбил после изучения Ruby).
Предполагая, что люди Ruby не просто отправятся в JVM, я думаю, что большинство из них примет Erlang, будучи еще одним динамически типизированным языком.