Mit Version 4.0 von .Net wird ja F# als offizielle Sprache unterstützt. Konnte schon jemand praktische Erfahrungen sammeln? Also mehr als das mal zwei Funktionen schreiben und denken ah schön. ;) Falls ja würde mich natürlich interessieren ob es eine reine F# Anwendung ist.
Wer von euch wird F# in Zukunft einsetzen?
Hier ein interessanter Link zu F#.

Ist zwar nicht direkt eine Antwort auf deine Frage aber ein paar generelle Gedanken zu F#.

Aktuell ist es irgendwie modern sich mit F# zu beschäftigen. Die Idee hinter F# ist jedoch nicht neu - funktionoale Programmiersprachen wurden erstmals gegen Ende der 80er Jahre entwickelt, sind also nur gering jünger als objekt orientierte Programmiersprachen. Verbreitung haben fuktionale Sprache jedoch nie erlangt. Selbst junge Sprachen wie Java/.net haben sich in ihrer kurzen Lebenszeit mehr verbreitet als es je eine funktionale Sprache geschafft hat. Daher sehe ich das Schicksal von F# genauso wie für die anderen Vertreter dieser Spezies.

Ich werde mir F# nicht lernen denn es ist eh schon genug Aufwand bei C# und allem was dazu gehört auf dem laufenden zu bleiben (jetzt kommt glich C#4.0 und wahrscheinlich wieder ein 1,5 Jahre später C#5.0;). Mein Programmiererleben besteht nicht nur aus dem Lernen von Sprachen und Features sondern vor allem darin Probleme zu lösen und um mein Werkzeug möglichst effizient und intuitiv einzusetzen - dafür werde ich ja auch bezahlt ;)

Alle Vorteile die für F# genannt werden treffen nur in gewissen Maße zu. Mal abgesehen dass ich die Syntax von F# grauslich und wenig intuitiv finde, gibt es nichts was ich mit C# nicht lösen kann. Eleganz ist subjektiv zu beurteilen und daher bietet für mich F# in dieser Hinsicht keine Vorteile. Ob ich nun eine mathematische Formel als Einzeiler codieren kann oder nicht ist für mich auch nicht entscheidend. Zum einen gibt es Formeln die 'riesig' sind und zum anderen habe ich es auch im Code gerne wenn ich Zwischenergebnisse berechnen kann (zB zu Debug-Zwecken). Durch die Jahre ist außerdem die Denkweise für die imperative/OO-Programmierung bzw. Programmerstellung soweit fortgeschritten dass die etwas andere Denkweise der (rein) funktionalen Programmerstellung ein ziemliches umdenken verlangen würde.

Eine leichtgewichte funktionale Programmierung ist mit Delegaten und anonymen Methoden auch mit C# möglich. Verwendet hab ich das aber nicht wirklich und Code der sich dem zu Nutze macht sehe ich auch kaum. Wozu also ein reine funktionale Sprache wenn scheinbar kein Bedarf entsteht?
Rekursion ist in so gut wie allen Sprachen möglich und somit lassen sich die gleichen Problem lösen - die Programmiersprache ist ja nur ein Mittel zum Zweck.

Ein praktischer Feature schein dass Einheiten zu den Variablen gespeichert werden können und somit der Compiler prüfen kann ob die Zuweisungen korrekt sind. Schönes Feature aber hat das praktisch Relevanz? Nein - die Eingaben müssen immmer noch auf herkömmliche Weise geprüft werden und der zu programmierende Algorithmus wird auch nicht im Code erstellt sondern liegt schon vor oder wird selbst von den Formeln abstrahiert. Dabei ist eine Einheitenprüfung unerlässlich und somit ist die Speicherung der Einheiten zu den Variablen nur etwas was die NASA gebrauchen kann wenn sie an Projekten mit SI- und dem Zoll-System rechnen. Der Rest der Welt kam ohne dieses Feature 50+ Jahre ohne Probleme aus ;)

F# für die Simulation: Simulation (von vortäuschen) basiert auf Modellbildung. Mit F# würde es auf einem mathematischen Modell beruhen. Ist die Realität aber nicht durch Objekte besser zu beschreiben? Für mich schon. Die Mathematik kann dann in jedes Objekt implementiert werden. Dies täuscht für mich die Realität besser vor als ein Satz von Differentialgleichungen welche in F# auch nicht automatisch gelöst werden können. Entweder verstehe ich unter Simulation etwas anderes als die Propagisten von F# oder ich übersehe etwas.

