I know a lot of Java people have started looking at Scala since it runs on the JVM, and a lot of people in the Microsoft world are looking at F#, but what does Ruby have as a natural functional successor?
我知道自从Scala在JVM上运行以来，很多Java用户已经开始关注它了，很多微软用户也在关注f#，但是Ruby作为一个自然的功能继承者有什么优势呢?
In a pure FP sense Ruby doesn't lack anything, instead it has too much some may say. A functional language forces the programmer to not use global variables and other idioms so much (although it is possible to use globals in functional languages)
从纯粹的FP意义上说，Ruby并不缺少任何东西，相反，它可能有太多的东西要说。函数性语言迫使程序员不要过多地使用全局变量和其他习惯用法(尽管在函数性语言中可以使用全局变量)
7 个解决方案
#1
75
There's two very different definitions of what "functional programming" means. You can kind-of do the one in Ruby, but you cannot do the other.
对于“函数式编程”的含义有两种截然不同的定义。你可以用Ruby做一个，但不能做另一个。
Those two definitions are:
这两个定义:
- programming with first-class functions and
- 用一流的函数和
- programming with mathematical functions
- 编程和数学函数
You can kind-of program with first-class functions in Ruby. It has support for first-class functions. In fact, it has too much support for them: there is Proc.new, proc, lambda, Method, UnboundMethod, blocks, #to_proc and ->() (and probably some others that I forget).
您可以在Ruby中使用一流的函数来编写程序。它支持一流的功能。实际上，它对它们有太多的支持:有proc .new、proc、lambda、方法、UnboundMethod、block、#to_proc和->()(可能还有一些我忘记了的)。
All of these behave slightly differently, have slightly different syntax, slightly different behavior and slightly different restrictions. For example: the only one of these which is syntactically lightweight enough that you can actually use it densely, is blocks. But blocks have some rather severe restrictions: you can only pass one block to a method, blocks aren't objects (which in an object-oriented language in wich "everything is an object" is a very severe restriction) and at least in Ruby 1.8 there are also some restrictions w.r.t parameters.
所有这些行为稍有不同，语法略有不同，行为略有不同，限制也略有不同。例如:其中唯一一个语法上足够轻的可以让你真正密集使用的是块。但是块有一些非常严格的限制:您只能将一个块传递给一个方法，块不是对象(在面向对象语言中，“一切都是对象”是一个非常严格的限制)，而且至少在Ruby 1.8中还有一些限制。t参数。
Referring to a method is another thing that is fairly awkward. In Python or ECMAScript for example, I can just say baz = foo.bar to refer to the bar method of the foo object. In Ruby, foo.bar is a method call, if I want to refer to the bar method of foo, I have to say baz = foo.method(:bar). And if I now want to call that method, I cannot just say baz(), I have to say baz.call or baz[] or (in Ruby 1.9) baz.().
引用一个方法是另一件相当尴尬的事情。例如，在Python或ECMAScript中，我只能写上baz = foo。bar指向foo对象的bar方法。在Ruby中,foo。bar是一个方法调用，如果我想引用foo的bar方法，我必须输入baz = foo.method(:bar)。如果我现在想调用那个方法，我不能只说baz()，我必须说baz。调用或baz[]或(Ruby 1.9) baz.()。
So, first-class functions in Ruby aren't really first-class. They are much better than second-class, and they are good enough™, but they aren't fully first-class.
因此，Ruby中的一流功能并不是真正的一流。他们比二等,它们足够好™,但是他们并不是完全一流。
But generally, Rubyists do not leave Ruby just for first-class functions. Ruby's support is good enough that any advantages you might gain from better support in another language usually is eaten up by the training effort for the new language or by something else that you are accustomed to that you must now give up. Like, say RubyGems or tight Unix integration or Ruby on Rails or syntax or …
但是一般来说，Rubyists并不是为了一流的功能而离开Ruby。Ruby的支持已经足够好了，你可能从其他语言的更好支持中获得的任何优势通常会被新语言的训练所消耗，或者你已经习惯了的其他东西，你现在必须放弃了。比如RubyGems，紧密的Unix集成，Ruby on Rails，语法等等。
However, the second definition of FP is where Ruby falls flat on its face. If you want to do programming with mathematical functions in Ruby, you are in for a world of pain. You cannot use the absolute majority of Ruby libraries, because most of them are stateful, effectful, encourage mutation or are otherwise impure. You cannot use the standard library for the same reasons. You cannot use the core library. You cannot use any of the core datatypes, because they are all mutable. You could just say "I don't care that they are mutable, I will simply not mutate them and always copy them", but the problem is: someone else still can mutate them. Also, because they are mutable, Ruby cannot optimize the copying and the garbage collector isn't tuned for that kind of workload.
然而，FP的第二个定义是Ruby在它的表面上是平的。如果你想用Ruby中的数学函数来编程，那你将会陷入痛苦的世界。您不能使用Ruby库的绝对多数，因为大多数库是有状态的、有效的、鼓励突变的，或者是不纯的。出于同样的原因，您不能使用标准库。不能使用核心库。您不能使用任何核心数据类型，因为它们都是可变的。你可以说:“我不在乎它们是可变的，我只是不会改变它们，而且总是复制它们”，但问题是:其他人仍然可以改变它们。而且，由于它们是可变的，Ruby无法优化复制，垃圾收集器也无法适应这种工作负载。
It just doesn't work.
它只是不工作。
There is also a couple of features that have really nothing to do with functional programming but that most functional languages tend to have, that Ruby is missing. Pattern matching, for example. Laziness also was not that easy to achieve before Enumerators were more aggressively used in Ruby 1.9. And there's still some stuff that works with strict Enumerables or Arrays but not with lazy Enumerators, although there's actually no reason for them to require strictness.
也有一些特性与函数式编程毫无关系，但是大多数函数式语言都有Ruby缺失的特性。例如,模式匹配。在Ruby 1.9中使用枚举器之前，惰性也不是那么容易实现的。仍然有一些东西可以使用严格的枚举数或数组，但是不能使用惰性的枚举数，尽管实际上没有理由要求它们严格。
And for this definition of FP, it definitely makes sense to leave Ruby behind.
对于这个FP的定义，离开Ruby是完全有意义的。
The two main languages that Rubyists have been flocking to, are Erlang and Clojure. These are both relatively good matches for Ruby, because they are both dynamically typed, have a similar REPL culture as Ruby, and (this is more a Rails thing than a Ruby thing) are also very good on the web. They have still pretty small and welcoming communities, the original language creators are still active in the community, there is a strong focus on doing new, exciting and edgy things, all of which are traits that the Ruby community also has.
rubyist聚集的两种主要语言是Erlang和Clojure。这两个都是Ruby的比较好的匹配，因为它们都是动态类型的，具有与Ruby相似的REPL文化，而且(这更像是Rails而不是Ruby)在web上也非常好。他们仍然有非常小和欢迎的社区，原始的语言创建者仍然活跃在社区中，有强烈的关注做新的、令人兴奋的和前卫的事情，所有这些都是Ruby社区拥有的特性。
The interest in Erlang started, when someone showed the original 1993 introduction video "Erlang: The Movie" at RubyConf 2006. A couple of high-profile Rails projects started using Erlang, for example PowerSet and GitHub. Erlang is also easy to master for Rubyists, because it doesn't take purity quite as far as Haskell or Clean. The inside of an actor is pretty pure, but the act of sending messages itself is of course a side-effect. Another thing that makes Erlang easy to grasp, is that Actors and Objects are actually the same thing, when you follow Alan Kay's definition of object-oriented programming.
人们对Erlang的兴趣开始于1993年的《Erlang: The Movie》，当时有人在RubyConf 2006年上映。一些引人注目的Rails项目开始使用Erlang，例如PowerSet和GitHub。对于反刍者来说，Erlang也很容易掌握，因为它不需要像Haskell或Clean那么纯粹。演员的内在是相当纯粹的，但是发送消息本身当然是一个副作用。另一件让Erlang易于理解的事情是，当您遵循Alan Kay对面向对象编程的定义时，参与者和对象实际上是相同的。
Clojure has been a recent addition to the Rubyist's toolbelt. Its popularity is I guess mostly driven by the fact that the Ruby community has finally warmed up to the idea that JVM ≠ Java and embraced JRuby and then they started to look around what other interesting stuff there was on the JVM. And again, Clojure is much more pragmatic than both other functional languages like Haskell and other Lisps like Scheme and much simpler and more modern than CommonLisp, so it is a natural fit for Rubyists.
Clojure是Rubyist的新工具。它的受欢迎程度是我想主要由Ruby社区终于热身,JVM≠Java和拥抱JRuby,然后他们开始四处看看有什么其他有趣的东西在JVM上。再说一遍，Clojure比Haskell和Scheme等其他函数性语言更实用，比CommonLisp更简单、更现代，因此它很适合ruby爱好者。
Another cool thing about Clojure is that because both Clojure and Ruby run on the JVM, you can combine them.
Clojure的另一个好处是，因为Clojure和Ruby都在JVM上运行，所以您可以将它们组合在一起。
The author of "Programming Clojure" (Stuart Halloway) is a (former?) Rubyist, for example, as is Phil Hagelberg, the author of the Leiningen build tool for Clojure.
《Clojure编程》(Stuart Halloway)一书的作者是a(前作家?)例如，Rubyist和Phil Hagelberg一样，他是Clojure的Leiningen构建工具的作者。
However, Rubyists are also looking at both Scala (as one of the more pragmatic statically typed FP languages) and Haskell (as one of the more elegant ones). Then there is projects like Scuby and Hubris which are bridges that let you integrate Ruby with Scala and Haskell, respectively. Twitter's decision to move part of their low-level messaging infrastructure first from MySQL to Ruby, then from Ruby to Scala is also pretty widely known.
然而，Rubyists也考虑Scala(作为一种更实用的静态类型的FP语言)和Haskell(作为一种更优雅的语言)。然后还有一些项目，比如Scuby和pride，它们是让您分别将Ruby与Scala和Haskell集成在一起的桥梁。Twitter决定首先将部分低级消息传递基础设施从MySQL转移到Ruby，然后再从Ruby转移到Scala，这也是众所周知的。
F# doesn't seem to play any role at all, possibly due to an irrational fear towards all things Microsoft the Ruby community has. (Which, BTW, seems mostly unfounded, given that the F# team has always made versions available for Mono.)
f#似乎一点作用都没有，可能是由于对所有微软Ruby社区拥有的东西的非理性恐惧。(顺便说一句，考虑到f#团队一直为Mono提供版本，这似乎几乎毫无根据。)
#2
15
Java people are using a language on the JVM and want a more functional one compatible with their runtime, so they go to Scala.
Java用户正在JVM上使用一种语言，并且想要一种与他们的运行时兼容的功能更强的语言，所以他们使用Scala。
C# people are using a language on the CLR and want a more functional one compatible with their runtime, so they go to F#.
c#人们在CLR上使用一种语言，并希望一种功能更强的语言与他们的运行时兼容，所以他们选择f#。
Ruby people are using a language that's already pretty functional, and they're using it on a number of underlying runtimes (JRuby, IronRuby, MRI, MacRuby, Rubinius, etc...). I don't think it has a natural functional successor, or even needs one.
Ruby用户正在使用一种已经相当实用的语言，并且他们在许多底层运行时(JRuby、IronRuby、MRI、MacRuby、Rubinius等等)上使用它。我不认为它有一个天然的功能继承者，甚至不需要一个。
#3
7
Any version of Lisp should be fine.
任何版本的Lisp都可以。
#4
6
Ruby it self is a kind of Functional programming language, So I don't see any special dialects for FP using ruby.
Ruby it self是一种函数式编程语言，所以我没有看到使用Ruby的FP有什么特别的方言。
#5
3
In hype level, Haskell.
在宣传层面,Haskell。
#6
3
Assuming Ruby people don't just go to the JVM themselves, I think most would adopt Erlang, being another dynamically typed language.
假设Ruby用户不只是访问JVM本身，我认为大多数人会采用Erlang，这是另一种动态类型语言。
#7
3
Ruby isn't as functional as say Lisp, but it is just functional enough that you can do some functional programming in a good fun way. (unlike trying to do functional programming in something like C#)
Ruby没有Lisp那样的功能，但它的功能已经足够，您可以用一种有趣的方式进行一些函数式编程。(不像用c#那样做函数式编程)
Also, it actually forces you into functional paradigms in some of its syntax, such as the heavy use of blocks and yield. (which I fell in love with after learning Ruby).
而且，它实际上迫使您在一些语法中使用功能范例，例如大量使用块和yield。(在学习了Ruby之后，我爱上了它)。
#1
75
There's two very different definitions of what "functional programming" means. You can kind-of do the one in Ruby, but you cannot do the other.
对于“函数式编程”的含义有两种截然不同的定义。你可以用Ruby做一个，但不能做另一个。
Those two definitions are:
这两个定义:
- programming with first-class functions and
- 用一流的函数和
- programming with mathematical functions
- 编程和数学函数
You can kind-of program with first-class functions in Ruby. It has support for first-class functions. In fact, it has too much support for them: there is Proc.new, proc, lambda, Method, UnboundMethod, blocks, #to_proc and ->() (and probably some others that I forget).
您可以在Ruby中使用一流的函数来编写程序。它支持一流的功能。实际上，它对它们有太多的支持:有proc .new、proc、lambda、方法、UnboundMethod、block、#to_proc和->()(可能还有一些我忘记了的)。
All of these behave slightly differently, have slightly different syntax, slightly different behavior and slightly different restrictions. For example: the only one of these which is syntactically lightweight enough that you can actually use it densely, is blocks. But blocks have some rather severe restrictions: you can only pass one block to a method, blocks aren't objects (which in an object-oriented language in wich "everything is an object" is a very severe restriction) and at least in Ruby 1.8 there are also some restrictions w.r.t parameters.
所有这些行为稍有不同，语法略有不同，行为略有不同，限制也略有不同。例如:其中唯一一个语法上足够轻的可以让你真正密集使用的是块。但是块有一些非常严格的限制:您只能将一个块传递给一个方法，块不是对象(在面向对象语言中，“一切都是对象”是一个非常严格的限制)，而且至少在Ruby 1.8中还有一些限制。t参数。
Referring to a method is another thing that is fairly awkward. In Python or ECMAScript for example, I can just say baz = foo.bar to refer to the bar method of the foo object. In Ruby, foo.bar is a method call, if I want to refer to the bar method of foo, I have to say baz = foo.method(:bar). And if I now want to call that method, I cannot just say baz(), I have to say baz.call or baz[] or (in Ruby 1.9) baz.().
引用一个方法是另一件相当尴尬的事情。例如，在Python或ECMAScript中，我只能写上baz = foo。bar指向foo对象的bar方法。在Ruby中,foo。bar是一个方法调用，如果我想引用foo的bar方法，我必须输入baz = foo.method(:bar)。如果我现在想调用那个方法，我不能只说baz()，我必须说baz。调用或baz[]或(Ruby 1.9) baz.()。
So, first-class functions in Ruby aren't really first-class. They are much better than second-class, and they are good enough™, but they aren't fully first-class.
因此，Ruby中的一流功能并不是真正的一流。他们比二等,它们足够好™,但是他们并不是完全一流。
But generally, Rubyists do not leave Ruby just for first-class functions. Ruby's support is good enough that any advantages you might gain from better support in another language usually is eaten up by the training effort for the new language or by something else that you are accustomed to that you must now give up. Like, say RubyGems or tight Unix integration or Ruby on Rails or syntax or …
但是一般来说，Rubyists并不是为了一流的功能而离开Ruby。Ruby的支持已经足够好了，你可能从其他语言的更好支持中获得的任何优势通常会被新语言的训练所消耗，或者你已经习惯了的其他东西，你现在必须放弃了。比如RubyGems，紧密的Unix集成，Ruby on Rails，语法等等。
However, the second definition of FP is where Ruby falls flat on its face. If you want to do programming with mathematical functions in Ruby, you are in for a world of pain. You cannot use the absolute majority of Ruby libraries, because most of them are stateful, effectful, encourage mutation or are otherwise impure. You cannot use the standard library for the same reasons. You cannot use the core library. You cannot use any of the core datatypes, because they are all mutable. You could just say "I don't care that they are mutable, I will simply not mutate them and always copy them", but the problem is: someone else still can mutate them. Also, because they are mutable, Ruby cannot optimize the copying and the garbage collector isn't tuned for that kind of workload.
然而，FP的第二个定义是Ruby在它的表面上是平的。如果你想用Ruby中的数学函数来编程，那你将会陷入痛苦的世界。您不能使用Ruby库的绝对多数，因为大多数库是有状态的、有效的、鼓励突变的，或者是不纯的。出于同样的原因，您不能使用标准库。不能使用核心库。您不能使用任何核心数据类型，因为它们都是可变的。你可以说:“我不在乎它们是可变的，我只是不会改变它们，而且总是复制它们”，但问题是:其他人仍然可以改变它们。而且，由于它们是可变的，Ruby无法优化复制，垃圾收集器也无法适应这种工作负载。
It just doesn't work.
它只是不工作。
There is also a couple of features that have really nothing to do with functional programming but that most functional languages tend to have, that Ruby is missing. Pattern matching, for example. Laziness also was not that easy to achieve before Enumerators were more aggressively used in Ruby 1.9. And there's still some stuff that works with strict Enumerables or Arrays but not with lazy Enumerators, although there's actually no reason for them to require strictness.
也有一些特性与函数式编程毫无关系，但是大多数函数式语言都有Ruby缺失的特性。例如,模式匹配。在Ruby 1.9中使用枚举器之前，惰性也不是那么容易实现的。仍然有一些东西可以使用严格的枚举数或数组，但是不能使用惰性的枚举数，尽管实际上没有理由要求它们严格。
And for this definition of FP, it definitely makes sense to leave Ruby behind.
对于这个FP的定义，离开Ruby是完全有意义的。
The two main languages that Rubyists have been flocking to, are Erlang and Clojure. These are both relatively good matches for Ruby, because they are both dynamically typed, have a similar REPL culture as Ruby, and (this is more a Rails thing than a Ruby thing) are also very good on the web. They have still pretty small and welcoming communities, the original language creators are still active in the community, there is a strong focus on doing new, exciting and edgy things, all of which are traits that the Ruby community also has.
rubyist聚集的两种主要语言是Erlang和Clojure。这两个都是Ruby的比较好的匹配，因为它们都是动态类型的，具有与Ruby相似的REPL文化，而且(这更像是Rails而不是Ruby)在web上也非常好。他们仍然有非常小和欢迎的社区，原始的语言创建者仍然活跃在社区中，有强烈的关注做新的、令人兴奋的和前卫的事情，所有这些都是Ruby社区拥有的特性。
The interest in Erlang started, when someone showed the original 1993 introduction video "Erlang: The Movie" at RubyConf 2006. A couple of high-profile Rails projects started using Erlang, for example PowerSet and GitHub. Erlang is also easy to master for Rubyists, because it doesn't take purity quite as far as Haskell or Clean. The inside of an actor is pretty pure, but the act of sending messages itself is of course a side-effect. Another thing that makes Erlang easy to grasp, is that Actors and Objects are actually the same thing, when you follow Alan Kay's definition of object-oriented programming.
人们对Erlang的兴趣开始于1993年的《Erlang: The Movie》，当时有人在RubyConf 2006年上映。一些引人注目的Rails项目开始使用Erlang，例如PowerSet和GitHub。对于反刍者来说，Erlang也很容易掌握，因为它不需要像Haskell或Clean那么纯粹。演员的内在是相当纯粹的，但是发送消息本身当然是一个副作用。另一件让Erlang易于理解的事情是，当您遵循Alan Kay对面向对象编程的定义时，参与者和对象实际上是相同的。
Clojure has been a recent addition to the Rubyist's toolbelt. Its popularity is I guess mostly driven by the fact that the Ruby community has finally warmed up to the idea that JVM ≠ Java and embraced JRuby and then they started to look around what other interesting stuff there was on the JVM. And again, Clojure is much more pragmatic than both other functional languages like Haskell and other Lisps like Scheme and much simpler and more modern than CommonLisp, so it is a natural fit for Rubyists.
Clojure是Rubyist的新工具。它的受欢迎程度是我想主要由Ruby社区终于热身,JVM≠Java和拥抱JRuby,然后他们开始四处看看有什么其他有趣的东西在JVM上。再说一遍，Clojure比Haskell和Scheme等其他函数性语言更实用，比CommonLisp更简单、更现代，因此它很适合ruby爱好者。
Another cool thing about Clojure is that because both Clojure and Ruby run on the JVM, you can combine them.
Clojure的另一个好处是，因为Clojure和Ruby都在JVM上运行，所以您可以将它们组合在一起。
The author of "Programming Clojure" (Stuart Halloway) is a (former?) Rubyist, for example, as is Phil Hagelberg, the author of the Leiningen build tool for Clojure.
《Clojure编程》(Stuart Halloway)一书的作者是a(前作家?)例如，Rubyist和Phil Hagelberg一样，他是Clojure的Leiningen构建工具的作者。
However, Rubyists are also looking at both Scala (as one of the more pragmatic statically typed FP languages) and Haskell (as one of the more elegant ones). Then there is projects like Scuby and Hubris which are bridges that let you integrate Ruby with Scala and Haskell, respectively. Twitter's decision to move part of their low-level messaging infrastructure first from MySQL to Ruby, then from Ruby to Scala is also pretty widely known.
然而，Rubyists也考虑Scala(作为一种更实用的静态类型的FP语言)和Haskell(作为一种更优雅的语言)。然后还有一些项目，比如Scuby和pride，它们是让您分别将Ruby与Scala和Haskell集成在一起的桥梁。Twitter决定首先将部分低级消息传递基础设施从MySQL转移到Ruby，然后再从Ruby转移到Scala，这也是众所周知的。
F# doesn't seem to play any role at all, possibly due to an irrational fear towards all things Microsoft the Ruby community has. (Which, BTW, seems mostly unfounded, given that the F# team has always made versions available for Mono.)
f#似乎一点作用都没有，可能是由于对所有微软Ruby社区拥有的东西的非理性恐惧。(顺便说一句，考虑到f#团队一直为Mono提供版本，这似乎几乎毫无根据。)
#2
15
Java people are using a language on the JVM and want a more functional one compatible with their runtime, so they go to Scala.
Java用户正在JVM上使用一种语言，并且想要一种与他们的运行时兼容的功能更强的语言，所以他们使用Scala。
C# people are using a language on the CLR and want a more functional one compatible with their runtime, so they go to F#.
c#人们在CLR上使用一种语言，并希望一种功能更强的语言与他们的运行时兼容，所以他们选择f#。
Ruby people are using a language that's already pretty functional, and they're using it on a number of underlying runtimes (JRuby, IronRuby, MRI, MacRuby, Rubinius, etc...). I don't think it has a natural functional successor, or even needs one.
Ruby用户正在使用一种已经相当实用的语言，并且他们在许多底层运行时(JRuby、IronRuby、MRI、MacRuby、Rubinius等等)上使用它。我不认为它有一个天然的功能继承者，甚至不需要一个。
#3
7
Any version of Lisp should be fine.
任何版本的Lisp都可以。
#4
6
Ruby it self is a kind of Functional programming language, So I don't see any special dialects for FP using ruby.
Ruby it self是一种函数式编程语言，所以我没有看到使用Ruby的FP有什么特别的方言。
#5
3
In hype level, Haskell.
在宣传层面,Haskell。
#6
3
Assuming Ruby people don't just go to the JVM themselves, I think most would adopt Erlang, being another dynamically typed language.
假设Ruby用户不只是访问JVM本身，我认为大多数人会采用Erlang，这是另一种动态类型语言。
#7
3
Ruby isn't as functional as say Lisp, but it is just functional enough that you can do some functional programming in a good fun way. (unlike trying to do functional programming in something like C#)
Ruby没有Lisp那样的功能，但它的功能已经足够，您可以用一种有趣的方式进行一些函数式编程。(不像用c#那样做函数式编程)
Also, it actually forces you into functional paradigms in some of its syntax, such as the heavy use of blocks and yield. (which I fell in love with after learning Ruby).
而且，它实际上迫使您在一些语法中使用功能范例，例如大量使用块和yield。(在学习了Ruby之后，我爱上了它)。