"F # ist nicht schwerer zu meistern als Entity Framework oder WPF": Interview mit Scott Vlashin

Wen sollte ich nach F # fragen, wenn nicht eine Person, die dieser Sprache eine detaillierte Website gewidmet hat? Scott Vlashin schuf die Ressource "F # for Fun and Profit" , die vielen Habra-Bewohnern bekannt ist: Von Habré aus übersetzten sie von dort aus sowohl die Artikelserie "Functional Thinking" als auch den Artikel "Railway-Oriented Programming".

Und im November wird er auf unserer DotNext-Konferenz in Moskau mit dem Bericht „Die Kraft der Komposition“ sprechen. Und im Vorgriff auf diese Rede fragten wir ihn nach F # und allgemein funktionaler Programmierung.

- Lassen Sie uns von Anfang an fortfahren: Was haben Sie vor der funktionalen Programmierung getan, wie sind Sie zu F # gekommen und wie haben Sie die Site erstellt?

- Ich bin ein Mann von ehrwürdigem Alter, und als ich an der Universität war, gab es noch keine separaten Informatikprogramme. Ich erhielt eine mathematische Ausbildung, wollte aber keine Mathematik machen. Nach dem Studium arbeitete ich ungefähr 10 Jahre lang in verschiedenen Berufen, darunter als Zimmermann.

Eines schönen Tages in den späten 1980er Jahren kaufte mein Vater einen Computer, CP / M Kaypro, mit einer winzigen Menge an Speicher und 5,25-Zoll-Disketten für seine Arbeit. Dies war, bevor Windows erschien, also stand DOS darauf. Darauf habe ich angefangen zu programmieren. Ich beschäftigte mich mit Datenbanken, zunächst für meinen Vater, er brauchte dies für seine Arbeit. Und dann fing ich an, es professionell zu machen.

Meine Muttersprache war Turbo Pascal, und 1989 oder 1990 traf ich Smalltalk, und es hat mir sehr gut gefallen, es ist immer noch eine meiner Lieblingssprachen. Ein Job ersetzte einen anderen, und am Ende bekam ich, wie die meisten Programmierer, einen Job bei einem großen Unternehmen, um langweilige Geschäftsanwendungen zu schreiben (ich nenne sie „BLOBs“: Langweilige Branchenanwendungen). Und genau das tat er sehr lange.

Für eine Weile schrieb ich in Python, ungefähr 10 Jahre - in C #. Und 2011, also vor nicht allzu langer Zeit, habe ich beschlossen, dass ich meine Arbeit satt habe und es wäre schön, etwas Neues auszuprobieren. Also wollte ich funktionale Programmierung machen. Es stellte sich heraus, dass mein Visual Studio bereits eine funktionale Sprache hatte, also versuchte ich, F # zu verstehen. Und zuerst schien es sehr seltsam, ich konnte nichts verstehen, es war so anders als alles, mit dem ich vorher gearbeitet habe.

Es gab mehrere gute Blogs auf F #, aber nur sehr wenige, und es gab auch nicht genügend Dokumentation. Infolgedessen gaben mir meine Freunde ausgezeichnete Ratschläge: Wenn Sie etwas richtig lernen möchten, versuchen Sie, andere darüber zu unterrichten, da Sie dadurch das Thema sehr gut verstehen. Außerdem wurde mir geraten, ein Blog zu starten, damit ich mich von anderen Programmierern abheben kann.

Im Allgemeinen habe ich 2012 den Blog „F # für Spaß und Gewinn“ gestartet und jedes Mal Artikel darin veröffentlicht, wenn ich etwas Neues über F # gelernt habe. Jetzt gibt es mehrere hundert Seiten, und es hat große Popularität gewonnen. Anfangs war es nur ein Hobby, ich habe in meiner Freizeit daran gearbeitet. Und vor ungefähr 3 oder 4 Jahren habe ich beschlossen, meinen Job zu kündigen und freiberuflicher Berater zu werden. Im vorletzten Jahr schrieb ich ein Buch, das sich auch als sehr beliebt herausstellte. Und so fand meine Bekanntschaft mit F # statt.

- Wie arbeitest du als Freiberufler mit F # oder nicht nur?