Es gäbe noch genügend weiteres zu schreiben, aber ich denke es genug. Kurz zusammengefasst: Für mich ist F# eine weitere akademische Sprache die (wie so viele) zum Scheitern verurteilt ist weil sie auf alte nicht durchgesetzten Konzepte basiert und keine nennenswerte Vereinfachung zur Lösung der realen Probleme bietet.

Ich habe mich nicht intensiv mit F# beschäftigt und daher kann es sein dass ich wesentliche Kernpunkte der Sprache falsch aufgefasst habe und somit einige oben erwähnte Punkte zu entkräften sind. Aber wenn diese Punkte nicht auf den ersten Blick ersichtlich sind kann es nur von geringer Relevanz sein ;)

Ich werde aber weiterhin (kurze) Blicke auf F# werfen und vielleicht ergibt sich ein Einsatzszenario um F# zu verwenden.

Anmerkung: Dies soll keine 'Verleumdung' gegen F# sein, sondern nur meine persönliche Sicht der Dinge.

In meiner aufrichtigen Meinung,
Günther ;)

F# macht Spaß! Mir zumindest. Wie Günther Foidl schon richtig geschrieben hat, ist es erst einmal gewöhnungsbedürftig sich in die Syntax einzuarbeiten, wenn man das zuvor von imperativen, nicht funktionale Sprachen wie C, C#, Java gewohnt ist. Aber es lohnt sicht!

Ich werde kurz aufzählen, wo ich persönlich die Stärken sehe:

Eine der größten Stärke an F# ist meiner Meinung nach die Integration in das .NET Framework.

F# kennt imperative, objektorientierte Ansätze, ist dabei aber eine erstklassige funktionale Programmiersprache. F# kann mit den bisherigen Programmiersprachen gut verknüpft werden. Imperative Probleme können also nach wie vor mit C# und Co gelößt werden, Funktionale mit F# und skriptbare, dynamische mit IronPython oder IronRuby.
nehmen
F# ist typisiert und dabei brauchst du die Typen aber nicht angeben (Type Inference). Der Kompiler sucht sich die Typen selbst zusammen.

F# setzt das PIPELINING sehr gut um. Der Pipeoperator |> macht manche Anweisung zu einem Genuß und erleichtert die Lesbarkeit, Evolvierbarkeit und Wartbarkeit von Code sehr. Last but not Least wäre für mich da noch das Patternmatching zu nennen, das ich sehr an F# schätze.

F# bietet die Möglichkeit eigene Operatoren zu erstellen (nicht nur die Ableitung der Bereits bekannten) und das nicht nur als Postfix, sondern auch als Infix. Damit werden die Klammern beim Aufrufen der Funktion überflüssig.

F# kann frei von Seiteneffekten programmiert werden, was die parallelisierung von Problemen und Algorithmen gut verteilbar macht. Und damit kommen wir zu dem bevorzugten Anwendungsgebiet von funktionalen Sprachen: Verteilte, skalierbare Systeme. Erlang, oder LISP - auch funktionale Sprachen - erfüllen genau diesen Zweck. Das konzept von F# zielt auf nichtänderbare, sprich statische Daten, die parallelisiert verarbeitet werden können. Das macht natürlich nur in solchen Szenarien Sinn, wo du parallel abarbeiten kannst.

C# sehe ich im Moment mit dem größten Potential an, da es die Schnittmenge zu allen .NET Sprachen ist, es beherrscht mit LINQ sehr gut die funktionalen Ansätze mit 4.0 kann C# auch dynamischen Code erzeugen, der erst zur Laufzeit ausgeführt wird. Was C# noch gut stehen würde wäre ein Konzept wie Mixins (Theme Komposition vs. Mehrfachvererkbung) und was in letzter Zeit immer mehr in Mode kommt sind META Programmierfähigkeiten.

Damit wären wir bei meinem großen Favorit für mich persöhnlich: Boo (früher hatte ich Nemerle favorisiert). Die eingebaute Fähigkeit seinen eigenen Sprachumfang durch Implementierung der Schnittstelle IAstMacrozu erweitern ist sehr gut führ DSLs geeignet. Mit wenig Aufwand kann eine eigene kleine Sprache erstellt werden, mit der Problemdomänen besser, effizienter bearbeitet werden können. Ruby ist übrigens für solche Zwecke auch gut geeignet (siehe RSpec)

Alles in allem ist mein Fazit: Für jeden Bereich seine eigene Spezielle Sprache ausnutzen! Ich hoffe dazu auf dem .NET OpenSpace 2009 mich mit anderen zu dem Thema Language Oriented Programming (LOP) austauschen zu können. F# schafft es mit seiner erst gewöhnungsbedürftigen Syntax bestimmte Probleme kürzer und knapper zu definieren. Die Vorteile liegen dabei eher auf Bibliotheken/Algorithmen als auf GUI. Aber dafür können wir ja dann z.B. WPF, WinForms, Qt, GTK oder was auch immer nehmen.

