如果Java人去斯卡拉，C＃转到F＃，那么Ruby的人们会去哪里实现功能性涅？？ [英] If Java people go to Scala, C# go to F#, where do Ruby people go for functional nirvana?
问题描述
我知道很多Java人开始关注Scala，因为它运行在JVM上，许多微软世界的人都在关注F＃，但Ruby作为一个自然的功能性继承者有什么作用？
在纯粹的FP意义上，Ruby并不缺乏任何东西，相反它有太多的可能说。一个函数式语言强迫程序员不要使用全局变量和其他习惯用法（尽管可以在函数式语言中使用全局变量）
对于函数式编程的含义，有两种 不同的定义。你可以在Ruby中做一个，但你不能做另一个。
这两个定义是： 您可以在Ruby中使用一流的函数进行编程。它支持一流的功能。事实上，它对它们有太多的支持：有： 所有这些的行为都略有不同，语法略有不同，语言略有不同，限制略有不同。例如：这些在语法上足够轻的密码中只有一个密码实际可以使用它，就是块。但块有一些相当严格的限制：你只能传递一个块到一个方法，块不是对象（在面向对象的语言中，一切都是对象都是 严重限制），至少在Ruby 1.8中，对于wrt参数也有一些限制。
使用数学函数编程
Proc.new ， proc ， lambda ，方法， UnboundMethod ，blocks， #to_proc 和 - >（）（可能还有一些我忘记的）。 b
引用一种方法是另一件相当尴尬的事情。在 Python 或 ECMAScript baz = foo.bar 来引用 所以，Ruby中的第一类函数并不是真正的第一类。它们比二流的要好得多，它们足够好，但它们不是一流的。 但是一般来说，Rubyists不会仅仅为了一流的功能而离开Ruby。 Ruby的支持是足够好的，以至于你可能从另一种语言的更好支持中获得的任何好处通常都会被新语言的培训努力或通过习惯于你现在必须给予的 else 向上。就像RubyGems或紧密的Unix集成或者Ruby on Rails或者语法或者… 但是，FP的第二个 它不起作用。 还有一些功能与函数式编程没有任何关系，但大多数函数式语言都倾向于缺少Ruby。例如，模式匹配。在Ruby 1.9中更加积极地使用 对于这个定义FP，所以将Ruby留在后面是很有意义的。 Rubyists已经聚集到的两种主要语言是 Erlang 和 Clojure 。这些对于Ruby来说都是相当不错的匹配，因为它们都是动态类型的，与Ruby有着相似的REPL文化，并且（这更像Rails的东西而不是Ruby的东西）在网络上也很好。他们仍然有非常小的欢迎社区，原始语言创作者仍然活跃在社区中，他们非常注重做新的，令人兴奋和前卫的事情，所有这些都是Ruby社区的特点。 对Erlang的兴趣开始了，当时有人展示了1993年的原创视频 Erlang：The Movie 。一些高调的Rails项目开始使用Erlang，例如 PowerSet < a>和 GitHub 。 Erlang也很容易掌握Rubyists，因为它不会像 Haskell 或清洁。演员的内部非常纯粹，但发送消息本身的行为当然是一种副作用。另一件让Erlang容易理解的事情是，当您按照艾伦凯的面向对象编程的定义。 Clojure是Rubyist工具带的最新成员。它的受欢迎程度大概是由于Ruby社区最终热衷于JVM≠Java并且拥抱 JRuby Scheme ）更务实，而且更简单比CommonLisp更现代，所以它非常适合Rubyists。 Clojure的另一个很酷的事情是，因为Clojure和Ruby都运行在JVM上，所以 他们。 编程Clojure （Stuart Halloway）是一位（前？）Rubyist，例如， Phil Hagelberg ， Leiningen 为Clojure构建工具的作者。 然而，Rubyists也在寻找 Scala （作为更多语用静态类型的FP语言）和Haskell（作为一种语言） f更优雅的）。然后有像 Scuby 和 Hubris ，这些桥梁可让您分别将Ruby与Scala和Haskell集成在一起。 Twitter将部分底层消息传递基础设施从MySQL迁移到Ruby，然后从Ruby迁移到Scala的决定也广为人知。 F＃似乎并没有扮演任何角色，可能是因为对Ruby社区所拥有的所有东西的无理恐惧。 （其中，顺便说一句，由于F＃团队始终为Mono提供了版本，所以它似乎大部分都是毫无根据的。） 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? 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) 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. Those two definitions are: 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 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. Referring to a method is another thing that is fairly awkward. In Python or ECMAScript for example, I can just say 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. 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 … 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. 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 And for this definition of FP, it definitely makes sense to leave Ruby behind. 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. 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 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. Another cool thing about Clojure is that because both Clojure and Ruby run on the JVM, you can combine them. 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. 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# 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人去斯卡拉，C＃转到F＃，那么Ruby的人们会去哪里实现功能性涅？？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！ bar 方法的 foo 对象。在Ruby中， foo.bar 是一个方法 call ，如果我想引用栏 foo 的方法，我必须说 baz = foo.method（：bar）。如果我现在想调用那个方法，我不能说 baz（），我必须说 baz。调用或 baz [] 或（在Ruby 1.9中） baz。（） / p>
Enumerator 之前，懒惰也不容易实现。还有一些东西可以在严格 Enumerable s或 Array s但与懒惰枚举 s，但实际上没有理由要求严格。
Proc.new, proc, lambda, Method, UnboundMethod, blocks, #to_proc and ->() (and probably some others that I forget).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.().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.