- Grundsätzlich F #, obwohl im Allgemeinen, wofür sie bezahlen werden - deshalb rate ich * lacht * . Wenn ich Geld brauche, aber jemand an C # arbeitet und es interessant aussieht, nehme ich es. Und letztes Jahr habe ich drei Monate mit Python gearbeitet. Was mir wichtig ist, ist nicht die Sprache, sondern welches spezielle Problem gelöst werden muss. Ich mag es zu studieren, und wenn Sie eingestellt werden, um ein Problem zu lösen, müssen Sie, wenn nicht ein Experte, zumindest einen neuen Bereich aussortieren.

Auf diese Weise musste ich Immobilienökonomie und Versicherungsrisiken studieren. Ich glaube, dass guter Code nur geschrieben werden kann, wenn Sie das Thema, das Sie gerade tun, gut verstehen und nicht nur schreiben, was andere Ihnen sagen. Für mich ist das am interessantesten - keine Sprache, sondern ein Problem.

- In Russland ist das Geschäft mit dieser Sprache schwierig, obwohl einige Entwickler ein Interesse an F # haben: Es ist schwieriger, einen Entwickler zu finden oder zu ersetzen als mit C #. Und die Unternehmen, mit denen Sie zusammenarbeiten, wie werden sie in F # gelöst?

- Es gibt zwei häufigste Situationen. Die erste Option ist, wenn das Unternehmen bereits F # verwendet, hat es normalerweise eine Art Pilotprojekt. Sie rufen mich an und bitten mich, ihnen zu helfen, dieses Projekt zu starten und ihnen die Sprache beizubringen. Normalerweise sind sie bereit, etwa sechs Monate für ein solches Projekt aufzuwenden, um herauszufinden, ob sie dies weiter tun möchten.

Außerdem unterrichte ich Menschen domänengesteuertes Design, und hier steht F # nicht im Rampenlicht, aber ich benutze es als Sprache. Ich zeige Programmierern, die an C # gewöhnt sind, wie viel kürzer der gleiche Code in F # sein kann als in C #. Das heißt, ich fördere leise die Sprache. Es hilft, dass Sie nicht vollständig zu F # wechseln müssen, sondern ein Domänenmodell in F # und alles andere in C # schreiben können.

- Sie sagen, dass C # und F # zusammen verwendet werden können. In C # wird jedoch am häufigsten das Entity Framework, NHibernate oder ähnliches verwendet. Und unter Entwicklern auf F # ist dies viel weniger beliebt. Wie kann man diese Sprachen unter Berücksichtigung der unterschiedlichen Ansätze mischen?

- Eines der Unternehmen, mit denen ich zusammengearbeitet habe, verwendet das Entity Framework. Sie versuchten, zur Architektur der Ports und Adapter zu wechseln, dh alle Eingabe- / Ausgabeoperationen aus dem Kern der Architektur zu entfernen. Dafür ist das Entity Framework ziemlich schlecht. In solchen Situationen ist es viel bequemer, etwas wie Dapper zu verwenden, wodurch Sie nicht mitten in Ihrem Code mit SQL umgehen können. Dies erleichtert unter anderem das Testen.

Lassen Sie sie keine funktionale Programmierung verwenden, aber die Situation zwingt sie immer noch dazu, einen sauberen Kern des Programms zu haben und die Datenbank irgendwo an der Peripherie zu behalten. Wenn das Denken auf dieses Format umgestellt hat, ist dies ein wichtiger Schritt, um die Entität aufzugeben. In einem solchen Unternehmen hätte ich tatsächlich nichts geändert. Sie können Menschen nicht zwingen, sich zu ändern, sie müssen selbst Veränderungen wollen. Ich versuche nicht, mich selbst zu verkaufen und jemandem die Art aufzuzwingen, die ich für die beste halte. Normalerweise wollen sich die Leute schon ändern, und ich helfe ihnen nur dabei, dies zu erreichen. Verstehst du was ich meine?

- Das heißt, Ihre Kunden sind Unternehmen, die selbst bereits einen funktionaleren Ansatz verfolgen.

