Nachdem ich etwas zu diesem Thema gelesen und dieses Video angeschaut habe Ссылка wo Eric Lippert, Jon Skeet, Mads Torgersen und Neal Gafter über die Diskussion sprachen Zukunft von C # Es ist ziemlich klar, dass C # schweres Gepäck von früheren Funktionen zu C # hinzugefügt hat. Diese Funktionen müssen in späteren Versionen der Sprache unterstützt werden, auch wenn sie die Komplexität erhöhen und das Hinzufügen neuer Funktionen mühsamer machen. Wahrscheinlich, warum die meisten Sprachen früher oder später sterben.
F # ist eine neue Sprache und hat natürlich nicht das gleiche Erbe, um das sie sich kümmern müssen. Da es sich bei beiden um allgemeine Sprachen handelt, scheint es verlockend, sich mehr auf F # zu konzentrieren. Glauben Sie, dass F # C # als Sprache der Wahl in der .net-Welt übernehmen wird und wie schnell wird dies geschehen?
Ich weiß, dass es einen Unterschied zwischen funktionalen und imperativen Sprachen gibt, also könntest du argumentieren, dass sie zu verschieden sind, um verglichen zu werden, aber die Tatsache, dass c # immer mehr funktionale Features bekommt, muss ich fragen, warum nicht einfach direkt zu F # springen
Erstens, denken Sie nicht daran, dass die Division "funktional" gegenüber "statisch typisiert" ist - F # ist immer noch eine statisch typisierte Sprache.
Denke ich, F # wird C # übernehmen? Nicht in vielen Bereichen. In einigen Nischen wird es definitiv seine Spuren hinterlassen ... aber ich persönlich denke, dass es aus einem anderen Grund wichtiger ist: Es wird die Leute ermutigen, mehr funktional zu denken.
Es ist absolut es wert, sich F # genauer anzusehen - um eure C # zu verbessern. Sie werden nicht finden, dass jede Aufgabe für einen funktionalen Ansatz geeignet ist, aber es ist definitiv wert, etwas anders zu denken.
An dieser Stelle sollte ich wahrscheinlich Real World Functional Programming anschließen - meistens von Tomas Petricek geschrieben, mit ein bisschen Hilfe von mir . Es richtet sich genau an Entwickler, die eher funktional denken möchten, mit einer starken Voreingenommenheit gegenüber bestehenden C # -Entwicklern, die an F # interessiert sind. (Und heute - 4. September 2010 - das E-Book ist nur 15 $. Verwenden Sie den Code dotd0904cc an der Kasse:)
C # ist hier, um zu bleiben. Die Mehrheit der kommerziellen Entwickler (und fast alle kommerziellen .NET-Entwickler) werden in C-Derivaten, Imperativsprachen / -stilen geschult und verwenden diese.
Ich glaube nicht, dass die Entwicklungswelt einen so radikalen Paradigmenwechsel vollziehen wird, dass das imperative OO zugunsten funktioneller Hybride verschwinden wird, es sei denn, Sie zählen C # 's eigenen Schritt in den Bereich einer funktionalen Hybride.
(im großen und ganzen) Du kannst keine F # -Entwickler einstellen, Du kannst keinen Job als F # -Entwickler finden, Du kannst die meisten C # -Walter nicht überzeugen (diejenigen, die keine Sprachfans sind oder Hobby-Programmierer in ihren Freizeit), dass F # alles andere als ein akademisches Spielzeug ist oder einfach genug ist, dass es sich lohnt, sie zu lernen.
Ich wünschte, das wäre nicht wahr, je mehr ich F # lerne, desto mehr würde ich es lieben, die Sprache zu sein, die ich täglich benutze.
Als Antwort auf Ihre Frage: JA! lerne F #, weil es eine wundervolle Sprache ist, aber es wird C # nicht über Nacht (oder über das nächste Jahrzehnt) verdrängen.
Sollten Sie sich F # ansehen? Ja, aber weil F # eine interessante Sprache ist und du neue Dinge lernen wirst; nicht weil du Verteidigung gegen die Chance spielst, dass "C # auf dem Weg nach draußen ist und F # die Welle der Zukunft ist". C # ist gut etabliert, eine großartige Sprache mit einer großartigen Community und vielen vorhandenen Assets (Tools, Samples, Templates, ...), die es extrem unwahrscheinlich machen, dass sie in naher Zukunft von irgendeiner anderen .NET-Sprache verdrängt werden. Lerne F #, um Offensive zu spielen: um dein eigenes Skillset zu entwickeln und ein insgesamt besserer Entwickler zu werden (selbst wenn du dich meistens noch in C # entwickelst).
(Feature Creep und Legacy verlangsamen die Sprache etwas, aber nicht viel. Von dem, was ich erfahre, wird C ++ immer noch benutzt, trotz des Erdrückens von Legacy. :) Du sagtest, dass Sprachen "früher oder später" sterben. Ich erinnere mich an jede Sprache, die den Mainstream erreichte, aber dann "früher" starb.)
Erstens ist F # eine speziellere Sprache als C #. Ja, Sie könnten Lösungen für fast alles in F # schreiben, aber Sie finden es besonders nützlich bei:
Sie werden F # nicht so mächtig finden, wenn es um Dinge wie UI oder DB-Zugriff geht (es kann alles gut gemacht werden, aber Sie werden keinen großen Unterschied zur Verwendung von C # finden).
Zweitens glaube ich nicht, dass F # insgesamt C # übernehmen wird, aber es gibt bestimmte Nischenmärkte (z. B. die Finanzindustrie), wo F # eine reelle Chance haben, über andere Sprachen bekannt zu werden.
Schließlich hat das funktionale Programmierparadigma, wie Sie selbst erwähnt haben, In-Road in mehreren anderen Sprachen / Plattformen (Python, Ruby, C #, VB.NET, hoffentlich das nächste Java) gemacht, um sich mit seinen Konzepten vertraut zu machen Hilfreich sein wird, und im Moment, zumindest in der .NET-Plattform, ist F # die wahrste Implementierung solcher Konzepte.
Kurz: Sie sollten F # wahrscheinlich nicht als allgemeine Sprache * wie C # verwenden, sondern zu Projekten hinzufügen, in denen geeignet .
Allzweckprobleme unterscheiden sich oft zu sehr von dem funktionalen Paradigma, das F # nicht wirklich hervorheben würde, aber in einigen Fällen ist F # absolut das richtige Werkzeug. Trotzdem lohnt es sich, einen Blick darauf zu werfen, da man sonst nicht auf Fälle hinweisen kann, in denen ein funktioneller Ansatz (auch wenn er in C # implementiert ist) vorteilhaft ist.
Schöne Probleme für F #:
Bearbeiten: Erläuterung nach dem Downvot. Natürlich ist F # ein allgemeiner Zweck in dem Sinne, dass Sie alles damit machen können und das gesamte .NET Framework als C # targetieren können, aber weil es kann verwendet werden, bedeutet das nicht, dass es
Wie ich schon sagte, sind viele "Allzweck" -Anwendungen nicht von Natur aus funktional und basieren stark auf sich ändernden Zuständen oder allgemeinen objektorientierten Mustern. Während du dort wieder F # benutzen kannst, scheint es in diesen Fällen nicht wirklich zu sein, da es gegen seine Natur programmiert ist.
Warum sollten Sie eine funktionale Sprache verwenden, wenn Sie ein funktionelles Problem nicht lösen? Und da Sie nicht müssen , kombinieren Sie einfach F # und C #, wo jeder am besten passt.