Was sind die größten Unterschiede zwischen F # und Scala?


59

F # und Scala sind beide funktionale Programmiersprachen, die den Entwickler nicht zwingen, nur unveränderliche Datentypen zu verwenden. Beide unterstützen Objekte, können in anderen Sprachen geschriebene Bibliotheken verwenden und auf einer virtuellen Maschine ausgeführt werden. Beide Sprachen scheinen auf ML zu basieren.

Was sind die größten Unterschiede zwischen F # und Scala, obwohl F # für .NET und Scala für die Java-Plattform entwickelt wurde?


2
Wenn Sie abstimmen können und denken, dass dies eine nützliche Frage ist, oder wenn Sie unten nützliche Antworten haben, stimmen Sie ab. StackExchange-Sites benötigen Stimmen, um eine gute Community aufzubauen. Sie können 30 Stimmen pro Tag abgeben, verschwenden Sie sie nicht. Speziell Anwender mit hohem Ansehen und niedriger Auszählung der Stimmen gegeben lesen Sie bitte: meta.programmers.stackexchange.com/questions/393/...
Maniero

functional programming langugages that don't force the developer to only use immutable datatypes- Gibt es welche, außer vielleicht Spielzeugsprachen?
Ingo

1
@Ingo, wenn Sie der Meinung sind, dass ML und Ocaml nicht als funktionale Programmiersprachen gelten, weil sie die Veränderbarkeit zulassen, sollten Sie möglicherweise Ihre Definition anpassen!
Frank Shearar

3
+ Frank, du musst falsch verstanden haben: Ich meine, sogar Haskell hat veränderbare Datentypen. Daher würde ich immer noch gerne wissen, in welchen Sprachen @Jonas möglicherweise nur unveränderliche Datentypen verwendet?
Ingo

Antworten:


61

Hauptunterschiede:

  • Sowohl Scala als auch F # kombinieren OO-imperative Programmierung und funktionale Programmierung in einer Sprache. Ihr Ansatz zur Vereinheitlichung der Paradigmen ist jedoch sehr unterschiedlich. Scala versucht, die beiden Paradigmen zu einem (wir nennen es objektfunktionales Paradigma) zu verschmelzen , während F # die beiden Paradigmen nebeneinander liefert. Beispielsweise sind algebraische Datentypen in F # rein funktionale Konstrukte ohne OO'ness, während ADTs in Scala weiterhin reguläre Klassen und Objekte sind. (Hinweis: Beim Kompilieren in den CLR-Bytecode werden selbst F # -ADTs zu Klassen und Objekten, sie sind jedoch für F # -Programmierer auf Quellenebene nicht sichtbar.)

  • F # hat eine vollständige Inferenz nach Hindley-Milner. Scala hat teilweise Typinferenz. Die Unterstützung von Subtyping und Pure-OO-Ness macht einen Rückschluss auf den Hindley-Milner-Typ für Scala unmöglich.

  • Scala ist eine viel minimalistischere Sprache als F #. Scala hat eine sehr kleine orthogonale Menge von Konstrukten, die in der gesamten Sprache wiederverwendet werden. F # scheint für jede Kleinigkeit eine neue Syntax einzuführen, wodurch es im Vergleich zu Scala sehr syntaxlastig wird. (Scala hat 40 Stichwörter, während F # 97 hat. Das sollte dir etwas sagen. :-)

  • F # als Microsoft-Sprache bietet eine hervorragende IDE-Unterstützung in Form von Visual Studio. Auf der Scala geht es nicht so gut. Das Eclipse-Plugin ist immer noch nicht auf dem neuesten Stand. Gleiches gilt für das NetBeans-Plugin. IDEA scheint im Moment die beste Wahl zu sein, obwohl es nicht annähernd das ist, was Sie mit Java IDEs erreichen. (Für Emacs-Fans gibt es ENSIME. Ich habe viele gute Dinge über dieses Paket gehört, aber ich habe es noch nicht ausprobiert.)

  • Scala hat ein weitaus leistungsstärkeres (und komplexeres) Typensystem als F #.


Andere Unterschiede:

  • F # -Funktionen werden standardmäßig ausgeführt. In Scala wird Curry angeboten, aber nicht sehr oft verwendet.

  • Die Syntax von Scala ist eine Mischung aus Java, Standard ML, Haskell, Erlang und vielen anderen Sprachen. Die Syntax von F # ist von der von OCaml, C # und Haskell inspiriert.

  • Scala unterstützt höhere Arten und Typklassen. F # nicht.

  • Scala ist für DSLs viel zugänglicher als für F #.


PS: Ich liebe sowohl Scala als auch F # und hoffe, dass sie in Zukunft die vorherrschenden Sprachen ihrer jeweiligen Plattformen werden. :-)