Ein praktischer Feature schein dass Einheiten zu den Variablen gespeichert werden können und somit der Compiler prüfen kann ob die Zuweisungen korrekt sind.

Aehm, ist nichts neues und kann auch mit Boardmitteln in C++ schoen implementiert werden, siehe: boost MPL.

Schönes Feature aber hat das praktisch Relevanz? Nein

Naja, die Marssonde ist abgestuerzt, weil das eine System mit Fuss und das andere mit Meter gerechnet hat. Koppelt man den Wert an eine Einheit, so findet man Bugs schon zur Kompilezeit (naja fuer C++ braucht man es nicht mal explizit in die Sprache aufnehmen).

Ist die Realität aber nicht durch Objekte besser zu beschreiben?

Dude, not every problem is an object.

ich nun eine mathematische Formel als Einzeiler codieren kann oder nicht ist für mich auch nicht entscheidend.

Fuer mich schon. Untersuchungen haben ergeben, dass im Schnitt 1 Programmierfehler alle 10 Zeilen (oder 20 oder 100 oder .. habe ich vergessen) auftritt, ganz unabhaengig von der Programmiersprache. Logische Konsequenz ist: Weniger Codezeilen => weniger Fehler. Oder wie viel Zeilen brauchst du fuer Hanoi? In Haskell:

dohanoi(0, _, _, _) = []
dohanoi(n, from, to, using) = dohanoi(n - 1, from, using, to) ++
                              [(from, to)] ++ dohanoi(n - 1, using, to, from)
hanoi(n) = dohanoi(n, 1, 3, 2)

Fuer funktionale Programme bieten sich auch ungeahnte Optimierungsmoeglichkeiten fuer den Kompiler. Die Frage hier z.B. ist: wieviel Speicher fuer das gesamte Programm wird benoetigt, wenn nur die Laenge der Liste ausgegeben werden soll?

Ich habe mich nicht intensiv mit F# beschäftigt und daher kann es sein dass ich wesentliche Kernpunkte der Sprache falsch aufgefasst

Wenn du F# durch Funktionale Sprache ersetzt, dann hast du wesentliche Kernpunkte nicht verstanden. Bestes Beispiel: in Haskell gibt es eine Library QuickCheck. Diese bietet weit mehr als jedes Unit-Test-Toll dir in anderen Sprachen (und das ist erst der Anfang). Auch stammt Funktionale Programmierung nicht aus den 80er, sondern ist so alt wie Lisp (ca. 1960). Als theoretische Grundlage dient das Lambda-Kalkuel (also noch aelter). Und frage dich doch mal selbst: Warum nehmen moderne Sprachen wie C++, Java oder C# immer mehr funktionale Elemente in ihre Sprache mit auf?

Der große Vorteil von funktionalen Sprachen ist die Seiteneffekts-Freiheit. Daraus folgt,
dass es egal ist wo das Ergebnis eines Funktionsaufrufs herkommt. Dies kann durch
eine Tabellen-Lookup sein (was war nochmal Fib(132)?) oder durch eine Berechnung auf einem anderen Prozessor oder sogar auf einem anderen Computer.
Dadurch hat der Compiler/Scheduler viel mehr Möglichkeiten zu optimieren, und die Ausnutzung aller Prozessorkerne bekommt man quasi geschenkt.

In C# ist das nicht so einfach. Hat man eine Methode

int DoSomething()
{
  return DoA(5)+ DoB(6);
}

So kann die Ausgabe jedes Mal unterschiedlich sein, und DoA und DoB müssen in dieser Reihenfolge ausgeführt werden, da sie sich ja beeinflussen könnten.

Es stimmt, es ist alles auch mit C# möglich, aber dummerweise noch viel mehr. Daher können sich Compiler und Laufzeitumgebung nicht auf uns Programmierer verlassen und nicht gescheit optimieren ;-)

In der Tat lassen sich selbst höhere funktionale Methoden auch in C# benutzen, auch die eigentlich F#-spezifischen Bibliotheken, siehe z.B.functional-c-implementing-async-computations-in-c.

Aber in C# sieht es doch irgendwie krank aus und lässt sich schlechter erlernen (IMHO und YMMV), so dass es sinnvoll sein kein, eine funktionale Sprache zu benutzen um sich die Konzepte einzuarbeiten, selbst wenn man sie produktiv später von C# aus nutzen möchte.