如果 Java 人去 Scala，C# 去 F#，那么 Ruby 人去哪里寻找函数式必杀技? [英] If Java people go to Scala, C# go to F#, where do Ruby people go for functional nirvana?
问题描述
我知道很多 Java 人已经开始关注 Scala，因为它在 JVM 上运行，Microsoft 世界中的很多人都在关注 F#，但是 Ruby 作为自然的函数继承者有什么?
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?
在纯粹的 FP 意义上，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)
推荐答案
对于什么是函数式编程"，有两个非常不同的定义.方法.你可以在 Ruby 中做一个，但你不能做另一个.
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 中编写具有一流功能的程序.它支持一流的功能.事实上，它对它们的太多支持:有Proc.new、proc、lambda、Method、UnboundMethod、blocks、#to_proc 和 ->()(可能还有一些我忘记了).
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 1.8 中也有一些限制写入参数.
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.
引用一个方法是另一件相当尴尬的事情.在 Python 或 ECMAScript 中a> 例如，我可以直接说 baz = foo.bar 来引用 foo 对象的 bar 方法.在Ruby中，foo.bar是一个方法call，如果我想引用foo的bar方法，不得不说baz = foo.method(:bar).如果我现在想调用那个方法，我不能只说baz()，我必须说baz.call或baz[] 或(在 Ruby 1.9 中)baz.().
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.().
因此，Ruby 中的一流函数真的 不是一流的.它们比二流要好得多，而且它们足够好™，但还不是完全一流的.
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 开发者不会仅仅为了一流的函数而离开 Ruby.Ruby 的支持足够好，以至于您可能从另一种语言的更好支持中获得的任何优势通常会被新语言的培训工作或您现在必须付出的习惯其他所消耗向上.比如 RubyGems 或紧密的 Unix 集成或 Ruby on Rails 或语法或……
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 …
然而，FP 的第二个定义是 Ruby 一败涂地.如果您想在 Ruby 中使用数学函数进行编程，那么您将陷入痛苦的世界.您不能使用绝大多数 Ruby 库，因为它们中的大多数是有状态的、有效的、鼓励突变或不纯的.出于同样的原因，您不能使用标准库.您不能使用核心库.您不能使用任何核心数据类型，因为它们都是可变的.你可以说我不在乎它们是可变的，我不会改变它们并始终复制它们"，但问题是:其他人仍然可以改变它们.此外，由于它们是可变的，Ruby 无法优化复制，并且垃圾收集器也未针对此类工作负载进行调整.
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.
就是不行.
还有一些特性与函数式编程实际上无关，但大多数函数式语言往往都具有，而 Ruby 则缺少这些特性.例如模式匹配.在 Enumerator 在 Ruby 1.9 中更积极地使用之前，惰性也不是那么容易实现的.还有一些东西适用于严格的 Enumerables 或 Arrays 但不适用于惰性的 Enumerators，尽管实际上他们没有理由这样做要求严格.
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.
对于 FP 的这个定义，将 Ruby 抛在后面绝对是有意义的.
And for this definition of FP, it definitely makes sense to leave Ruby behind.
Rubyists 蜂拥而至的两种主要语言是 Erlang 和 Clojure.这些都是 Ruby 的相对较好的匹配，因为它们都是动态类型的，具有与 Ruby 相似的 REPL 文化，并且(这更像是 Rails 的东西而不是 Ruby 的东西)在网络上也非常好.他们仍然拥有相当小的和热情的社区，原始语言的创造者仍然活跃在社区中，他们非常专注于做新的、令人兴奋的和前卫的事情，所有这些都是 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.
人们对 Erlang 的兴趣始于 1993 年的原始介绍视频Erlang: The Movie"在 RubyConf 2006 上.一些备受瞩目的 Rails 项目开始使用 Erlang，例如 PowerSet 和 GitHub.Erlang 对 Ruby 爱好者来说也很容易掌握，因为它不像 Haskell 或 清洁.演员的内部非常纯粹，但发送消息本身的行为当然是一种副作用.另一件让 Erlang 易于掌握的事情是，当你遵循 Alan Kay 对面向对象编程的定义.
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.
Clojure 最近加入了 Rubyist 的工具带.我想它的流行主要是因为 Ruby 社区最终接受了 JVM ≠ Java 的想法并接受了 JRuby 然后他们开始查看 JVM 上有哪些其他有趣的东西.再说一次，Clojure 比 Haskell 等其他函数式语言和 Scheme 等其他 Lisps 更实用，而且更简单和比 CommonLisp 更现代，因此非常适合 Ruby 爱好者.
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 的另一个很酷的地方是，因为 Clojure 和 Ruby 都在 JVM 上运行，所以您可以组合它们.
Another cool thing about Clojure is that because both Clojure and Ruby run on the JVM, you can combine them.
Programming Clojure"的作者(Stuart Halloway) 是一位(前任?)Rubyist，例如，Phil Hagelberg，
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.
然而，Rubyists 也在关注 Scala(作为更实用的静态类型 FP 语言之一)和 Haskell(作为更优雅的之一).然后是像 Scuby 和 Hubris 它们是让您分别将 Ruby 与 Scala 和 Haskell 集成的桥梁.Twitter 决定先将部分底层消息传递基础架构从 MySQL 迁移到 Ruby，然后再从 Ruby 迁移到 Scala，这一决定也广为人知.
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.
F# 似乎根本没有发挥任何作用，可能是由于对 Microsoft 的所有事物的非理性恐惧Ruby 社区有.(顺便说一句，鉴于 F# 团队总是为 Mono 提供了可用版本，这似乎是毫无根据的.)
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.)
这篇关于如果 Java 人去 Scala，C# 去 F#，那么 Ruby 人去哪里寻找函数式必杀技?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