- Selbst wenn sie mit C # arbeiten, wechseln sie zu einem funktionaleren C #, verwenden LINQ, unveränderliche Datenstrukturen, dh gehen im Allgemeinen in diese Richtung. Daher ist der Wechsel zu F # für sie kein großer Sprung mehr.

Sind die Berufe eines Entwicklers und eines Tischlers ähnlich?

- Sie haben einen interessanten Thread auf Twitter, in dem Sie die Arbeit eines Programmierers und eines Zimmermanns vergleichen. Ich möchte ausgehend von diesem Thread nach "Funktionalismus" fragen. Aber können Sie unseren Lesern das Wesentliche davon erzählen?

- Entwickler vergleichen sich gerne mit Ingenieuren und Softwareentwicklung - mit dem Bau von Gebäuden oder Brücken. Und es gibt viele Debatten darüber, ob die Programmierung diesen Aktivitäten wirklich nahe kommt oder ob sie sich grundlegend unterscheiden. Wir haben Anforderungen an das Projekt, die sich jeden Tag ändern - wenn Sie eine Brücke bauen, ist wahrscheinlich alles völlig falsch? Oder ist es dort wirklich auch so?

Aber ich glaube, dass es in diesem Streit keine einzige richtige Antwort gibt. Ich war noch nie Ingenieur, aber Zimmermann. Und ich kann sagen, dass Tischler viele verschiedene Arbeiten haben, sehr unterschiedliche Formate, und jede braucht ihren eigenen Ansatz.

Zum Beispiel habe ich in einer der Arbeiten Küchenschränke gemacht. In Amerika sind sie alle sehr standardisiert, alle gleich groß, aufeinander zugeschnitten, und es wird mit Elektrowerkzeugen gearbeitet. Es ist notwendig, etwas Qualität zu liefern, aber in Amerika wird die alte Küche normalerweise weggeworfen, wenn das Haus seinen Besitzer wechselt, das heißt, es wird für eine sehr lange Zeit nicht dienen. Bei dieser Arbeit hängt alles von Geschwindigkeits- und Kosteneinsparungen ab.

Dann hatte ich eine andere Aufgabe, bei der ich einen großen 6-Zoll-Eichenbalken in der Mitte des Raumes im Gebäude ersetzen musste, der 400-500 Jahre alt war. Hier war alles umgekehrt: alles war gebogen, keine rechten Winkel, und um es zu ersetzen, musste manuell ein neues Stück Holz angebracht werden, damit es genau die gleiche Form wie das alte hatte. Dies erforderte viel Genauigkeit.

Schließlich gab es die dritte Arbeit, in der ich die Kulisse für die Bühne machte. Sie bestanden aus Sperrholz und sehr dünnem Holz für Requisiten.

Meine Idee ist, dass jede Arbeit ihren eigenen Ansatz erfordert. Bei Küchenschränken sind Präzision, der Einsatz von Elektrowerkzeugen und reproduzierbare Ergebnisse erforderlich. In einem alten Holzhaus, in dem Sie mit einem Legacy-System arbeiten, ist es wichtig, vorsichtig zu sein, nicht zu hetzen, Sie brauchen keine Geschwindigkeit, sondern die Richtigkeit des Ergebnisses. Schließlich schaffen Sie bei Dekorationen absichtlich eine zerbrechliche Struktur, die nicht stark sein muss. Oft müssen Sie sie schneiden und in wenigen Minuten wieder zusammenbauen. Solche Strukturen halten nicht ewig.

Wenn sie sagen, dass die Programmierung der Technik ähnlich ist, gilt dies nur für bestimmte Arten der Programmierung. Wenn Sie beispielsweise Software schreiben, die ein Flugzeug steuert, müssen Sie sehr vorsichtig sein und eine sehr hohe Genauigkeit erzielen. Eine ganz andere Sache ist ein einzeiliges Skript zum Suchen nach Dateien. Dies ähnelt eher dem Erstellen von Landschaften. Es macht keinen Sinn, 20 Stunden damit zu verbringen, zu beweisen, dass dieses Skript funktioniert, und 1000 Komponententests dafür zu schreiben. Alle Arbeiten sollten nicht länger als 5 Minuten dauern. Und wenn Sie mit einem geerbten System arbeiten, müssen Sie Ihren Code so weit wie möglich an das vorhandene anpassen. Ein umfangreiches Refactoring ist hier unerwünscht.

