Muster-mix F# und C# in der gleichen Lösung
Studierte ich einige funktionale Sprachen, vor allem für schulische Zwecke. Dennoch, wenn ich Projekt eine client-server-Anwendung, die ich starte immer die Annahme eines Domain-Driven Design, streng OOP.
Einer komplexen Lösung geschrieben .Net framework bekommen könnte Vorteile, die mit mehr als einer Sprache, und manchmal mehr als ein Paradigma. Das mischen von C-oder C++ mit LUA oder Python ist eine gängige Praxis, manchmal die Einbettung von prolog kann sehr interessant sein.
Ich habe nie versucht zu mischen, OOP und funktionale Paradigma.
F# ist eine neuere, funktionale und Objekt-orientierte Sprache, ich sehe, dass es technisch sehr einfach zu mischen, C# - F# - Bibliotheken in der gleichen Lösung. Aber ich Frage mich, ob es noch Sinn macht: ich nutze LINQ to erfüllen viele meiner funktionale Anforderungen.
Wann und wie, glaubst du, es ist eine gute Idee, mischen Sie diese beiden Sprachen zusammen?
Ich Frage mich, ob gibt es eine Reihe von mustern, die versucht, die.
Tun Sie auch wirklich nutzen F# in einer C# - Lösung?
- Dies scheint wie eine "poll" - Frage. Sollte wohl community-wiki. Es ist eine gute Umfrage, wenn.
- für die Klarheit, die Sie tatsächlich mischen Sie Sie in die gleiche 'Lösung', ein Projekt entspricht einer Bibliothek (generaliztion).
- Ein Levy: du meinst, ich sollte die fahne der "Wiki-community" checkbox? Danke. @ Lukas: korrigiert, Danke.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es bestimmte Orte, wo die traditionelle funktionale Techniken machen eine Menge Sinn, und führt zu code, der sowohl kleiner und übersichtlicher. Ein klassisches Beispiel ist der text-parsing-Baum-und-Verarbeitung, beide oft erscheinen zusammen, wenn Sie die Implementierung einer DSL. F# - features wie anonyme Iteratoren, erweiterbaren pattern-matching, und die Fähigkeit zum definieren von benutzerdefinierten infix-Operatoren dienen als combinators wirklich hilft hier viel. Inzwischen, auf der C# Seite, LINQ ist ein guter Anfang, aber es doesn ' T nehmen Sie alle den Weg dorthin.
Ich schlage vor, Sie haben einen Blick auf FParsec, und sehen Sie selbst, wie viel besser es ist, erweiterte text-Verarbeitung /parsing als jede Bibliothek, die Sie möglicherweise könnte in C# schreiben.
parse { ... }- vor allem).Ich geschrieben habe, einen WCF-Dienst in F#, die fungiert als übersetzer-plug-in für das Lesen eines WFS (geospatial data) - Dienst. Der code stellte sich heraus, schön und prägnant.
Während die standalone-dll, die ich zusammengestellt fein gearbeitet in meinem Kollege die C# - Lösung, er wollte versuchen, Sie zu erwürgen mich, wenn ich zeigte ihm den code. Kultur Schock, denke ich.
So haben wir mit F# und C# in einem Projekt? Ja und Nein. Nein, denn ich schrieb die Sache in C#. Ja, weil die Entwicklung und Erprobung des Prototyps in F# mich gerettet, mehr Zeit als es brauchte, um es zu übersetzen C# - LINQ-Stil.
Ich würde nicht wollen, um zu versuchen, bauen alles in F#, aber ich bin geduldig warten auf den Tag, an dem ich arbeiten kann auf die Daten-Verarbeitung/Algorithmische Teil einer gemischten Sprache, Lösung in F# ohne Angst um mein Leben.
Haben wir eine Anwendung, die ruft alle seine Funktionalität durch das laden von MEF Teile.
Die meisten Teile sind in C# geschrieben, aber es gibt einen Teil, die nicht binary-Daten-Verarbeitung, die ist geschrieben in F#. In diesem Fall ist F# war einfach besser für den job geeignet.
F# - Teil entspricht eine Schnittstelle definiert, die in C# - und C# - Anwendung hat keine Ahnung
der Umgang mit einer F# - Teil (außer die Abhängigkeit von fsharp.dll).
Natürlich gilt dies nicht nur für F#, wenn jemand will, um zu schreiben, oder schreiben Sie eine Teil (addon, Modul, was auch immer Sie es nennen wollen) in eine andere Sprache, es wird abgeholt von MEF und zur Verfügung gestellt, um unsere Anwendung ohne Nachteile.
Wählen wir die Sprache, die am besten geeignet ist, ein spezifisches problem zu lösen und MEF abstracts alle Besonderheiten von uns entfernt, also haben wir nichts zu befürchten.
Du hast mich denken, und ich versuchte zu entscheiden, wo ich es tun würde. Es gibt zwei Situationen, die in den Sinn:
Weiter, ich bin ein großer Verfechter der "richtige Werkzeug für den job', also, wenn ich denke, dass der ein oder andere würde besser passen, würd ich die verwenden.
Ich benutze F# für explorative Programmierung in meinem C# - Lösungen. E. g. Ich Feuer meine C# - WPF-Anwendung über visual Studio F# interactive-Konsole und stöbern in der Laufenden Anwendung. Sparen Sie eine Menge von edit-compile-debug-Sitzungen..
Sprachen sind nur ein Werkzeug. So wie Luke, ich bin ein großer fan der mit dem richtigen Werkzeug für den job. Wenn eine bestimmte app nutzen würde mit C# und F#, dann mischen scheint mir vernünftig.
So, wie es zu tun, finden Sie unter:
Können Sie mischen .net-Sprachen in einem einzigen Projekt?
Bottom line: Sie können Zusammenführen von zwei DLLs, die verschiedene Sprachen verwenden, in einer einzigen DLL als post-build-Schritt. Oder, Sie können mehrere Sprachen in eine Website zusammengestellt, die auf der server-Seite.
Habe es noch nicht versucht, aber ein Ort, wo ich sicher verwenden möchten, funktionale Sprache, auch wenn das nicht ein Grund sein, es zu benutzen, so dass ich vermeiden kann, was wurde hier beschreibe
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Ich möchte nur dieser name ein verb, und führen Sie es
calculateSomething() anstelle von SomtingCalculator.Execute()
Ja, in Zukunft ich glaube, wir müssen gemeinsam diese Art von Sprachen wie OOP (C#) mit der Funktionalen Sprache F#), um die Vorteile der multicore-Verarbeitung. C# 4 ist in Klassen um dies zu unterstützen, aber einige Dinge sind besser gemacht in F#.