Quali sono le maggiori differenze tra F # e Scala?

F # e Scala sono entrambi linguaggi di programmazione funzionale che non obbligano lo sviluppatore a utilizzare solo tipi di dati immutabili. Entrambi hanno il supporto per gli oggetti, possono usare librerie scritte in altre lingue ed eseguire su una macchina virtuale. Entrambe le lingue sembrano basate su ML.

Quali sono le maggiori differenze tra F # e Scala nonostante il fatto che F # sia progettato per .NET e Scala per la piattaforma Java?

— Jonas
fonte

Se puoi votare e pensare che questa sia una domanda utile o abbia delle risposte utili di seguito, vota per favore. I siti StackExchange hanno bisogno di voti per costruire una buona comunità. Puoi dare 30 voti al giorno, non sprecarli. Specialmente gli utenti con alta reputazione e basso numero di voti assegnati, per favore leggi questo: meta.programmers.stackexchange.com/questions/393/…

— Maniero

functional programming langugages that don't force the developer to only use immutable datatypes- ce ne sono, tranne forse le lingue dei giocattoli?

— Ingo,

@Ingo, se pensi che ML e Ocaml non si qualifichino come linguaggi di programmazione funzionali perché consentono la mutabilità, forse dovresti modificare la tua definizione!

— Frank Shearar,

+ Frank, devi aver frainteso: voglio dire, anche Haskell ha tipi di dati mutabili. Quindi, mi piacerebbe ancora sapere quali lingue @Jonas ha forse in mente e che potrebbero costringere a usare solo tipi di dati immutabili?

— Ingo,

Risposte:

Differenze principali:

Sia Scala che F # combinano la programmazione imperativa OO e la programmazione funzionale in una lingua. Il loro approccio all'unificazione dei paradigmi è tuttavia molto diverso. Scala cerca di fondere i due paradigmi in uno (lo chiamiamo paradigma oggetto-funzionale), mentre F # fornisce i due paradigmi fianco a fianco. Ad esempio, i tipi di dati algebrici in F # sono costrutti puramente funzionali senza OO'ness in essi mentre gli ADT in Scala sono ancora classi e oggetti regolari. (Nota: nel processo di compilazione in bytecode CLR, anche gli ADT F # diventano classi e oggetti ma non sono visibili al programmatore F # a livello di sorgente.)
F # ha un'inferenza completa del tipo di stile Hindley-Milner. Scala ha un'inferenza di tipo parziale. Il supporto per il sottotipo e il puro OO rende impossibile l'inferenza di tipo Hindley-Milner per Scala.
Scala è un linguaggio molto più minimalista di F #. Scala ha un piccolo insieme ortogonale di costrutti che vengono riutilizzati in tutto il linguaggio. F # sembra introdurre una nuova sintassi per ogni piccola cosa, diventando così molto sintassi pesante rispetto a Scala. (Scala ha 40 parole chiave, mentre F # ha 97. Questo dovrebbe dirti qualcosa. :-)
F # essendo un linguaggio Microsoft ha un eccellente supporto IDE sotto forma di Visual Studio. Le cose non vanno così bene dal lato della Scala. Il plugin Eclipse non è ancora all'altezza. Lo stesso vale per il plugin NetBeans. IDEA sembra essere la tua scommessa migliore al momento, anche se non si avvicina nemmeno a ciò che ottieni con gli IDE Java. (Per i fan di Emacs, c'è ENSIME. Ho sentito molte cose positive su questo pacchetto, ma non l'ho ancora provato.)
Scala ha un sistema di tipo molto più potente (e complesso) di F #.

Altre differenze:

Le funzioni F # sono predefinite. A Scala, il curry è disponibile ma non usato molto spesso.
La sintassi di Scala è un mix di quella di Java, Standard ML, Haskell, Erlang e molte altre lingue. La sintassi F # è ispirata a quelle di OCaml, C # e Haskell.
Scala supporta tipi e tipi di caratteri più alti. F # no.
Scala è molto più sensibile ai DSL che a F #.

PS: Adoro sia Scala che F #, e spero che in futuro diventino lingue predominanti delle rispettive piattaforme. :-)

— missingfaktor
fonte

