Ich habe ein Buch über F #, aber im Moment bin ich ziemlich uninformiert, also dachte ich, ich würde fragen. Von sehr wenig weiß ich von F #, ich kämpfe um zu sehen, was es mir über C # Bar eine mögliche syntaktische Ordentlichkeit bringt. Es scheint nichts konzeptionell Neues, oder das ist nicht möglich in Piian C #
Ich bin früher (vor 20 Jahren fast) zurückgegangen, und ich habe schon Delegierte von Passing-Funktionen als Parameter in Methoden integriert (es scheint so).
Stilistisch bin ich nicht scharf auf anonyme Methoden - wird das ein Problem sein?
Obwohl ich denke, syntaktische Ordentlichkeit ist nicht an zu schnüffeln: -)
(Achtung: Dieses erste Bit ist nicht wirklich eine Antwort auf Ihre Frage. Und ich bin sehr voreingenommen, als Mitglied des F # -Teams.) Ich benutze F # seit fast einem Jahr und finde es immer, wenn es sein muss Schreibe C # -Code, es fühlt sich an wie durch Schlamm zu laufen. Es gibt so viele Curlies und Semikolons, und oh-mein-Gott-quit-mach-mich-schreibe-all-die-darn-Typen! Es fühlt sich einfach langsam an. Ich arbeite mit viel C # -Code und deshalb lese und debugge ich es fast täglich, und es ist in Ordnung (sogar besser als F # für das Debugging; wir müssen noch die F # Debugger-Integration ein wenig verbessern), aber ich habe das gefunden em> Schreiben C # -Code fühlt sich jetzt an wie eine lästige Pflicht; F # ist nur viel mehr Spaß zum code.
Was die tatsächlichen Antworten auf Ihre Fragen betrifft, sagen viele Leute "Tupel", aber ich sage "Meh" dazu. Typinferenz, diskriminierte Vereinigungen und Mustervergleiche, eine funktionale Bibliothek, Pipelining und syntaktische Ordentlichkeit (Syntaxangelegenheiten!) Sind größere Gewinner für mich. (Und wenn Sie heute asynchronen Code schreiben möchten, bläst F # die Türen von allen anderen.)Ich mag sowohl F # als auch C #, aber generell bevorzuge ich F #:
Ich würde sagen, wenn Sie versuchen und unveränderliche Programmierung in C # Sie bald auf das Problem stoßen, dass Sie nicht mehr als eine Sache aus einer Methode / Funktion zurückgeben können. F # löst sauber mit Tupeln, damit Sie mehr als einen Wert zurückgeben können.
Ein weiteres Problem mit Delegaten in C # ist, dass sie nominal sind. Sie können zwei Delegierte mit genau der gleichen Signatur haben, aber sie sind nicht kompatibel, nur weil sie unterschiedliche Namen haben. Sie können Lambdas oder anonyme Delegaten verwenden, um dieses Problem zu umgehen, aber F # löst auf eine sauberere Weise: es überprüft nur, ob die Signaturen übereinstimmen.
Union-Typen sind großartig und es ist schwer zu sehen, dass C # genau diese Funktionalität bietet.
Zusätzlich zu den anderen Antworten: Automatische Generalisierung.
Dies gibt F # einen großen Schritt gegenüber C #, Scala usw. Hier ist ein triviales Beispiel, die "snd" -Funktion, um den zweiten Wert eines Paares zu erhalten. In F #:
%Vor%Der Compiler erkennt die Dinge automatisch und macht sie vollständig generisch:
%Vor%In C #:
%Vor%1/3 der Code, 100% weniger Rauschen. Erweitern Sie das nun zu komplexeren Funktionstypen, sagen wir, etwas, das ein Tupel nimmt, und ein Lexikon einer Enumeration zu einer Funktion zurückbringt. Autsch.
Und das sind einfache Szenarien. Fügen Sie einige generische Constraints, Beziehungen zwischen Typparametern hinzu, und nun, in C # wird es wirklich schwierig. Ein paar Mal mit C # musste ich wirklich aufhören, nachdenken und berechnen, welche generischen Parameter ich brauche, , auch wenn es keine schwierige Anwendung ist . In F # kann ich die Idee kodieren, und generell werden die Dinge so weit wie möglich verallgemeinert, ohne dass ich weiterarbeiten muss. Schön.
Ein weiterer großer Vorteil ist das vollständige Inferenzsystem. Lokale Funktionen, Lambdas, Tupel und Listen reduzieren den Code sehr.
Ich denke, einer der großen Vorteile von F # ist die bessere Unterstützung von Tupeln.
Ja, in diesem Moment der Zeit sind die Vorteile "nur" Mustererkennung, Unveränderbarkeit standardmäßig, einfachere (aber weniger vertraute) Syntax und ziemlich gute Typschlussfolgerung.
Die beiden großen für mich (ohne Typinferenz) sind eine viel nettere monadische Syntax (Berechnungsausdrücke in F # gegen LINQ-Abfragen in C #) und Zitate (gegen LINQ-Ausdrücke).
Ich muss sagen, dass Async und Parallelität in F # beeindruckend sind ... beeindruckend. Schauen Sie sich dieses Video von PDC an .
Ich finde es ziemlich schwierig, die Vorteile auf eine einfache Art darzustellen. Meine Überzeugung ist, dass die Vorteile nicht in einigen Sprachfunktionen sind (sei es Unveränderlichkeit standardmäßig, Typ Schlüsse oder irgendetwas anderes, das hier erwähnt wird). Der Unterschied liegt in einem völlig anderen Entwicklungsstil, den Sie bei der Arbeit mit F # verwenden können.
Sie können weitere Informationen finden:
Hoffe, das hilft!
Die funktionale Programmierung unterscheidet sich erheblich von der objektorientierten Programmierung. Da F # jedoch eine objektorientierte funktionale Sprache ist und C # eine funktionale objektorientierte Sprache ist, scheinen diese beiden Sprachen ziemlich nahe beieinander zu liegen.
Es gibt Dinge wie diskriminierte Gewerkschaften, aber ich kam genau zu der gleichen Schlussfolgerung wie Sie.
Und ich bin kein großer Fan der Tupel - ich mag benannte Eigenschaften, also muss ich mich nicht an jede Position erinnern.
Dinge wie "immutabiliy" sind ein falscher Anhaltspunkt - da kann man das in C # machen, und hoffentlich wird es auch C # 5 einfacher machen.
Re syntaktische Ordentlichkeit ... Ich finde C # besser und einfacher zu folgen, Bugs, die Vertrautheit sein könnten.
Es gibt eine bessere Switch-Syntax, die aber in C # eingefügt werden kann - siehe hier (einschließlich Antworten). Re anon-Methoden, niemand zwingt dich, sie zu benutzen, aber Lambdas sind in vielen Fällen eine sehr saubere Art, Absicht auszudrücken.