Warum ist OCaml nicht beliebter?

Ich habe immer gehört, dass C die Sprache der Wahl für eingebettete Systeme oder für alles ist, was mit maximaler Geschwindigkeit ausgeführt werden muss. Ich habe nie eine Vorliebe für C entwickelt, hauptsächlich, weil ich keine Zeigerarithmetik mag und die Sprache kaum eine Stufe über Assembler ist.

Auf der anderen Seite sind ML-Sprachen funktionsfähige Sprachen, die überflüssig gesammelt werden, und OCaml verfügt sogar über ein Objektmodell. Sie sind jedoch dafür bekannt, dass sie so schnell sind wie C. ML-Sprachen mit der Abstraktion, die man sich nur wünschen kann, um prägnante Texte auf hohem Niveau zu schreiben Code, aber es behält die Geschwindigkeit, die zum Schreiben von Hochleistungsanwendungen erforderlich ist.

Insbesondere OCaml kann überall dort eingesetzt werden, wo traditionell C verwendet wird, z. B. für eingebettete Geräte, Grafiktreiber, Betriebssysteme usw. OCaml hätte mittlerweile die Welt erobern sollen, aber kaum jemand hat bisher von der Sprache allein gehört benutzte es.

Dies ist eine subjektive Frage, aber warum sind OCaml und ML in anderen Sprachen so dunkel geblieben, während C und andere Sprachen populär wurden?

Die erste Antwort ist, dass niemand wirklich weiß, warum Sprachen populär werden, und jeder, der etwas anderes sagt, täuscht sich oder hat eine Agenda. (Es ist oft leicht zu erkennen, warum eine Sprache nicht populär wird, aber das ist eine andere Frage.)

In Anbetracht dieses Haftungsausschlusses sind hier einige Punkte zu beachten, die am wichtigsten sind:

• Der erste reife C-Compiler erschien 1974; Der erste ausgereifte OCaml-Compiler erschien Ende der neunziger Jahre. C hat einen Vorsprung von 25 Jahren.

• C wurde mit Unix ausgeliefert, der größten "Killer-App" aller Zeiten. Lange Zeit musste jede CS-Abteilung auf der Welt Unix haben, was bedeutete, dass jeder Ausbilder und jeder, der an einem CS-Kurs teilnahm, die Möglichkeit hatte, mit C. OCaml und ML in Kontakt zu treten. Sie warten immer noch auf ihre erste Killer-App. (MLdonkey ist cool, aber es ist nicht Unix.)

• C füllt seine Nische so gut aus, dass ich bezweifle, dass es nie wieder eine einfache Sprache geben wird, die nur der Systemprogrammierung gewidmet ist. (Um die Beweise dafür zu sehen, lesen Sie Dennis Ritchies Artikel über die Geschichte von C aus HOPL II.) Es ist nicht einmal klar, was OCamls Nische ist, und die Nische von Standard ML ist nur ein wenig klarer. So haben Caml und ML einige Konkurrenten, während C seinen einzigen Konkurrenten (BLISS) tötete.

• Eine der großen Stärken von C ist, dass das Kostenmodell sehr vorhersehbar ist: Wenn Sie sich ein kleines Fragment von C-Code ansehen, können Sie sofort eine genaue Vorstellung davon bekommen, welche Maschinenoperationen ausgeführt werden müssen, um diesen Code auszuführen. Das Kostenmodell von OCaml ist viel weniger klar, insbesondere wegen der Speicherzuweisungist viel weniger explizit, und die Gesamtkosten für die Speicherzuweisung (entspricht den Zuweisungskosten zuzüglich der Kosten, die bei der Garbage Collection anfallen) hängen von neuen Eigenschaften ab, z. B. wie lange Objekte leben und welche Objekte auf andere Objekte verweisen. Das Nettoergebnis ist, dass die Leistung schwer vorherzusagen und sogar schwer nachträglich zu analysieren ist. (OCamls Tools zur Erstellung von Speicherprofilen sind nicht das, was sie sein sollten.) Daher eignet sich OCaml nicht für Anwendungen, bei denen die Leistung sehr vorhersehbar sein muss - wie bei eingebetteten Systemen.