Questa risposta perpetua diverse idee sbagliate. Li enumererò a turno. Hai detto "i tipi di dati algebrici in F # sono costrutti puramente funzionali senza nessuna OO'ness in essi", ma i tipi di dati algebrici in F # sono solo classe e, in particolare, supportano l'aumento con istanze OO / membri e proprietà statici.

— Jon Harrop,

Dici "Scala cerca di fondere i due paradigmi in uno (lo chiamiamo paradigma oggetto-funzionale)" ma Scala manca dell'eliminazione generale della chiamata di coda e, di conseguenza, di qualsiasi codice funzionale non banale (compresi quasi tutti i linguaggi funzionali convenzionali come il passaggio di continuazione lo stile e lo scioglimento del nodo ricorsivo) sono inclini a sovrapporsi in Scala e, quindi, sono praticamente inutili.

— Jon Harrop,

@JonHarrop: Scala non tratta in particolare gli ADT. Sono trattati proprio come le lezioni regolari. Quindi Some(2)in Scala ha tipo Some[Int]e non Option[Int]è ciò che è indesiderabile IMO. F # d'altra parte ha una sintassi e un trattamento speciali per gli ADT e può quindi dedurre correttamente il tipo di Some 2as int option. Quindi la codifica F # degli ADT è migliore di quella di Scala (IMO, ovviamente). Non ho cercato di insinuare che è inferiore, e mi dispiace se si è imbattuto in quel modo.

— missingfaktor,

@JonHarrop: la mancanza di TCO in JVM non ha disturbato molti sviluppatori Scala. Fidati di me, non è un problema così grande come sembra pensare. Il più delle volte, stiamo usando funzioni di ordine superiore, anziché ricorsione esplicita. E la maggior parte delle funzioni di ordine superiore in Scala sono implementate in termini di loop e non di ricorsione. Quindi, la mancanza di TCO diventa quasi irrilevante.

— missingfaktor,

Penso che tutta questa risposta sia un po 'distorta nei confronti di Scala. Ad esempio Scala è un linguaggio molto più minimalista di F # che sembra andare contro il suo argomento / punto successivo di un sistema di tipo più complesso.

— Adam Gent,

F # si basa su aspetti funzionali mentre scala si basa su aspetti orientati agli oggetti.
F # ha un supporto IDE migliore con Visual Studio mentre il plug-in eclipse di Scala è per IDE open source e relativamente più lento.
F #, essendo più simile a ML rispetto a Scala, ha più di un minimo lambda calcolo come lo sono OCaml, Standard ML e Scheme. F # sembra essere un linguaggio notevolmente più semplice.

— Ayush Goyal
fonte

"F # sembra essere un linguaggio notevolmente più semplice." << No, non lo è. È molto più grande della Scala. Dovrei scrivere un articolo su questo argomento qualche volta.

— missingfaktor il

"Scala si basa su aspetti orientati agli oggetti." << Sbagliato. Scala cerca di fondere la programmazione funzionale OOP AND. Personalmente uso molto raramente le sue funzionalità orientate agli oggetti. Gran parte di ciò che facciamo è puramente funzionale.

— missingfaktor il

@missingfaktor: "È molto più grande della Scala". Quanto sono grandi le grammatiche?

— Jon Harrop,

Non so se le cose sono cambiate. Scala in IntelliJ è rock, con il plugin ancora open source.

— Colliot,

Un punto piccolo ma importante è la licenza: Scala è BSD (praticamente la licenza di software libero più permissiva che esista), F # era un "accordo di licenza di Microsoft Research Shared Source" ma al giorno d'oggi è un prodotto commerciale (secondo @Lorenzo di seguito, sebbene non sia stato possibile trovare accordi di licenza più specifici da nessuna parte).

— Joonas Pulakka
fonte

In realtà, F # è ora open source e Scala è ora un prodotto commerciale della società Scala O di Martin Odersky.

— Jon Harrop,

@Jon Harrop: penso che Scala Solutions stia vendendo solo strumenti, servizi, formazione legati alla Scala, ecc. Il linguaggio stesso sembra ancora essere sotto licenza BSD.

— Joonas Pulakka,

@Joonas: Esatto, lo stesso vale per F #.

— Jon Harrop,

@JonHarrop: Scala rimane open source. Si prega di non diffondere disinformazione.

— missingfaktor

@missingfaktor: non ho detto che Scala fosse chiusa.

— Jon Harrop,