6
Diese Antwort verewigt mehrere Missverständnisse. Ich werde sie der Reihe nach aufzählen. Sie sagten, "algebraische Datentypen in F # sind rein funktionale Konstrukte ohne OO'ness", aber algebraische Datentypen in F # sind nur Klassen und unterstützen insbesondere die Erweiterung mit OO-Instanz / statischen Elementen und Eigenschaften.
Jon Harrop

7
Sie sagen, "Scala versucht, die beiden Paradigmen zu einem (wir nennen es objektfunktionales Paradigma) zu verschmelzen", aber Scala fehlt die allgemeine Eliminierung von Tail Calls und folglich jeglicher nicht-trivialer Funktionscode (einschließlich fast aller konventionellen funktionalen Redewendungen wie Continuation Passing) Stil und das Auflösen des rekursiven Knotens sind in Scala anfällig für Stapelüberläufe und daher praktisch nutzlos.
Jon Harrop

4
@ JonHarrop: Scala behandelt ADTs nicht speziell. Sie werden wie reguläre Klassen behandelt. Davon abgesehen hat Some(2)Scala in der Art Some[Int]und nicht Option[Int]die unerwünschte IMO. F # hingegen hat eine spezielle Syntax und Behandlung für ADTs und kann daher den Typ von Some 2as korrekt ableiten int option. Daher ist die F # -Codierung von ADTs besser als die von Scala (IMO natürlich). Ich habe nicht angedeutet, dass es minderwertig ist, und es tut mir leid, wenn es so rüberkam.
Fehlender Faktor

9
@ JonHarrop: Der Mangel an TCO in JVM hat nicht viele Scala-Entwickler gestört. Vertrauen Sie mir, es ist kein so großes Problem, wie Sie zu denken scheinen. In den meisten Fällen verwenden wir Funktionen höherer Ordnung anstelle einer expliziten Rekursion. Die meisten Funktionen höherer Ordnung in Scala werden in Form von Schleifen und nicht in Form von Rekursionen implementiert. Der Mangel an Gesamtbetriebskosten wird somit nahezu unerheblich.
Fehlender Faktor

8
Ich glaube, diese ganze Antwort ist etwas voreingenommen gegenüber Scala. Zum Beispiel ist Scala eine viel minimalistischere Sprache als F #, was seinem Argument / späteren Standpunkt eines komplexeren Typsystems zu widersprechen scheint.
Adam Gent

9
  • F # basiert auf funktionalen Aspekten, während Scala auf objektorientierten Aspekten basiert.
  • F # bietet mit Visual Studio eine bessere IDE-Unterstützung, während das Eclipse-Plug-in von Scala für Open-Source-IDEs gedacht und vergleichsweise langsamer ist.
  • F # ist ML-ähnlicher als Scala und hat ein eher minimales Lambda-Gefühl wie OCaml, Standard ML und Scheme. F # scheint eine wesentlich einfachere Sprache zu sein.

4
"F # scheint eine wesentlich einfachere Sprache zu sein." << Nein, das ist es nicht. Es ist viel größer als Scala. Ich sollte irgendwann einen Artikel zu diesem Thema schreiben.
Fehlender Faktor

4
"Scala basiert auf objektorientierten Aspekten." << Falsch. Scala versucht, OOP UND funktionale Programmierung zu verschmelzen. Ich persönlich verwende seine objektorientierten Funktionen sehr selten. Das meiste, was wir tun, ist rein funktional.
Fehlender Faktor

@missingfaktor: "Es ist viel größer als Scala". Wie groß sind die Grammatiken?
Jon Harrop

1
Ich weiß nicht, ob sich die Dinge geändert haben. Scala in IntelliJ rockt, das Plugin ist immer noch Open Source.
Colliot

0

Ein kleiner, aber wichtiger Punkt ist die Lizenz: Scala ist BSD (so ziemlich die freizügigste freie Softwarelizenz, die es gibt), F # war früher "Microsoft Research Shared Source-Lizenzvereinbarung", ist aber heute ein kommerzielles Produkt (laut @Lorenzo unten). obwohl ich nirgendwo spezifischere Lizenzvereinbarungen finden konnte).


3
Tatsächlich ist F # jetzt Open Source und Scala ist jetzt ein kommerzielles Produkt von Martin Oderskys Firma Scala Solutions.
Jon Harrop

4
@ Jon Harrop: Ich denke, Scala Solutions verkauft nur Scala-bezogene Tools, Services, Schulungen usw. Die Sprache selbst scheint immer noch unter der BSD-Lizenz zu stehen.
Joonas Pulakka

2
@Joonas: Genau das gleiche gilt für F #.
Jon Harrop

5
@ JonHarrop: Scala bleibt Open Source. Bitte verbreiten Sie keine Fehlinformationen.
Fehlender Faktor

2
@missingfaktor: Ich habe nicht gesagt, dass Scala Closed Source ist.
Jon Harrop
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.