Se gli utenti Java vanno a Scala, C# vanno a F#, dove vanno gli utenti Ruby per il nirvana funzionale?[Chiuso]

Question

So che molte persone Java hanno iniziato a guardare Scala da quando funziona su JVM, e molte persone nel mondo Microsoft guardano F#, ma cosa ha Ruby come naturale successore funzionale?

In senso puro FP a Ruby non manca nulla, anzi ha troppo, direbbe qualcuno.Un linguaggio funzionale costringe il programmatore a non utilizzare così tanto variabili globali e altri idiomi (sebbene sia possibile utilizzare i globali nei linguaggi funzionali)

Answer 1

Ce ne sono due molto diverse definizioni di cosa significhi "programmazione funzionale".Puoi fare una cosa in Ruby, ma non puoi fare l'altra.

Queste due definizioni sono:

• programmazione con funzioni di prima classe e
• programmazione con funzioni matematiche

Puoi programmare con funzioni di prima classe in Ruby.Ha il supporto per funzioni di prima classe.In effetti, lo ha fatto troppo supporto per loro:c'è Proc.new, proc, lambda, Method, UnboundMethod, blocchi, #to_proc E ->() (e probabilmente alcuni altri che dimentico).

Tutti questi comportarsi in modo leggermente diverso, hanno una sintassi leggermente diversa, un comportamento leggermente diverso e restrizioni leggermente diverse.Per esempio:l'unico di questi che è sintatticamente abbastanza leggero da poterlo effettivamente utilizzare densamente, sono i blocchi.Ma i blocchi hanno alcune restrizioni piuttosto severe:puoi passare solo un blocco a un metodo, i blocchi non sono oggetti (che in un linguaggio orientato agli oggetti in cui "tutto è un oggetto" è un molto restrizione severa) e almeno in Ruby 1.8 ci sono anche alcune restrizioni rispetto ai parametri.

Fare riferimento a un metodo è un'altra cosa abbastanza imbarazzante.In Pitone O ECMAScript per esempio, posso solo dire baz = foo.bar fare riferimento a bar metodo del foo oggetto.In Rubino, foo.bar è un metodo chiamata, se voglio fare riferimento al bar metodo di foo, Devo dire baz = foo.method(:bar).E se ora lo voglio chiamata quel metodo, non posso semplicemente dirlo baz(), Devo dire baz.call O baz[] o (in Ruby 1.9) baz.().

Quindi, le funzioni di prima classe in Ruby non lo sono Veramente prima classe.Sono molto meglio della seconda classe, e lo sono abbastanza buono™, ma non sono del tutto di prima classe.

Ma in generale, i Rubyisti non lasciano Ruby solo per funzioni di prima classe.Il supporto di Ruby è abbastanza buono che qualsiasi vantaggio che potresti ottenere da un migliore supporto in un'altra lingua di solito viene divorato dallo sforzo di formazione per la nuova lingua o da qualcosa altro a cui sei abituato, a cui ora devi rinunciare.Ad esempio, RubyGems o la stretta integrazione Unix o Ruby on Rails o la sintassi o...

comunque, il secondo la definizione di FP è dove Ruby cade a faccia in giù.Se vuoi programmare con funzioni matematiche in Ruby, ti troverai in un mondo di dolori.Non è possibile utilizzare la maggioranza assoluta delle librerie Ruby, perché la maggior parte di esse sono stateful, efficaci, incoraggiano la mutazione o sono altrimenti impure.Non è possibile utilizzare la libreria standard per gli stessi motivi.Non è possibile utilizzare la libreria principale.Non è possibile utilizzare nessuno dei tipi di dati principali perché sono tutti modificabili.Potresti semplicemente dire "Non mi interessa che siano mutabili, semplicemente non li muterò e li copierò sempre", ma il problema è:qualcun altro può ancora mutarli.Inoltre, poiché sono modificabili, Ruby non può ottimizzare la copia e il garbage collector non è ottimizzato per quel tipo di carico di lavoro.

Semplicemente non funziona.

Ci sono anche un paio di funzionalità che non hanno davvero nulla a che fare con la programmazione funzionale ma che la maggior parte dei linguaggi funzionali tendono ad avere, e che a Ruby mancano.Corrispondenza di modelli, per esempio.Anche la pigrizia non era così facile da raggiungere prima Enumerators sono stati utilizzati in modo più aggressivo in Ruby 1.9.E ci sono ancora alcune cose che funzionano con strict Enumerables o Arrays ma non con pigro Enumerators, anche se in realtà non c'è motivo per cui lo facciano richiedere rigore.

E per Questo definizione di FP, ha sicuramente senso lasciare Ruby indietro.