• C ist eine Sprache mit Standard und vielen Compilern. OCaml ist ein Software-Artefakt: Der einzige Compiler stammt aus einer Quelle, und der Compiler ist der Standard. Und dieser Standard ändert sich mit jeder Veröffentlichung. Für Menschen, die Wert auf Stabilität und Abwärtskompatibilität legen, kann eine Sprache aus einer Hand ein inakzeptables Risiko darstellen.

• Jeder mit einem halbwegs anständigen Compiler-Kurs für Studenten und viel Beharrlichkeit kann einen C-Compiler schreiben, der mehr oder weniger funktioniert und eine angemessene Leistung aufweist. Um eine Implementierung von OCaml oder ML in Betrieb zu nehmen, ist viel mehr Schulung erforderlich, und um eine vergleichbare Leistung mit einem naiven C-Compiler zu erzielen, ist viel mehr Arbeit erforderlich. Dies bedeutet, dass es sehr viel weniger Hobbyisten gibt, die mit Sprachen wie OCaml herumspielen müssen. Daher ist es für die Community schwieriger, ein tiefes Verständnis dafür zu entwickeln, wie man es ausnutzt.

Ich denke, das Problem mit OCaml ist, dass es "out of the box" nicht allzu nützlich ist. Der Grund, warum Leute eine Sprache benutzen, ist, dass sie Bibliotheken hat, die sie brauchen. Wenn nichts "out of the box" ist, kommt niemand weit genug in ein Projekt, um zu erkennen, dass er eine Bibliothek schreiben muss. Das Ergebnis ist eine Sprache ohne Bibliotheken, was das Schreiben von "echten Apps" erschwert.

Ich denke, das ist es, woran OCaml leidet - niemand stört sich daran, "echte Projekte" zu starten, denn alles, was es gibt, ist eine Programmiersprache. Ja, ich kann zwei und zwei addieren und das Ergebnis ausdrucken. Das Ergebnis ist eine Sammlung von Bibliotheken, bei denen es sich hauptsächlich um wissenschaftliche Abbruchmaterialien handelt (der Autor promovierte und ging weiter), was für das Üben von Programmierern nicht allzu hilfreich ist.

(Ich weiß, es wird daran gearbeitet, dies mit Projekten wie "Batteries Included" zu ändern. Kommen Sie in 5 Jahren wieder hierher, und vielleicht wird OCaml populärer.)

Es gibt einige Ausnahmen von dieser Regel. Java startete ohne Bibliotheken, aber Sun bezahlte die Leute, um sie alle im Haus zu schreiben, und dann vermarkteten sie das verdammt noch mal. Java-Zertifizierung, Java-spezifische Hardware, Java-Bücher, Java-Klassen usw. haben dann sogar die meisten Universitäten davon überzeugt, sie exklusiv zu unterrichten, obwohl sie keine sehr gute Sprache für das Programmieren ist.

Das Ergebnis war Popularität. Geld kann viele Probleme lösen.

Auf dem Gebiet der funktionalen Sprache können wir sehen, dass Haskell immer beliebter wird. Ich denke, der größte Teil der Popularität ist auf Leute wie Dons zurückzuführen, die nützliche Bibliotheken schreiben und nie aufhören, die Sprache zu vermarkten. Jeden Tag sehen Sie ein paar Haskell-Artikel über die Programmierung von Reddit. Dies hält es in den Köpfen der Menschen fest, bis sie schließlich entscheiden: "Ich werde es mit Haskell versuchen." Dabei sehen sie nützliche Dinge wie Web-Frameworks, Objektdatenbanken, OpenGL-Bibliotheken und XML-Verarbeitungsbibliotheken. Dies bedeutet, dass sie tatsächlich "im Augenblick" etwas Nützliches tun können. Haskell hat also zwischen dem Potenzial, produktiv zu sein und viel davon zu hören, eine Menge an Popularität gewonnen.

