Unkomplizierter C # / Java-Code ist extrem schwierig zu parallelisieren, Multithread usw. Als Ergebnis wird einfacher C # / Java-Code immer weniger von der gesamten Verarbeitungsleistung einer Box verbrauchen (weil alles jetzt sein wird) Multicore).
Das Lösen dieses Problems in C # und Java ist nicht einfach. Veränderlichkeit und Nebeneffekte sind der Schlüssel, um Dinge in C # und Java zu erledigen, aber genau das macht Multi-Core-, Multi-Threading-Programmierung so schwierig.
Daher wird die funktionale Programmierung immer wichtiger.
Wenn man bedenkt, dass die J2EE / Ruby-Welt unter vielen funktionalen / Multi-Core-Ansätzen splittert (genau wie für alles andere), während die .NET-Leute alle F # verwenden, deutet diese Denkweise darauf hin, dass F # sein wird riesig in zwei Jahren.
Was ist falsch an dieser Denkweise? Warum ist es nicht offensichtlich, dass F # riesig wird?
(Bearbeiten) Larry O'Brien nagelt es in dieser Blog-Beitrag :" In meinen Augen ist dies eine Reihe von Übungen, in denen C und C ++ leuchten - zumindest bis zum Multithreading. Sprachen mit list-processing-Idiome werden anfangs ebenfalls gut funktionieren, aber es können Speicherverbrauchsprobleme auftreten (insbesondere funktionale Sprachen.) Letztendlich denke ich, dass die verwaltete C-abgeleitete Sprache (Java und C #) den einfachsten Weg zu Übung 9 hat und dann ernst ist Mängel bei Übung 10, bei der Nebenläufigkeitsfragen die Hauptrolle spielen. Meiner Meinung nach wird Nebenläufigkeit das zentrale Thema in der beruflichen Entwicklung im nächsten halben Jahrzehnt werden, so dass diese Mängel sehr groß sind. "
Unkomplizierter C # / Java-Code ist extrem schwierig zu parallelisieren
Nicht, wenn Sie die Task Parallel Library verwenden.
Ob F # riesig wird, hängt davon ab, ob das Kosten-Nutzen-Verhältnis da ist, was überhaupt nicht offensichtlich ist. Wenn .NET-Entwickler herausfinden, dass sie einige Programme in 1/3 der Zeit schreiben können, indem sie einen funktionalen statt einen imperativen Ansatz verwenden (was meiner Meinung nach für bestimmte Arten von Programmen zutrifft), dann sollte es eine Motivation für die F # -Applikation geben .
Paul Grahams Geschichte von seinem Einsatz von Lisp in einem Startup-Unternehmen veranschaulicht diesen Prozess. Lisp verschaffte ihnen einen enormen Wettbewerbsvorteil, doch Lisp übernahm nicht die Welt, nicht weil es nicht mächtig war, sondern aus anderen Gründen, wie fehlender Bibliotheksunterstützung. Dass F # Zugriff auf das .NET-Framework hat, gibt ihm eine Chance.
Die Verwendung einer neuartigen Programmiersprache ist ein kalkuliertes Risiko - Sie können mehr eingebaute Funktionalität und syntaktischen Zucker bekommen, aber Sie werden in der Community-Unterstützung verlieren, Programmierer einstellen und blinde Flecken in der Sprache umgehen können. p>
Ich nehme nicht auf F # - jede Entscheidung der Programmiersprache ist eine Risikogleichung, die Sie erarbeiten müssen. Wenn die Leute dieses Risiko bei C # nicht eingehen würden, würden wir immer noch VB6 und C ++ benutzen. Gleiches gilt für diese Sprachen gegenüber ihren Vorgängern. Sie müssen sich für Ihr Projekt entscheiden, ob die Vorteile die Risiken überwiegen.
Funktionale Programmierung ist schwieriger zu verstehen als imperative Programmierung. F # ist in vielerlei Hinsicht eine schwierigere Sprache als C #. Die meisten "Entwickler" verstehen keine funktionalen Programmierkonzepte und können nicht einmal sehr guten imperativen Code in C # schreiben. Also, welche Hoffnung haben sie, in F # einen guten Funktionscode zu schreiben?
Und wenn Sie bedenken, dass jeder im Team in der Lage sein muss, den Code in der von Ihnen gewählten Sprache zu verstehen, zu schreiben, zu debuggen, zu korrigieren usw., bedeutet das, dass Sie ein sehr starkes Team brauchen - nicht nur eine sehr starke Person - um F # so zu benutzen, wie es benutzt werden soll. Und es gibt nicht viele davon.
Fügen Sie dem Mix die Tatsache hinzu, dass 8 Jahre C # / VB-Code herumliegen, der wahrscheinlich nicht migriert wird, und dass es leichter ist, Bibliotheken zu erstellen, die wie BCL in C # / VB aussehen und sich so anfühlen, da es weniger einfach ist lecke Sachen wie Tupel usw. durch öffentliche Schnittstellen, und ich rechne damit, dass es F # schwer fallen wird, mehr als nur die Nutzung starker Teams für neue, interne Projekte zu gewinnen.
Ich stimme der Prämisse nicht zu, dass C # schwer zu parallelisieren ist. Es ist wirklich nicht, wenn Sie wissen, was Sie tun. Zusätzlich wird dies durch paralleles linq noch einfacher gemacht. Wünsche ich, dass es ein OpenMP für C # gibt? Natürlich, aber die Tools, die C # bietet, erlauben es dir, fast alles zu tun, was du willst, wenn du gut genug bist (und ich denke, dass man nicht mehr so gut sein muss).
Ich persönlich denke, dass funktionale Sprachen zunehmend Mainstream werden (heck F # selbst ist ein Beweis dafür), aber wahrscheinlich niemals lingua franca Status wie C / C ++ / Java / C # / etc. haben oder Willen.
* Dies ist anscheinend eine etwas umstrittene Ansicht, also werde ich das weiter ausführen.
In einer multi-threaded UI wird jedes UI-Ereignis asynchron und auf einem eigenen Thread ausgelöst (die tatsächliche Verwaltung von Threads ist wahrscheinlich komplizierter als nur ein neues zu erstellen, aber das ist für die Diskussion nicht wirklich relevant) .
Stellen Sie sich vor, dass dies der Fall ist und Sie das Fenster rendern.
In Schritt 2 muss jedes Element den Anwendungsstatus (oder die Teilmenge davon, die sich auf die Anzeige auswirkt) sperren. Andernfalls, falls der Anwendungsstatus aktualisiert wird, könnte das Endergebnis des Renderns des Fensters Elemente enthalten, die zwei verschiedene Anwendungszustände widerspiegeln.
Dies ist ein Schleusenkonvoi. Jeder Render-Thread wird gesperrt, gerendert und anschließend freigegeben. deshalb werden sie seriell ausgeführt.
Stellen Sie sich vor, Sie haben es mit Benutzereingaben zu tun. Erstens sind die Benutzer ziemlich langsam, so dass die Vorteile nicht existieren werden, es sei denn, Sie machen beträchtliche Arbeit an dem (einer von vielen) UI-Thread; also werde ich annehmen, dass das der Fall ist.
Alles, was Sie erreicht haben, ist, von explizit aus einen Worker-Thread zu starten, um dies implizit zu tun; auf Kosten von potenziellen Heisenbugs & amp; Deadlocks, wenn Sie Ihren Status sperren.
Das grundlegende Problem mit UI-APIs besteht darin, dass Sie mit einer Beziehung von vielen zu eins (oder Eins-zu-vielen, je nachdem, wie Sie es betrachten) zu tun haben. Entweder viele Fenster, viele Elemente oder viele "Eingabetypen", die alle ein einzelnes Fenster / Oberfläche betreffen. Irgendeine Art von Synchronisation muss passieren, und wenn es Multithreading tut, hat das nicht mehr nur Nachteile.
Was ist falsch an dieser Denkweise? Warum ist es nicht offensichtlich, dass F # riesig wird?
Sie gehen davon aus, dass die großen Massen tatsächlich Programme schreiben, die Multicore-Unterstützung benötigen - oder dass die Programme signifikant von der Parallelisierung profitieren würden. Das ist eine falsche Annahme.
Serverseitig ist eine parallele Sprache noch weniger erforderlich. Die Backend-Server-Verarbeitung nutzt die Multicore- / Prozessor-Unterstützung bereits durch ihre inhärente Art der Gleichzeitigkeit aus (die Arbeit ist auf Clients über Threads und zwischen Prozessen aufgeteilt (z. B. ein App-Server, ein DB-Server, ein Web-Container).
Was mit dieser Argumentationslinie nicht stimmt, ist die Annahme, dass alles wie geplant funktionieren wird.
Es gibt die Annahme, dass es einfacher ist, Multithread-Programme in F # zu schreiben als in C #. Historisch gesehen haben funktionale Sprachen nicht so gut an Popularität gewonnen, und es gibt wahrscheinlich Gründe, warum. Obwohl es im Allgemeinen leichter ist, funktionale Sprachen als Imperativ-Sprachen zu multiplizieren, war es im Allgemeinen leichter, Menschen zu finden, die in imperativen Sprachen programmieren sollten. Diese zwei Dinge balancieren sich irgendwie aus, je nach den Leuten und der App. Es ist im Allgemeinen einfacher oder einfacher, Multithread-Anwendungen in funktionale oder imperative Sprachen zu schreiben. Es ist viel zu früh, um es zu sagen.
Es wird davon ausgegangen, dass die Leute einen effizienten Gebrauch ihrer 1K-Core-Computer verlangen. Es gibt immer Anwendungen, die so viel CPU-Leistung aufnehmen können, wie sie finden können, aber dies sind nicht die häufigsten Anwendungen. Die meisten Anwendungen, die Benutzer ausführen, sind heutzutage nicht durch CPU-Leistung eingeschränkt, sondern durch Verzögerungen bei lokalen E / A, Netzwerken und Benutzern. Dies kann sich ändern, aber es wird sich nicht schnell ändern.
Es ist auch nicht klar, dass massiv Multicore-Prozessoren die Welle der Zukunft sind. Es kann einen ziemlich kleinen Markt für sie geben, so dass Chip-Hersteller kleinere Chips statt leistungsfähiger produzieren oder Ressourcen für andere Dinge einsetzen werden, über die wir derzeit nicht im Klaren sind.
Es gibt die Annahme, dass F # der Gewinner unter den funktionalen Sprachen sein wird. Als funktionale Sprache VS 2010 hat sie einen erheblichen Vorteil. Das Rennen hat jedoch noch nicht wirklich begonnen, und es gibt viel Zeit für Dinge, die passieren können. Es kann sich herausstellen, dass F # .NET keine besonders gute Sprache ist, um massiv parallele PCs zu programmieren, und etwas anderes kann entstehen. Es kann passieren, dass Microsoft und .NET nicht mehr so wichtig sind, wenn 64-Core-Prozessoren routinemäßig auf billige Laptops kommen. (Verschiebungen wie diese sind nicht so häufig, aber sie tendieren dazu, überraschend zu sein. Sie sind auch wahrscheinlicher in Zeiten von konzeptionellen Veränderungen, und eine Massenverschiebung in funktionale Sprachen würde sich qualifizieren.)
Unter der Annahme, dass F # weiterhin die primäre Microsoft-Funktionssprache bleiben wird, dass Microsoft-Programmiersprachen weiterhin dominieren werden, ist es wichtig, maximale Leistung aus massiven Multicore-Prozessoren herauszuholen, die alle technischen Argumente nicht haben von Geschäftsträgheit überschwemmt, und das F # wird deutlich besser sein als C # und andere solche Sprachen beim Schreiben von massiv Multithread-Anwendungen, und dass Sie Recht haben. Dies ist jedoch eine ganze Reihe von Annahmen, die aneinandergereiht und durch plausible Gründe und nicht durch starre Logik verbunden sind.
Sie scheinen zu versuchen, die Zukunft als eine Kombination aus den Dingen des nächsten Jahres zu prognostizieren, die um eine Argumentationslinie über technische Probleme erweitert werden, und das ist äußerst unzuverlässig.
Der einzige "Fall" dagegen (wenn es so etwas gibt) ist, dass die meisten modernen, professionellen Entwickler verschiedene Werkzeuge (sowie verschiedene Werkzeugarten) verwenden. F # bringt einige einzigartige Werkzeuge ins Spiel, und diejenigen von uns, die sie annehmen, werden unsere jeweiligen spezialisierten Talente finden, die für andere Programmieraufgaben nützlich sind - insbesondere jene Aufgaben, die die Analyse und Manipulation großer Datensammlungen beinhalten.
Was ich von F # gesehen habe, erstaunt mich wirklich. Jede Demo lässt mich grinsen, weil F # mich als eine erweiterte Ausgabe von dem, was ich mich erinnere, aus den guten
Es gibt eigentlich keinen Fall gegen F #, aber Sie müssen den Kontext der Situation verstehen, in der wir uns als Entwickler gerade befinden.
Die Multicore-Architektur steckt noch in den Kinderschuhen. Die treibende Kraft, um Singlethread-Apps auf eine parallele Architektur umzustellen, wird Zeit brauchen.
F # ist aus einer Reihe von Gründen sehr nützlich, wobei der Parallelismus einer von ihnen ist, aber nicht der einzige. Funktionale Programmierung ist auch sehr nützlich für wissenschaftliche Zwecke. Dies wird in vielen Bereichen enorm sein.
Wie Sie Ihre Frage formulieren, klingt es jedoch so, als würden Sie festlegen, dass F # bereits einen verlorenen Kampf führt, was definitiv nicht der Fall ist. Ich habe bis jetzt mit vielen Wissenschaftlern gesprochen, die Dinge wie MatLab und Ähnliches verwenden, und viele von ihnen kennen F # bereits und sind begeistert darüber.
Es gibt ein paar Dinge, die es wert sind, über Technologie zu berichten
Wenn wir annehmen, dass der Kampf zwischen C # und F # stattfindet, glaube ich nicht, dass F # innerhalb von 2 Jahren C # aus folgenden Gründen gewinnen wird:
Die Funktionen von F #, die C # nicht enthält, sind keine Features, die Menschen fehlen. Zum Beispiel denke ich, dass Seq.map, Seq.iter, Seq.fold und Freunde großartig sind, aber ich sehe keine Mehrheit von Entwicklern, die von foreach zu diesen Konstrukten wechseln.
Die Leistungsvorteile von Multicores sind für die meisten bestehenden Programme irrelevant, da nur wenige Programme CPU-gebunden sind. Für Programme, bei denen Leistung wirklich wichtig ist (z. B. Videospiele), wird C ++ zumindest in den kommenden zwei Jahren vorherrschend bleiben. Es ist nicht so schwierig, Threads in C ++ zu verwenden, vorausgesetzt, man vermeidet Nebenwirkungen (die Sie selbst in C ++ treffen können). Tut Google das nicht?
Damit F # wirklich groß wird, muss es meines Erachtens eine der Hauptsprachen im Unterricht werden, so wie Java. Dies ist sehr wahrscheinlich, wenn man bedenkt, wie sehr die akademische Welt funktionale Sprachen mag. Sollte das passieren, glaube ich nicht, dass die Auswirkungen vor 5 Jahren sichtbar werden.
Das Verknüpfen von Baugruppen ist nicht trivial.
F # ist an das .NET-Typsystem gebunden, das wesentlich eingeschränkter ist als beispielsweise PHP. Es ist wahrscheinlich genau dort oben mit Java im Land von Strong Typing. Das macht die Einstiegsbarriere für jemanden, der mit den .NET-Typen nicht vertraut ist, ziemlich hoch.
Single-Assignment-Code ist schwer zu schreiben; Die meisten Algorithmen verwenden das typische Turing-Maschinenmodell, das mehrere Zuweisungen zulässt und der Code für die Einzelzuordnung nicht wirklich in ein gutes Modell für "Wie wir denken" passt. Zumindest für diejenigen von uns, die Turing Machine Code für ihren Lebensunterhalt schreiben. Vielleicht ist es anders für diejenigen von uns, die Lambda Machine Code da draußen schreiben ...
F # ist an Microsoft gebunden, was bei vielen Geeks einen hysterischen Hass erzeugt. Sie würden lieber Lisp oder Scheme oder Haskell (oder was auch immer) verwenden. Obwohl Mono es unterstützt, unterstützt es das letzte Mal nicht gut, wenn ich versuchte, an Mono zu arbeiten (es war ziemlich langsam).
Der Großteil unseres bestehenden Codes lebt in imperativen, sequentiellen Codebasen, und die meisten unserer Anwendungen sind auf imperative, sequentielle Operationen mit Nebeneffekten ausgerichtet.
Was zu sagen ist, reine funktionale Ansätze modellieren die reale Welt nicht sauber, so dass F # eine Nische ausarbeiten muss, in der es Probleme in der realen Welt leicht handhabt. Es kann keine allgemeingültige Sprache sein, weil es allgemeine Probleme nicht sauber löst.
Tags und Links java c# multithreading f# multicore