Le due lingue principali a cui si stanno riversando i Rubyisti sono Erlang E Clojure.Queste sono entrambe corrispondenze relativamente buone per Ruby, perché sono entrambe tipizzate dinamicamente, hanno una cultura REPL simile a Ruby e (questa è più una cosa di Rails che di Ruby) sono anche molto buone sul web.Hanno ancora comunità piuttosto piccole e accoglienti, i creatori del linguaggio originale sono ancora attivi nella comunità, c'è una forte attenzione nel fare cose nuove, eccitanti e innovative, tutte caratteristiche che anche la comunità Ruby possiede.

L'interesse per Erlang è iniziato quando qualcuno ha mostrato il video introduttivo originale del 1993 "Erlang:Il film"al RubyConf 2006.Ad esempio, un paio di progetti Rails di alto profilo hanno iniziato a utilizzare Erlang PowerSet E GitHub.Erlang è anche facile da padroneggiare per i Rubyisti, perché non richiede purezza così lontana Haskell O Pulito.IL dentro di un attore è piuttosto puro, ma l'atto stesso di inviare messaggi è ovviamente un effetto collaterale.Un'altra cosa che rende Erlang facile da comprendere è che attori e oggetti sono in realtà la stessa cosa, quando segui La definizione di programmazione orientata agli oggetti di Alan Kay.

Clojure è stata una recente aggiunta alla cintura degli strumenti del Rubyist.Immagino che la sua popolarità sia principalmente guidata dal fatto che la comunità Ruby si è finalmente riscaldata all'idea che JVM ≠ Java e ha abbracciato JRuby e poi hanno iniziato a guardarsi intorno altro cose interessanti c'erano sulla JVM.E ancora, Clojure è molto più pragmatico di entrambi gli altri linguaggi funzionali come Haskell e altri Lisps schema e molto più semplice e moderno di CommonLisp, quindi è una scelta naturale per i Rubyisti.

Un'altra cosa interessante di Clojure è che, poiché sia ​​Clojure che Ruby funzionano sulla JVM, puoi farlo combinare loro.

L'autore di "Clojure di programmazione" (Stuart Halloway) è un (ex?) Rubyista, per esempio, così com'è Phil Hagelberg, l'autore del Leiningen strumento di creazione per Clojure.

Tuttavia, anche i Rubyisti stanno guardando entrambi Scala (come uno dei linguaggi FP tipizzati staticamente più pragmatici) e Haskell (come uno di quelli più eleganti).Poi ci sono progetti come Scuby E Hybris che sono bridge che ti consentono di integrare Ruby rispettivamente con Scala e Haskell.Anche la decisione di Twitter di spostare parte della propria infrastruttura di messaggistica di basso livello prima da MySQL a Ruby, poi da Ruby a Scala è piuttosto nota.

F# non sembra avere alcun ruolo, forse a causa di una paura irrazionale nei confronti di tutto ciò che la comunità Ruby ha di Microsoft.(Il che, a proposito, sembra per lo più infondato, dato che il team F# ha Sempre reso disponibili le versioni per Mono.)

Answer 2

persone Java utilizza una lingua sulla JVM e vogliono un più funzionale uno compatibile con la loro esecuzione, in modo da andare a Scala.

C # persone stanno usando un linguaggio il CLR e vogliono un più funzionale uno compatibile con la loro esecuzione, in modo da andare a F #.

rubino gente sta usando un linguaggio che è già abbastanza funzionale, e stanno usando su un certo numero di tempi di esecuzione sottostanti (JRuby, IronRuby, MRI, MacRuby, Rubinius, ecc ...). Io non penso che abbia un successore funzionali naturali, o anche bisogno di uno.

Answer 3

Qualsiasi versione di Lisp dovrebbe andare bene.

Answer 4

Rubino è di per sé una sorta di linguaggio di programmazione funzionale, quindi non vedo alcun dialetti speciali per i FP usando rubino.

Answer 5

Nel livello di hype, Haskell.

Answer 6

Supponendo che la gente di Ruby non basta andare alla JVM se stessi, penso che la maggior parte sarebbe adottare Erlang, essere un altro linguaggio tipizzato in modo dinamico.

Answer 7

Rubino non è funzionale come dire Lisp, ma è sufficiente solo funzionale che si può fare un po 'di programmazione funzionale in un buon modo divertente. (A differenza cercando di fare programmazione funzionale in qualcosa di simile a C #)

Inoltre, in realtà ti costringe in paradigmi funzionali in alcune delle sua sintassi, come ad esempio l'uso pesante di blocchi e rendimento. (Che mi sono innamorato dopo aver appreso Ruby).