CL hat viele der gleichen Bibliotheken wie Haskell und ist fast so schnell, aber niemand spricht darüber, so dass es sich "tot anfühlt". In der Tat ist #lisp viel leiser als #haskell, aber Lisp ist immer noch eine sehr produktive Sprache mit vielen Bibliotheken. Keine andere Sprache hat SLIME. Aber Marketing ist sehr wichtig und Haskell macht es besser als Lisp oder OCaml (und konkurriert um die gleiche Nutzerbasis).

Schließlich werden einige Leute niemals programmieren. Wenn Sie also ihr mentales Modell (Variablen sind Felder mit Werten, Code wird von oben nach unten ausgeführt) brechen, stellen Sie sicher, dass sie Ihre Sprache nicht verwenden. Diese Art von Programmierer stellt einen großen Prozentsatz der Programmierbevölkerung dar, wodurch die mögliche Verwendung abstrakter Sprachen wie Lisp, Haskell und OCaml weiter eingeschränkt wird.

Ich mag OCaml viel als Sprache. ABER...

Die Tools-Unterstützung ist einfach nicht da. Der Debugger funktioniert nur in Ordnung, aber nicht unter Windows (das habe ich zuletzt überprüft), und es sind nicht so viele Entwicklungstools dafür verfügbar.

Das Typensystem ist manchmal etwas zu stark. Für jemanden, der die Funktionsweise von Typinferenz oder das ML-Typsystem im Allgemeinen nicht versteht, ist die Tatsache, dass er einem Gleitkomma keine Ganzzahl hinzufügen kann, eine sofortige Hauptabschaltung.

Die Standardbibliothek kann manchmal ein inkonsistentes Gefühl haben.

Das Objektmodell scheint etwas überfrachtet zu sein, und die Standardbibliothek verwendet es kaum und wählt stattdessen modulbasierte Bibliotheken.

Es gibt viele andere Dinge, die im Grunde genommen dazu führen, dass sich die Sprache nicht "poliert" anfühlt und die Menschen in der sehr kritischen Phase davon abbringen, eine Sprache zu lernen und zu entscheiden, ob sie sie mögen oder nicht.

Ich denke, sein wichtigstes Erbe wird sein, dass es zusammen mit anderen ML-Dialekten einen sehr starken Einfluss auf andere funktionale Sprachen hatte. Die meisten funktionalen Sprachen der aktuellen Generation greifen die besten Elemente der ML-Dialekte auf und verfeinern einige der Ärgernisse.

Eingebettete Systeme erfordern oft zwei Dinge: Geschwindigkeit und Determinismus. OCaml kann Geschwindigkeit liefern, aber die Tatsache, dass es einen Garbage Collector hat, macht es von Natur aus nicht deterministisch und für ein Echtzeitsystem, das so einfach nicht geht.

