Il y a deux très différentes définitions de la notion de "programmation fonctionnelle" signifie. Vous pouvez sorte de faire la une en Ruby, mais vous ne pouvez pas faire les autres.
Ces deux définitions sont les suivantes:
- programmation avec la première classe des fonctions et
- programmation avec des fonctions mathématiques
Vous pouvez sorte de programme avec des fonctions en Ruby. Il a le soutien de première classe de fonctions. En fait, il a trop de soutien pour eux: il est Proc.new, proc, lambda, Method, UnboundMethod, blocs, #to_proc et ->() (et probablement d'autres que j'oublie).
L'ensemble de ces se comportent un peu différemment, ont une syntaxe légèrement différente, un comportement légèrement différent et légèrement différentes restrictions. Par exemple: une seule de ces qui est syntaxiquement suffisamment léger que vous pouvez réellement utiliser dense, est bloque. Mais les blocs sont assez sévères restrictions: vous ne pouvez passer d'un bloc à une méthode, les blocs ne sont pas des objets (ce qui, dans un langage orienté-objet dans lequel "tout est objet" est un très sévère restriction) et au moins en Ruby 1.8 il existe également des restrictions w.r.t paramètres.
Se référant à une méthode est une autre chose qui est assez maladroit. En Python ou ECMAScript par exemple, je peux juste dire baz = foo.bar pour se référer à l' bar méthode de foo objet. En Ruby, foo.bar est une méthode d'appel, si je veux me référer à l' bar méthode de foo, je dois dire baz = foo.method(:bar). Et si je veux maintenant pour appeler cette méthode, je ne peux pas juste dire baz(), je dois dire baz.call ou baz[] (ou Ruby 1.9) baz.().
Alors, de première classe de fonctions en Ruby ne sont pas vraiment de première classe. Ils sont beaucoup mieux que de seconde classe, et ils sont assez bons™, mais ils ne sont pas pleinement de première classe.
Mais généralement, Rubyists ne pas laisser de Ruby juste pour la première classe de fonctions. Ruby est assez bon que tous les avantages que vous pouvez acquérir à partir d'un meilleur soutien dans une autre langue est habituellement consommés par l'effort de formation pour la nouvelle langue ou par quelque chose d'autre que vous se sont habitués à que vous devez abandonner. Comme, disons RubyGems ou serré Unix intégration ou Ruby on Rails ou de syntaxe ou de ...
Cependant, la deuxième définition de la PF est où Ruby tombe à plat sur son visage. Si vous voulez faire de la programmation avec des fonctions mathématiques en Ruby, vous êtes dans un monde de douleur. Vous ne pouvez pas utiliser la majorité absolue des bibliothèques Ruby, parce que la plupart d'entre eux sont dynamiques, effectful, d'encourager la mutation ou qui sont impurs. Vous ne pouvez pas utiliser la bibliothèque standard pour les mêmes raisons. Vous ne pouvez pas utiliser la bibliothèque de base. Vous ne pouvez pas utiliser un des principaux types de données, car ils sont tous mutable. Vous pouvez simplement dire "je n'aime pas qu'ils sont mutables, je vais tout simplement pas muter et toujours copier", mais le problème est: quelqu'un d'autre encore peut muter eux. Aussi, parce qu'ils sont mutables, Ruby ne peut pas optimiser le copier et le garbage collector n'est pas réglé pour le type de charge de travail.
Il ne fonctionne tout simplement pas.
Il ya aussi un couple de caractéristiques qui en ont vraiment rien à voir avec de la programmation fonctionnelle, mais que la plupart des langages fonctionnels ont tendance à avoir, que Ruby est manquant. La correspondance de modèle, par exemple. La paresse n'était pas aussi facile à réaliser avant d' Enumerators ont été plus agressive utilisé dans Ruby 1.9. Et il y a encore quelques trucs qui fonctionne avec le strict Enumerables ou Arrays, mais pas avec lazy Enumerators, bien qu'il n'y a vraiment aucune raison pour eux d' exiger de la rigueur.
Et pour cette définition de la FP, il fait vraiment bon sens de laisser Ruby derrière.
Les deux principales langues que Rubyists ont afflué à, sont Erlang et Clojure. Ce sont à la fois relativement bons matchs pour Ruby, parce qu'ils sont à la fois dynamiquement typé, ont un semblable REPL la culture comme Ruby, et (ce n'est plus un Rails chose que le Rubis chose) sont également de très bonne sur le web. Ils ont encore assez petit et les communautés d'accueil, la langue d'origine des créateurs sont toujours actifs dans la communauté, il ya un fort accent sur le faire de nouveau, excitant et edgy de choses, qui sont des traits que la communauté Ruby a aussi.
L'intérêt en Erlang a commencé, quand quelqu'un a montré l'original de 1993, l'introduction de la vidéo "Erlang: Le Film" à RubyConf 2006. Un couple de haut-profil des Rails de projets qui ont démarré à l'aide de Erlang, par exemple PowerSet et GitHub. Erlang est aussi facile à maîtriser pour Rubyists, car elle ne prend pas la pureté tout à fait aussi loin que Haskell ou Nettoyer. L' intérieur d'un acteur est assez pur, mais la loi de l'envoi de messages en lui-même est bien sûr un effet secondaire. Une autre chose qui rend Erlang facile à saisir, c'est que les Acteurs et les Objets sont en fait la même chose, lorsque vous suivez Alan Kay définition de la programmation orientée objet.
Clojure a été un ajout récent à la Rubyist de toolbelt. Sa popularité est je crois surtout alimentée par le fait que la communauté Ruby a enfin réchauffé à l'idée que la JVM ≠ Java et l'embrassa JRuby et puis ils ont commencé à regarder autour de ce que d'autres choses intéressantes, il y avait sur la JVM. Et encore une fois, Clojure est beaucoup plus pragmatique que les deux autres langages fonctionnels comme Haskell et d'autres Lisps comme Régime et beaucoup plus simple et plus moderne que CommonLisp, c'est donc un choix naturel pour la Rubyists.
Une autre chose cool à propos de Clojure est que parce que les deux Clojure et Ruby s'exécuter sur la machine, vous pouvez combiner entre eux.
L'auteur de "Programmation Clojure" (Stuart Halloway) est un (ancien?) Rubyist, par exemple, comme c'est Phil Hagelberg, l'auteur de la Leiningen outil de construction de Clojure.
Cependant, Rubyists sont également à la recherche à la fois Scala (comme l'un des plus pragmatique statiquement typé FP langues) et Haskell (comme l'une des plus élégantes de ceux). Puis il y a des projets comme Scuby et l'Arrogance qui sont des ponts qui vous permettent d'intégrer des Rubis avec Scala, Haskell, respectivement. Twitter la décision de déplacer une partie de leur faible niveau de l'infrastructure de messagerie d'abord à partir de MySQL Ruby, puis à partir de Ruby, Scala est également assez largement connus.
F# ne semble pas jouer de rôle à tous, peut-être due à une peur irrationnelle à l'égard de tous les choses Microsoft la communauté Ruby a. (Qui, d'ailleurs, semble souvent sans fondement, étant donné que l'équipe F# a toujours fait des versions disponibles pour Mono.)