Das heißt, in jedem Fall ist der Kontext wichtig. Manchmal muss man viel planen, viel über ein Projekt nachdenken, viele Tests schreiben. In anderen Fällen reicht es aus, etwas aufzupeitschen. Vielen Menschen mangelt es in dieser Hinsicht an Flexibilität. Sie glauben, dass Sie kein Profi sind, wenn Sie keine Komponententests oder keine Programmiersprache verwenden. Tatsächlich ist die Idee, dass alles vom Kontext abhängt, ziemlich offensichtlich. Überraschenderweise, wie hartnäckig einige Programmierer auf ihren Ideen bestehen, und wenn Sie zumindest irgendwie von ihren Idealen abweichen, werden Sie sofort auf die schwarze Liste geschickt. Meiner Meinung nach ist das dumm.

- Sie sagen, dass für einen externen Beobachter die Aktivität einheitlich aussieht, aber wenn Sie sie von innen sehen, werden ganz andere Fälle aufgedeckt. Und ich möchte fragen: Ist es dasselbe mit der funktionalen Programmierung? Diejenigen, die von außen schauen, haben ein gemeinsames Stereotyp, aber tatsächlich gibt es gigantische Unterschiede?

- Das stimmt. Von außen mag es so aussehen, als ob alle „Funktionäre“ gleich denken, aber es gibt viele verschiedene Gruppen, die miteinander streiten: Unterstützer von Haskell, F #, Clojure, Elm. Selbst innerhalb von F # gibt es starke Meinungsverschiedenheiten darüber, in welche Richtung sich diese Sprache entwickeln sollte - sollten Sie versuchen, Haskell nachzuahmen, oder sollte die Benutzerfreundlichkeit Priorität haben. Sie haben also Recht, innerhalb dieses Feldes ist es viel vielfältiger, als es sich externe Beobachter normalerweise vorstellen.

- Für Unterschiede in der Arbeit eines Tischlers haben Sie sehr klare Beispiele gegeben. Können Sie die Unterschiede in der funktionalen Programmierung auch anhand konkreter Beispiele veranschaulichen?

- Es gibt eine Schule für funktionale Programmierung, die glaubt, dass Sie versuchen müssen, alles zu beweisen, und dass alles mathematisch perfekt ist. Diese Schule verwendet viel mathematischen Jargon, zum Beispiel "Monoide" oder "Monaden". Dies sind hauptsächlich Haskell-Benutzer, und das akademische Umfeld ist sehr einflussreich.

Und es gibt Menschen, die wichtiger sind, um Ergebnisse zu erzielen. Sie interessieren sich weniger für Mathematik als für Unveränderlichkeit und E / A-Entfernung zur Peripherie. Das beste Beispiel für diesen Ansatz ist die Elm Community. Sie sind hauptsächlich an der Erstellung von Webanwendungen beteiligt. Im Gegensatz zur ersten Gruppe verwenden sie hier nicht bewusst mathematischen Jargon und lehnen bewusst den Teil der Funktionalität ab, der in Haskell vorhanden ist und den Haskell-Benutzer für wichtig halten.

Darüber hinaus gibt es einen Streit zwischen Befürwortern einer starken und einer dynamischen Typisierung. Nach Ansicht des Laien ist funktionale Programmierung so etwas wie Haskell oder F #, aber neben ihnen gibt es Sprachen wie Clojure, die dynamisch tippen und einen völlig anderen Ansatz zur Lösung von Problemen haben. Wenn Sie all diese bunten Unternehmen in einem Raum sammeln, können sie kämpfen. Ich denke, dass alle Ansätze ihren eigenen Grund haben, und wenn ich für jemanden arbeite, sage ich ihnen nicht, dass ihr Ansatz falsch ist.