Dies ist ein Vergleich zwischen Äpfeln und Apfelsinen. OCaml ist eine relativ junge Sprache [1], und es wurden nie ernsthafte und nachhaltige Anstrengungen unternommen, um sie in den Mainstream zu drängen (mit Ausnahme von Microsofts aktueller Arbeit mit F #). Im Gegensatz zu C ist es nicht die Verkehrssprache des am häufigsten unterstützten und imitierten Enterprise-Betriebssystems (dh UNIX). Im Gegensatz zu Java wurde es von keinem großen Unternehmen als Computerplattform der nächsten Generation vorangetrieben. Im Gegensatz zu Perl, Python und Ruby hat es sich nicht in einer einflussreichen Nische etabliert (dh seine Nische ist Programmiersprache und automatisierte Argumentationsforschung - im Vergleich zur Webentwicklung nicht sehr bekannt). Daher ist es nicht sehr beliebt.

[1] Fairerweise gibt es die ursprüngliche ML-Sprache seit den 70er Jahren. Aber OCaml erschien erst 1996 und erbte die Standard ML-Bibliotheken nicht. In der Praxis ist es eine jüngere Sprache als C, C ++, Java, Python, Haskell oder sogar Ruby.

Die OCaml-Community konnte keine große und zuverlässige Standardbibliothek entwickeln (über das hinaus, was heute mit OCaml geliefert wird), die die Anwendungsentwicklung vereinfacht. Es gibt mehrere Versuche, das Problem zu lösen, aber werfen Sie einen Blick auf Python oder Ruby, um festzustellen, was fehlt. OCaml ist eine großartige Sprache, wenn Sie ein algorithmisches Problem lösen möchten, das nicht zu sehr von der Interaktion mit erweiterten Standardmodulen wie XML, Netzwerkbetrieb, Datenberechnung usw. abhängt, die Sie lieber nicht selbst implementieren möchten.

Ich glaube, dass ein Teil des Problems darin besteht, wie Module von OCaml Dateien zugeordnet werden: Konzeptionell befinden sich alle * .ml-Dateien im selben Namensraum, und Verzeichnisse haben keine Bedeutung. Dies macht es einer Community schwer, eine Bibliothek zu entwickeln. Wenn der Compiler Verzeichnishierarchien in Modulhierarchien abbilden würde, hätte ich eine bessere Chance, dass sich eine Standardbibliothek entwickelt. Dies würde jedoch erhebliche Anstrengungen der Core-Compiler-Entwickler erfordern. (Ich bin mir bewusst, dass Module gepackt werden müssen, aber ich halte dies für einen Trick.)

Ein weiteres Bibliotheksproblem ist die Binärkompatibilität zwischen Compiler-Releases. Man kann mit ziemlicher Sicherheit sagen, dass der gesamte Bibliothekscode nach einem Compiler-Upgrade neu kompiliert werden muss. Dies macht es schwierig, binäre Releases von Modulen oder Bibliotheken bereitzustellen.

Wahrscheinlich, weil zu viele Menschen ML als Teil einer Einführung in seltsame und verwirrende theoretische Dinge über Typen gelernt haben. Das ist mir passiert.

Es wurde mir ungefähr zur gleichen Zeit ML und Smalltalk gezeigt. Smalltalk sah einfach nur verdammt cool aus und es war sofort verständlich, wofür OO war und wie man in dieser Umgebung hübsche, interaktive Sachen machen konnte. ML handelte von abstrakten mathematischen Dingen, die für das, was ich tun wollte, nicht relevant zu sein schienen. Und im Gegensatz zu C habe ich nicht versprochen, schnelle Spiele auf 16-Bit-Mikros zu schreiben.

Das ist natürlich zutiefst unfair und subjektiv. Aber das ist wahrscheinlich die wahre Geschichte für die meisten Menschen.

Heutzutage lautet die Frage vermutlich: Jetzt muss ich dieses seltsame und verwirrende theoretische Material über Typen kennen. Warum sollte ich ML statt Haskell oder Erlang wählen?

Ich glaube, dass das Hauptproblem das Fehlen einer tatsächlichen Standardbibliothek ist. Daher Projekt OCaml-Batterien enthalten , was die Situation voraussichtlich weitgehend verbessern wird. Es soll innerhalb weniger Tage in die Beta-Phase eintreten, sodass Sie die Frage in etwa einem Jahr erneut stellen müssen.

Ich bin damit einverstanden, dass eine schlechte Windows-Unterstützung, eine steile Lernkurve und eine schlanke Standardbibliothek die Akzeptanz von OCaml in der Vergangenheit erstickt haben, aber ich möchte hinzufügen, dass es im Vergleich zu gängigen Sprachen wie Java einen riesigen Mangel an Tutorial-Informationen (z. B. Büchern) über OCaml gab.

Auch die Arten von Menschen, die Sprachen wie OCaml beherrschen, sind äußerst heterogen. Unter den Web-Programmierern wird vielleicht 1 von 1.000 von OCaml gehört haben. Unter den Wissenschaftlern der Universität Cambridge sprachen ungefähr 90% der mir bekannten Personen fließend OCaml. In der Tat war ich einer der letzten unter meinen Freunden, die OCaml lernten. Wir haben sogar OCaml auf unserem 256-CPU-Supercomputer ausgeführt ...

Ich sollte auch erwähnen, dass diese Probleme schnell angegangen werden. OCaml hat sich in letzter Zeit mit Projekten wie Ocsigen für die Webprogrammierung neu erfunden und verfügt in diesem Zusammenhang bereits über mindestens zwei große industrielle Erfolgsgeschichten. Es gibt ein weiteres neues Buch über OCaml. Die Community arbeitet an einer umfassenden Standardbibliothek mit dem Namen "batteries included", die gerade in die Beta-Version eingegangen ist und fantastisch aussieht. Eine Multicore-freundliche Version von OCaml wird in Kürze veröffentlicht. Die neueste Version von OCaml enthält auch viele großartige neue Funktionen wie Lazy Patterns und dynamisch geladene OCaml-Bibliotheken mit nativem Code.

Ich denke, ein Teil des Problems ist, dass funktionale Programmierung für die meisten Menschen keine natürliche Denkweise ist (und ich sage dies als jemand, der ein großes Interesse an funktionaler Programmierung hat und diese schätzt). Hinzu kommt, dass die überwiegende Mehrheit der Programmierer heute mit dem Erlernen der prozeduralen Programmierung begonnen hat (die beliebtesten OOP-Sprachen sind immer noch prozedurale Sprachen), sodass es anfangs schwierig ist, funktionale Sprachen anzupassen.

Als ich an der Universität anfing, kannte ich mich bereits gut mit BASIC, C ++ und Java sowie ein bisschen Pascal und x86-Assemblersprache aus. Ich war weit davon entfernt, ein Experte zu sein, hatte aber die (etwas naive) Schlussfolgerung gezogen, dass alle Programmiersprachen im Grunde die gleichen waren und eine etwas andere Syntax hatten. Unsere Einführung in den Programmierkurs verwendete ML, was mich schnell von dieser Vorstellung ablenkte. In dieser Phase meiner Programmierkarriere hatte ich Probleme, mich mit ML zu beschäftigen, und konnte den Sinn der funktionalen Programmierung nicht wirklich erkennen. Ich denke, es braucht ein bisschen mehr Erfahrung mit einigen Problemen der prozeduralen Programmierung, um die Vorteile eines funktionalen Ansatzes wirklich zu würdigen.

Unser ML-Dozent behauptete oft, dass das rekursive Ausdrücken von Problemen „natürlicher“ und einfacher sei als die Verwendung von Schleifen oder anderen prozeduralen Konzepten. Ich war nie von dieser Behauptung überzeugt und kaufe sie immer noch nicht. Rekursive Funktionen können manchmal besonders elegante und prägnante Problemlösungen bieten, aber ich finde es immer noch unnatürlich, über Probleme nachzudenken. Wenn Sie einen sehr starken mathematischen Hintergrund haben, erscheint dies vielleicht intuitiver, aber ich denke, dass es für die meisten Menschen nicht einfach ist, rekursiv zu denken. Angesichts der zentralen Bedeutung rekursiver Funktionen für das Paradigma der funktionalen Programmierung ist dies meines Erachtens auch ein Grund für die geringere Beliebtheit funktionaler Sprachen.

Es gibt auch einen Rückkopplungseffekt für die Sprachbeliebtheit. Als ich anfing zu programmieren, wollte ich wissen, wie man grafische Effekte und Spiele programmiert. Nachdem ich ein bisschen BBC BASIC und später QBASIC gelernt hatte, untersuchte ich natürlich, welche Sprachen in der Demoszene und für Spieleprogrammierer am häufigsten verwendet wurden, und begann mit dem Erlernen von C ++ und x86-Assembler. Heutzutage möchten einige neue Programmierer vielleicht wissen, wie man Webanwendungen erstellt, und werden sich daher für das Erlernen von PHP, Ruby oder C # interessieren. Es gibt nur sehr wenige Anwendungsbereiche für selbstmotivierte Programmieranfänger, in denen die Antwort auf die Frage, welche Sprache am besten geeignet ist, um etwas wie X zu programmieren, "Ocaml" lautet.

Viele der praktischen Gründe für die begrenzte Popularität von Ocaml (Mangel an ausgereiften Bibliotheken, Debuggern, IDEs usw.) werden durch die offizielle Unterstützung von Microsoft für F # als erstklassige .NET-Sprache behoben. Es wird interessant sein zu sehen, ob F # dazu beiträgt, die Popularität der funktionalen Programmierung zu steigern.

Ich glaube, der Kern des Problems ist die Politik. Die Ocaml-Entwickler sind hauptsächlich an Recherchen interessiert und verfügen nicht über die Ressourcen, um eine umfangreiche Bibliothek bereitzustellen und zu warten. Sie sind jedoch auch nicht bereit, die Kontrolle über das Produkt an die Community weiterzugeben, die über diese Ressourcen verfügt. Das Ergebnis ist, dass mehrere Versuche, dieses Problem zu lösen, auf nicht existierender Zusammenarbeit und Finanzierung von Bibliotheken von Drittanbietern beruhten und diese Versuche fehlschlugen. Batterien versagen aus demselben Grund, es sei denn, die Ocaml-Entwickler ändern ihre Einstellung.

Ich verwende Ocaml, um mein Produkt zu entwickeln, und ich habe eine einfache Regel: Minimieren Sie die Abhängigkeit von Code von Drittanbietern. Wenn ein Artikel von Drittanbietern nützlich ist, fügen Sie die Quellcodes, wenn möglich, direkt in das Paket ein. Zum Beispiel sind OCS-Schema und Dypgen wesentliche Teile des Felix-Parsers, daher werden sie in unsere Quellen kopiert, damit wir etwas Kontrolle über sie haben. Die Steuerung ist etwas illusorisch (da Dypgen zumindest so komplex ist, ist es unwahrscheinlich, dass wir es warten können, aber zumindest haben wir eine Kopie, von der wir denken, dass sie funktioniert :)

Ich werde keine Batterien verwenden, da die Lizenz einschränkend ist, sodass ich die Quelle nicht kopieren kann, und ich habe kein Vertrauen in die langfristige Funktionsfähigkeit des Produkts als eigenständiges Produkt: Die einzige Möglichkeit, wie ich es verwenden könnte, wäre, wenn es vorhanden wäre direkt in die Standarddistribution von Ocaml integriert.

In der C ++ - Welt könnte ich nur überlegen, Boost zu verwenden: Obwohl es sich um eine Drittanbieter-Bibliothek handelt, die nicht zum Standard gehört, wird sie von der Community stark unterstützt und ist tatsächlich hervorragend mit dem Entwicklungsprozess für Standards synchronisiert. In Boost entwickelte und getestete Ideen werden zu einer Art existierender Praxis, die standardisiert werden kann, und der Standardisierungsprozess ist offen genug, um die Beteiligung der Community zu ermöglichen.

Ocaml hat die Popularität erlangt, die es tatsächlich hat, weil es ein so feines Produkt ist, aber das reicht nicht aus, um es zu einer Mainstream-Sprache zu machen. Java ist gemein, es wurde mit Milliarden von Dollar an Marketing und Bibliotheksentwicklung populär gemacht, aber am Ende musste es für die Community freigegeben werden, um überhaupt zu überleben.

Ich habe es genossen, sowohl in ML als auch in C für eine Vielzahl von Projekten zu programmieren. Die Sache, die mich davon abhält, ML in eingebetteten Projekten zu verwenden (die meisten davon unterliegen Echtzeitbeschränkungen und müssen validiert werden), ist die Garbage Collection.

Es gibt Forschungen zum Speichermanagement mit Regionen (siehe MLKit ), aber die Komplexität der Implementierungen und Schulungen, die erforderlich sind, um sie ordnungsgemäß zu verwenden (und die damit verbundenen Risiken), haben ihre Verwendung behindert.

Meiner Meinung nach liegt ein großes Problem von OCaml nicht in der Sprache (das ist großartig), sondern in den Leuten, die es entwickeln, und folglich in seiner Lizenz:

http://caml.inria.fr/ocaml/license.en.html

Sie verwenden die Q Public Lizenz für den Compiler! Ja, die Lizenz ex-Trolltech für Qt-Bibliotheken! Vergessen Sie jeden Beitrag mit einer solchen Lizenz.

Wenn Sie vor etwa 7 bis 8 Jahren das Language Shootout ( http://shootout.alioth.debian.org/ ) überprüft haben, lag OCaml hinsichtlich der Ausführungsgeschwindigkeit direkt hinter C und C ++. In der Zwischenzeit haben andere Sprachen (wie Haskell) einen besseren Compiler (vermutlich aufgrund eines anderen Community-Ansatzes) und jetzt ist die Ausführungsgeschwindigkeit von OCaml nicht mehr so ​​hoch wie in der Vergangenheit.

Kurz gesagt, ich würde OCaml nicht verwenden, weil ich es nirgendwo besser finden würde, wenn nicht einige wirklich gute Hacker einen OCaml-Compiler erstellen würden, der über eine REAL Open Source-Lizenz und eine Community mit einem REAL Open Source-Verhalten verfügt.

Nun, wenn es um Geld geht, wie @jrockway sagt, werden wir sehen, ob F # die Popularität von Java oder C # gewinnt.

Ich denke, Entwickler fühlen sich mit der funktionalen Arbeitsweise nicht wohl (das geht aus der F # -Sitzung der Techdays 2009 hervor, in der etwa 10 Personen angaben, dass sie sich mit funktionaler Programmierung unter fast 100 Personen auskennen).

Ich habe dieses Jahr mit OCAML angefangen. Ich habe mich noch nie mit funktionaler Programmierung beschmutzt, aber jetzt lerne ich wirklich immer Neues von OCAML und der funktionalen Art, Probleme zu lösen (aber ich kann nicht sagen, dass ich C # aufgeben werde). OCAML benutzen :)).

Nun, vielleicht wird F # populär.

Es hilft nicht, dass c-> ocaml ein größerer mentaler Übergang ist als c-> lisp. Ich habe ein paar Mal darüber nachgedacht, und immer festgestellt, dass das Kosten-Nutzen-Verhältnis einfach nicht für mich da war, also lege es wieder beiseite. Es waren nicht die Konstrukte, die es hart aussehen ließen, die sahen wirklich gut aus. Es wurde versucht, eine ganz andere Bedeutung für '!' Zu lernen. Zumindest sieht Lisp so anders aus, dass es leicht zu vermeiden ist, kleine Teile davon falsch zu interpretieren als c.

Wenn Sie eine Sprache in eingebetteten Echtzeitsystemen verwenden möchten, benötigen Sie Zeiger und können sich keinen GC leisten.

Ich denke, der Hauptgrund ist, dass zu wenige Entwickler OCaml kennen.

Und wenn ich mit anderen Entwicklern spreche (diejenigen, die etwas über Ocaml gehört haben), habe ich immer den Eindruck, dass sie OCaml als eine "Nur-Bildung" -Sprache betrachten ... traurig, aber wahr

Ich mag O'caml sehr ... Ich habe eine Menge Dinge damit implementiert, Compiler, Interpreter, System, um mit C zu kommunizieren ...

Als ich es lernte, war das Hauptproblem, dass die Fehlermeldungen nicht wirklich klar waren ... also war ich mir am Anfang nicht sicher, wann ich sie setzen sollte ';' und das war wirklich schwer zu finden, dass tatsächlich die; wurde verlegt ...