Ich habe gerade gehört Podcast von Chris Smith über F # , in dem er darüber spricht, wie F # eine Sprache ist, die es Ihnen erlaubt, Probleme auf andere Weise anzugehen als in C # / VB.NET, dh anstatt "Bits herumzuschubsen" zusammen Datentransformationen ", und das, wie F # wird" wie XML ", etwas, das Sie zusätzlich zu Ihrer Sprache der Wahl (C # oder VB.NET) verwenden, um bestimmte Probleme auf eine effizientere Weise zu lösen.
Das hat mich dazu gebracht, über die Beziehung der .NET-Sprachen zu denken, so wie ich sie verstehe:
Aber was ist mit IronPython und IronRuby ? Chris erwähnte, dass "F # viel von Ruby und Python gelernt hat", also würde ich denken, dass F # eine ähnliche Beziehung zu IronRuby / IronPython und C # zu VB.NET hat. Ein bisschen herumgeplottet sagt mir jedoch, dass IronRuby und IronPython beide auf dem DLR basieren, aber F # nicht ist.
Wie lassen sich die Beziehungen zwischen F #, IronRuby und IronPython am besten verstehen?
F # und IronPython / IronRuby sind Lichtjahre von einer sprachlichen Perspektive entfernt. F # ist eine funktionale, hoch typisierte kompilierte Sprache. IronRuby / IronPython sind dynamisch typisierte, interpretierte Sprachen.
Ich glaube, dass IronPython die Kompilierung zusätzlich unterstützt, aber ich bin mir nicht 100% sicher und weniger über Ruby.
Die Beziehung zwischen VB.Net und C # ist viel näher.
In vielerlei Hinsicht sind F # und Ruby / Python oberflächlich ähnlich. In allen drei Sprachen können Sie Ideen präzise ausdrücken, ohne Ihren Code mit vielen Arten zu verschwenden. Allerdings unterscheidet sich F # sehr stark von Ruby und Python, da F # eine statisch typisierte Sprache ist, während Ruby und Python dynamisch typisiert sind. Idiomatischer F # -Code erwähnt selten Typen, aber der Compiler leitet Typen ein, und alle Typfehler werden vom Compiler während der Kompilierung markiert. Bei Ruby und Python erzeugt die Verwendung eines falschen Typs nur Fehler zur Laufzeit. Die Dynamik von Ruby und Python bedeutet, dass beide besser für Metaprogrammierung geeignet sind als F # (Typen können z. B. zur Laufzeit geändert werden). Auf der anderen Seite wird F # für die meisten Aufgaben leistungsfähiger sein (vergleichbar mit C #) und bietet viele schöne funktionale Abstraktionen, wie diskriminierte Vereinigungen mit Musterabgleich. Es ist sicherlich richtig, dass das Erlernen einer dieser Sprachen dazu führt, dass Sie über Probleme anders nachdenken als in C # oder VB.NET, aber Ihr Ansatz wird wahrscheinlich auch zwischen F # und Python / Ruby variieren.
Ich würde sagen, dass F # bei OCaml viel mehr gelernt hat als bei Ruby und Python zusammen. Der einzige wirkliche Vergleich ist, dass F # ML nach .NET bringt, genau wie IronPython / Ruby Python / Ruby nach .NET bringt.
F # ist eher eine "Werkzeugsprache", in der es spezifische Probleme gibt, die am besten mit einem funktionalen Ansatz angegangen werden. F # ist inhärent Thread-sicher, was Hoffnung gibt, dass es beim Skalieren einer Anwendung für die Verwendung mehrerer Prozessoren hilfreich sein wird. Ich sehe F # verwendet werden, um Komponenten zu erstellen, die in VB.NET oder C # verwendet werden, um bestimmte Probleme zu behandeln.
Es gibt Aspekte von F #, die dynamischen Sprachen ähnlich sind; Die Antwort von JaredPar bringt es jedoch auf den Punkt. F # ist in seiner eigenen Kategorie der funktionalen Programmierung, wobei IronRuby und IronPython dynamische Sprachen und C # / VB OO-Sprachen sind. Sie können alle die gleichen Dinge tun und hängt nur davon ab, wie Sie es tun möchten. Jeder hat seine Vor- und Nachteile für ein gegebenes Problem.
HINWEIS: Dies ist hauptsächlich eine Zusammenstellung meiner Gedanken und Beobachtungen zu diesem Thema. Ich bin ein C # -Programmierer bei Tag und Python bei Nacht.
Ja, ich stimme einigen der Dinge zu, die gesagt wurden, aber ich habe etwas Zeit und möchte meine Gedanken ausarbeiten und teilen.
F # ist eine funktionale Sprache. Was bedeutet, dass du dich so sehr mehr mit den Verben beschäftigst. Es ist immer noch statisch getippt und läuft auf der CLR, aber Sie strukturieren Ihren Code anders und arbeiten Probleme anders durch. Normalerweise denken die Leute, dass funktionale Sprachen mathematischer strukturiert sind und leichter formal bewiesen werden können. Natürlich wird das meist als akademisch angesehen.
C # und andere statisch typisierte OO-Sprachen konzentrieren sich wirklich mehr auf die Substantive, um meine Analogie zu verbessern. Du strukturierst also deinen Code und arbeitest damit Probleme aus. Natürlich gibt es auch natürliche Probleme mit der Aufrechterhaltung des Zustands und mit nichtdeterministischen Methoden für Objekte, die in OO-Sprachen häufiger vorkommen.
Und natürlich hat F # einige Funktionen und Ideen, die von OO-Sprachen übernommen wurden, während C # Ideen und Funktionen enthält, die von funktionalen entlehnt sind.
Beim Vergleich von Python und C # geht es mehr um den Unterschied zwischen dynamischer und statischer Typisierung (obwohl Python einige funktionale Funktionen bietet, die C # immer noch nicht bietet). Dynamische Typisierung ist in der Regel viel einfacher zu handhaben, Introspektion / Reflektion Aktivitäten und Laufzeitänderung, während das Risiko von Laufzeitfehlern aufgrund von Tippfehlern oder falsche Objekte in "normalen" Code verwendet.
Statische Sprachen haben normalerweise einen gewissen Entwickleraufwand, den dynamische Sprachen nicht haben. Der Overhead scheint in der Regel darauf zurückzuführen zu sein, dass Ebenen erstellt werden müssen, um Dinge wegzuspalten und Vererbungshierarchien und Schnittstellen zu erstellen, um mit der benötigten / gewünschten Abstraktion zu arbeiten. Da Sie versuchen, Abhängigkeiten zu Typen zu vermeiden.
Es scheint, dass Statiksprachen in größeren Teams viel einfacher zu verwalten sind. Außerdem erhalten Sie die Vorteile des Refactorings sehr einfach mit all den Überprüfungen und Tools da draußen.
Tags und Links c# f# vb.net ironpython ironruby