- Viele haben Angst vor der erwähnten „akademischen Natur“ („F # wurzelt in ML, was strengen wissenschaftlichen Beweisen dient, aber ich löse hier echte Probleme“). Aber es stellt sich heraus, dass die Menschen vergeblich Angst haben?

- Im Allgemeinen erscheint es mir seltsam, dass so viele Menschen daran gewöhnt sind, Akademizität als etwas Negatives zu betrachten. Nun, das heißt, manche halten es für negativ, andere für positiv.

Tatsache ist, dass viele der Technologien, die wir heute in der Programmierung verwenden, im akademischen Umfeld entstanden sind, beispielsweise die Speicherbereinigung oder Typen. An den akademischen Methoden selbst ist also nichts auszusetzen. Eine andere Frage ist, dass eine übermäßige Betonung schädlich sein kann, da Wissenschaftler und Programmierer unterschiedliche Ziele verfolgen.

Obwohl funktionale Sprachen akademische Wurzeln haben, scheint es mir die richtige bewusste Entscheidung zu sein, diese Logik in Sprachen wie F # und Elm zu verbergen. Daher wird F # nicht verwendet, um Theoreme zu beweisen, sondern um echte Probleme zu lösen. Es ist eine sehr pragmatische Sprache. Und die Universitäten haben jetzt auf noch komplexere Sprachen wie Coq, F * und dergleichen umgestellt. Sie sind viel akademischer und werden verwendet, um Theoreme zu beweisen.

Wie gesagt, Wissenschaftler und Programmierer machen verschiedene Dinge. Programmierer verbringen die meiste Zeit damit, Dateien zu lesen und zu schreiben, mit Datenbanken zu arbeiten, Daten auf dem Bildschirm anzuzeigen, eingegebene Daten zu überprüfen, sie zu konvertieren usw. Aber Wissenschaftler sind an solchen Dingen nicht interessiert. Tatsache ist jedoch, dass Dinge, die vor 40 Jahren rein akademisch waren, heute möglicherweise nicht mehr so ​​sind.

- Wie Sie selbst im Zusammenhang mit der Arbeit eines Tischlers gesagt haben, sind unterschiedliche Ansätze in unterschiedlichen Kontexten gut, es gibt keine universellen Ansätze. Insbesondere eignet sich F # auch am besten für bestimmte Aufgaben. Was sind diese Aufgaben?

- Ja, dies ist definitiv keine universelle Sprache, ich würde definitiv nicht empfehlen, sie überhaupt für alle zu verwenden, es wäre dumm. Aber es scheint mir, dass F # ein ausgezeichneter Ersatz für C # ist - mit Ausnahme von Aufgaben, die eine sehr hohe Leistung erfordern. Die Programmierung in F # basiert auf einem völlig anderen Ansatz: Immunität, strukturelle Gleichheit, explizite Abhängigkeiten, F # hat keine Nullwerte und so weiter. Und es scheint mir, dass dieser Ansatz bei der Lösung alltäglicher Programmierprobleme viel nützlicher ist.

Wenn eine Person C # verwendet, sollte sie daher unbedingt nach F # fragen. Diese Sprache hilft dabei, den Code zu verbessern. Was andere Anwendungsbereiche betrifft, scheint mir F # für viele Aufgaben gut geeignet zu sein, für die Python jetzt verwendet wird. F # und Python sind sich sehr ähnlich, und es scheint mir, dass F # ein großes Potenzial für die Datenverarbeitung hat. Derzeit ist in diesem Bereich noch viel zu tun, aber vielleicht werden die Leute in einigen Jahren F # für verschiedene Dinge im Zusammenhang mit Big Data und Data Science verwenden, für die Python jetzt verwendet wird.

Schließlich ist F # sehr praktisch, um mit JavaScript zu arbeiten. Im Allgemeinen möchte niemand direkt mit JavaScript arbeiten, daher gibt es viele Sprachen, die in JS kompiliert werden: zum Beispiel ReasonML (das unter OCaml ausgeführt wird) und Fable (das unter F # ausgeführt wird). Persönlich arbeite ich lieber mit einer dieser Optionen als mit JavaScript. Wenn ich also am Frontend arbeite, würde ich so etwas wie Fable wählen. Das sind also die drei Hauptbereiche, in denen F # seine beste Seite zeigt.

- Wie Sie in Ihrem Bericht „F # für C # -Entwickler“ festgestellt haben, ist die Hauptsache in der Sprache nicht die Syntax, sondern die Philosophie. Aber hier liegt die Schwierigkeit für diejenigen, die schnell verstehen wollen, "ob diese Sprache zu mir passt". Sie können bereits anhand einer kurzen Einführung verstehen, ob Ihnen die Syntax gefällt. Aber wie lange dauert es, die Sprachphilosophie zu verstehen?

- Eine Person, die in C # schreibt, kann schnell eine Sprache wie Java oder Go herausfinden, da die meisten dieser Standardsprachen etwa ein zwingendes Modell haben. Der Wechsel von ihnen zu F # erfordert definitiv viel Aufwand, und dies hält einige Leute auf. Nach meiner Erfahrung ist F # viel einfacher zu lernen, wenn Sie für eine Weile alles vergessen, was Sie über OOP wissen. Andernfalls beginnen Sie, alle möglichen Dinge von C # nach F # zu übertragen.

In zwei Wochen Training ist es bereits möglich, mit dem Schreiben von Arbeitscode zu beginnen, und es wird einige Monate dauern, bis man sich mehr oder weniger an die Sprache gewöhnt hat. Schließlich benötigen Sie für ein gutes Maß an Eigenverantwortung mehr Zeit, 6 Monate, vielleicht mehr - wenn wir über das Aussortieren aller Bibliotheken, Redewendungen und dergleichen sprechen.

Aber ehrlich gesagt ist der Wechsel zu F # nicht schwieriger als der Wechsel zu Entity oder WPF. Sie benötigen auch viel Zeit. Unterschätzen Sie nicht die notwendigen Anstrengungen, aber manchmal sagen sie, dass dieser Übergang Jahre dauert. Ich wiederhole: Um mit dem Schreiben von Code zu beginnen, dauert es einige Wochen, bis Sie es sich bequem gemacht haben - mehrere Monate. Ich sage dies sowohl aus meiner eigenen Erfahrung als auch aus der Erfahrung anderer Menschen, mit denen ich gesprochen habe.

Muss ich C # vor F # kennen?

- Es ist klar, dass die meisten Benutzer von F # aus C # stammten. Gibt es viele, die ohne C # -Erfahrung zu F # kommen?

- Es gibt nicht sehr viele solcher Leute, und es ist ziemlich schwierig für sie, da alle Bibliotheken über eine Dokumentation für C # verfügen, sodass die Leute überall auf Beispiele von C # stoßen. Aber es gibt immer noch solche Leute, und außerdem wird F # an mehreren Universitäten unterrichtet.

Es gibt Leute, die versuchen, F # nach Python zu lernen. Das Problem ist, dass F # sehr stark von .NET abhängig ist und .NET an C # gebunden ist. In der gleichen Situation wie in Visual Basic gibt es auch alle Beispiele in C #. Hoffen wir, dass sich diese Situation in den nächsten Jahren ändern und das Erlernen der Sprache erleichtern wird. Dies ist eines der wichtigsten Probleme.

— C#, F#, , F# . ? LINQ , , , ?

— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .

— C# , F# ?

— . , . , , . , - , Python JavaScript, .

, . JavaScript , F# . , . F# — , , C#, . F# .

— F# — «F# for fun and profit»? C#?

— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.

Fun and profit

— «F# » («F# for fun and profit») - , «». , -, ?

- Ja. . , F# , , . , , F#, , . F# .

- , — . , - Java . , , , . , , F# C# .

— «»: , , , .

— , . , , , . .

StackOverflow , , F# , . , , , , C#. , - , , 10 . .

, , F#, F#. F#, , . , . , F# .

— , F# . ? , , F# . F# ?

— , F# . , . - , . , , , . , . F# null; , ; . F# .

, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .

- . , , . , , , , , . Google Amazon — .

— , F# , — , , . ?

— , . , , C# , , C#. , C#, null, , - . F# . , , , .

- - , , , . C# F#, , , . , , . , , F#, .

— , Microsoft F# ( C# ). ?

— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .

, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .

— Haskell. F# — .NET-, ?

— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .

Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .

— . F#, , : , , ?

— , F# . , , , . , . F# , , C#. , Haskell, - , .

, , , .

F# , , . , -, .

, - , , — , ? , , , . F#, C#, , . . - , F#.

, F# , , .

DotNext «The Power of Composition». , F#: , , , . , .