私は常にCであることを聞いた組み込みシステム、または最大速度で実行する必要がある何のために使用する選択した言語。主にポインター演算が好きではなく、言語がアセンブラーの上のラングにすぎないため、私はCが好きではありませんでした。
一方、ML言語は機能的で、ガベージコレクションされた言語であり、OCamlにはオブジェクトモデルさえありますが、Cと同じくらい高速であるという評判があります。ML言語は、高レベルで簡潔なコード、それでも高性能アプリケーションを書くために必要な速度を保持します。
特にOCamlは、組み込みデバイス、グラフィックスドライバー、オペレーティングシステムなど、Cが従来使用されていた場所ならどこでも使用できます。すべての権利により、OCamlは今までに世界を支配していたはずですがそれを使用しました。
これは主観的な質問ですが、なぜOCamlやMLの他の言語はそれほどあいまいなままで、Cや他の言語が普及したのでしょうか？
回答:
最初の答えは、言語が人気を博した理由を誰も実際には知らず、そうでないと言う人はだまされているか、アジェンダを持っているということです。（多くの場合、言語が普及しない理由を特定するのは簡単ですが、それは別の質問です。）
その免責事項で、最も重要な最初の示唆的なポイントがあります：
最初の成熟したCコンパイラは1974年に登場しました。最初の成熟したOCamlコンパイラは1990年代後半に登場しました。Cには25年の有利なスタートがあります。
CにはUnixが付属しており、これは史上最大の「キラーアプリ」でした。長い間、世界中のすべてのCS部門にはUnixが必要でした。つまり、すべてのインストラクターとCSコースを受講する全員がCに触れる機会がありました。OCamlとMLはまだ最初のキラーアプリを待っています。（MLdonkeyはクールですが、Unixではありません。）
Cはそのニッチを非常にうまく埋めているので、システムプログラミング専用の別の低レベル言語が存在することはないでしょう。（好意的な証拠を見るには、HOPL IIのCの歴史に関するDennis Ritchieの論文を読んでください。）OCamlのニッチが何であるかさえ明確ではなく、Standard MLのニッチは少しだけ明確です。したがって、CamlとMLにはかなりの数の競合他社がいますが、Cはその唯一の競合他社（BLISS）を殺しました。
Cの大きな強みの1つは、そのコストモデルが非常に予測可能であることです。Cコードの小さな断片を簡単に見ることができるため、そのコードを実行するために実行する必要のあるマシン操作を正確に把握できます。OCamlのコストモデルは、特にメモリ割り当てのために、あまり明確ではありません。明示的ではなく、メモリ割り当ての全体的なコスト（割り当てコストとガベージコレクション中に発生するコストに等しい）は、オブジェクトの存続期間や他のオブジェクトを参照するオブジェクトなどの緊急プロパティに依存します。最終的な結果として、パフォーマンスを予測することは困難であり、事後に分析することさえ困難です。（OCamlのメモリプロファイリングツールは本来あるべきものではありません。）その結果、OCamlは、組み込みシステムのようにパフォーマンスを非常に予測可能でなければならないアプリケーションには適していません。
Cは、標準および多くのコンパイラを備えた言語です。OCamlはソフトウェアアーティファクトです。唯一のコンパイラは単一のソースからのものであり、コンパイラは標準です。そして、その標準はリリースごとに変わります。安定性と後方互換性を重視する人々にとって、単一ソースの言語は受け入れがたいリスクになる可能性があります。
中途半端な学部コンパイラコースと多くの永続性を持つ人はだいたい動作し、適切なパフォーマンスでCコンパイラを書くことができます。OCamlまたはMLを実装するためには、さらに多くの教育が必要です。また、素朴なCコンパイラに匹敵するパフォーマンスを得るには、さらに多くの作業が必要です。これは、OCamlのような言語をいじり回す愛好家がはるかに少ないことを意味します。したがって、コミュニティがそれを悪用する方法について深い理解を深めることは困難です。
OCamlの問題は、「箱から出してすぐに」あまり便利ではないことだと思います。人々が言語を使用する最終的な理由は、必要なライブラリがあるためです。しかし、「箱から出してすぐに」何もなければ、ライブラリに書き込む必要があることを理解するのに十分なほどプロジェクトに踏み込む人はいません。その結果、ライブラリのない言語となり、「本物のアプリ」を書くことが難しくなります。
これはOCamlが苦しんでいることだと思います-プログラミング言語がすべてあるので、だれも「実際のプロジェクト」を開始することを気にしません。はい、2つ追加して結果を印刷できます。その結果、ほとんどがアカデミックな放棄されたライブラリのコレクションが作成され（著者は博士号を取得し、次の段階に進みました）、プログラマーの練習にはあまり役立ちません。
（「Batteries Included」のようなプロジェクトで、これを変更する作業が進行中であることは知っています。5年後にここに戻ってください。おそらくOCamlがもっと普及するでしょう。）
この規則にはいくつかの例外があります。Javaはライブラリなしで開始されましたが、Sunはそれらをすべて社内で作成するために人々に支払い、それから彼らはそれから地獄を売り出しました。Java認定、Java固有のハードウェア、Javaブック、Javaクラスなど。プログラミングの学習に使用するのにあまり適した言語ではありませんが、ほとんどの大学にそれだけを教えるよう説得しました。
結果は人気でした。お金は多くの問題を解決できます。
関数型言語の分野では、Haskellが非常に人気を博していることがわかります。人気の大部分は、便利なライブラリを書くドンのような人々によるものであり、言語のマーケティングをやめることはないだろうと思います。毎日、Redditのプログラミングに関するHaskellの記事をご覧ください。これにより、「Haskellを試してみる」と最終的に決定するまで、人々の心にとどまります。実行すると、Webフレームワーク、オブジェクトデータベース、OpenGLライブラリ、XML処理ライブラリなどの便利なものが表示されます。これは、彼らが実際に「今すぐ」役に立つ何かをすることができることを意味します。そのため、生産性の可能性とそれについて多くのことを聞くことの間で、Haskellは多くの人気を得ています。
CLにはHaskellと同じライブラリが多数あり、ほぼ同じ速度ですが、誰もそれについて語っていないため、「死んでいるように感じます」。実際、＃lispは#haskellよりもずっと静かですが、Lispは依然として多くのライブラリを備えた非常に生産的な言語です。他の言語にはSLIMEがありません。しかし、マーケティングは非常に重要であり、HaskellはLispやOCamlよりも優れています（同じユーザーベースで競合しています）。
最後に、一部の人々はプログラミングを「取得」しないため、メンタルモデル（変数は値を持つボックスであり、コードは上から下に実行されます）を破ると、言語を使用しないようになります。このタイプのプログラマーはプログラミング人口の大部分を占めているため、Lisp、Haskell、OCamlなどの抽象言語のユーザーベースをさらに制限します。
OCaml は言語としてとても好きです。しかし...
ツールのサポートはありません。デバッガーは問題なく動作しますが、Windowsでは動作せず（最後にチェックしました）、利用可能な開発ツールはそれほど多くありません。
その型システムは、時々少し強すぎます。型推論の仕組みやML型システムの一般的な仕組みを理解していない人にとって、整数をフロートに追加できないという事実は、すぐに重大な転換点になります。
標準ライブラリでは、一貫性のない感じがする場合があります。
オブジェクトモデルはやや固定されているようで、標準ライブラリはほとんど使用せず、代わりにモジュールベースのライブラリを選択します。
基本的に「洗練された」と感じない言語に相当し、言語を拾い、それが好きかどうかを判断しようとする非常に重要な時期に人々を追い払うものが他にもたくさんあります。
その最も重要な遺産は、他のML方言とともに、他の関数型言語に非常に強い影響を与えていることだと思います。現在の世代の関数型言語のほとんどは、MLの方言から最高の要素を取り入れて、いくつかの煩わしさを改善しています。
組み込みシステムでは、多くの場合、速度と決定性の2つが必要です。OCamlは速度を提供できますが、ガベージコレクターを備えているため、本質的に非決定的であり、単純なリアルタイムシステムでは実現できません。
これは、リンゴとオレンジの比較です。OCamlはかなり若い言語[1]であり、これを主流に押し込むための真剣で持続的な努力はこれまでありませんでした（MicrosoftのF＃に関する現在の作業を除く）。Cとは異なり、最も広くサポートおよび模倣されているエンタープライズオペレーティングシステム（UNIXなど）の共通語ではありません。Javaとは異なり、次世代のコンピューティングプラットフォームとして推進している大手企業はありません。Perl、Python、Rubyとは異なり、注目を集める影響力のあるニッチ（つまり、そのニッチはプログラミング言語と自動推論の研究であり、Web開発に比べてあまり注目されていません）には定着していません。したがって、それは超人気ではありません。
[1]公平に言うと、元のML言語は70年代から存在しています。しかし、OCamlは1996年まで登場せず、標準MLライブラリを継承しませんでした。実際には、C、C ++、Java、Python、Haskell、さらにはRubyよりも新しい言語です。
OCamlコミュニティは、アプリケーション開発を容易にする大規模で信頼性の高い標準ライブラリ（現在のOCamlに付属しているものを超える）の開発に失敗しました。問題を解決する試みはいくつかありますが、PythonまたはRubyを見て、何が欠けているのかを確認してください。OCamlは、XML、ネットワーク、データ計算などの高度な標準モジュールとのやり取りにあまり依存しないアルゴリズムの問題を解決したい場合に最適な言語です。
問題の一部は、OCamlによるモジュールのファイルへのマッピング方法にあると考えています。概念的には、すべての* .mlファイルは同じ名前空間に存在し、ディレクトリには意味がありません。これは、コミュニティがライブラリを進化させるのを困難にします。コンパイラがディレクトリ階層をモジュール階層にマップすると、標準ライブラリが進化する可能性が高くなります。ただし、これにはコアコンパイラ開発者による相当な努力が必要です。（モジュールの梱包については知っていますが、これは手間だと思います。）
別のライブラリの問題は、コンパイラリリース間のバイナリ互換性です。コンパイラのアップグレード後にすべてのライブラリコードを再コンパイルする必要があると言うのは非常に安全です。これにより、モジュールまたはライブラリのバイナリリリースを提供することが難しくなります。
おそらく、型についての奇妙で混乱している理論的なものの紹介の一部としてMLを教えられた人が多すぎたからでしょう。それが私に起こったことです。
私はMLとSmalltalkをほぼ同時に見せられました。Smalltalk はとてつもなくクールに見え、OOの目的と、この環境できれいでインタラクティブなものを作成する方法をすぐに理解できました。MLは、私がやりたいこととは関係がないように思える抽象的な数学的なことについてでした。また、Cとは異なり、16ビットマイクロで高速ゲームを書くことを約束しませんでした。
もちろん、これは深く不公平で主観的です。しかし、それはほとんどの人にとって本当の話になるでしょう。
最近、質問は次のようになると思います：型に関するこの奇妙で混乱した理論的なことを知る必要があると感じていますが、なぜHaskellやErlangよりもMLを選ぶのでしょうか？
主な問題は、実際の標準ライブラリが不足していることだと思います。したがって、プロジェクトOCaml Batteries Includedを使用すると、状況が大幅に改善されることが期待されます。数日以内にベータフェーズに移行する予定なので、1年程度で再度質問する必要があります。
貧弱なWindowsサポート、急な学習曲線、スリムな標準ライブラリはすべて、過去のOCamlの普及を阻んでいたことに同意しますが、Javaなどの主流言語と比較してOCamlに関するチュートリアル情報（書籍など）が非常に不足していることを付け加えます。
また、OCamlのような言語を知っている人々は、非常に異質です。Webプログラマーのなかで、OCamlを聞いたことがある人は1,000人に1人でしょう。ケンブリッジ大学で科学コンピューティングを行っている人のうち、私が知っている人の約90％はOCamlに堪能でした。実際、私は友人の中でOCamlを学ぶ最後の一人でした。256 CPUのスーパーコンピューターでOCamlを実行しました...
また、これらの問題が急速に対処されていることにも言及する必要があります。OCamlは最近、OcsigenのようなプロジェクトでWebプログラミングのために再発明し、そのコンテキストで少なくとも2つの主要な産業の成功事例をすでに持っています。OCamlに関する別の新しい本が今出ています。コミュニティは、「バッテリー付属」と呼ばれる包括的な標準ライブラリで共同作業を行っており、ベータリリースに移行したばかりで、見た目も素晴らしく見えます。OCamlのマルチコア対応バージョンがリリースされようとしています。OCamlの最新バージョンには、レイジーパターンや動的にロードされるネイティブコードOCamlライブラリなど、多くの優れた新機能も含まれています。
問題の一部は、関数型プログラミングはほとんどの人にとって自然な方法ではないということだと思います（そして関数型プログラミングに大きな関心と感謝を持っている人として私はこれを言います）。これは、今日、大多数のプログラマーが手続き型プログラミングの学習を始めたという事実（さらに、最も人気のあるOOP言語はまだ中心的な手続き型である）によってさらに複雑になり、関数型言語は最初に調整するのが困難です。
大学に入学したとき、私はすでに合理的な量のBASIC、C ++、Java、および少しのPascalおよびx86アセンブリ言語を知っていました。私は専門家とはほど遠いものでしたが、すべてのプログラミング言語は基本的に同じで、わずかに異なる構文であるという（少し素朴な）結論に達しました。プログラミングコースの紹介ではMLを使用していましたが、この概念はすぐに私を嫌いました。私はプログラミングのキャリアのその段階でMLを理解するのに苦労し、関数型プログラミングのポイントを実際には見ていませんでした。関数型アプローチの利点を本当に理解するには、手続き型プログラミングの問題のいくつかについてもう少し経験が必要だと思います。
私たちのML講師は、問題を再帰的に表現することは、ループや他の手続き概念を使用するよりも「自然」で簡単だとしばしば主張しました。私はその主張に納得しなかったし、それでも買わない。再帰関数は、問題に対して特にエレガントで簡潔な解決策を提供することがありますが、それでも問題を考えるのは不自然な方法だと思います。おそらくあなたが非常に強力な数学的背景を持っている場合、それはより直感的に思えますが、ほとんどの人にとって再帰的に考えるのは簡単ではないと思います。関数型プログラミングパラダイムに対する再帰関数の中心性を考えると、これは関数型言語の人気が低い理由でもあると思います。
言語の人気に対するフィードバック効果もあります。プログラミングを始めたとき、グラフィカルエフェクトとゲームのプログラミング方法を知りたいと思いました。BBC BASICとその後のQBASICを少し学習した後、デモシーンとゲームプログラマーが使用する最も一般的な言語が何であるかを自然に調査し、C ++およびx86アセンブリの学習について設定しました。最近では、一部の新しいプログラマーはWebアプリケーションの作成方法を知りたいと思うかもしれないので、PHP、Ruby、またはC＃の学習に引き寄せられます。「Xのようなものをプログラムすることを学ぶのに最適な言語は何か」に対する答えが「Ocaml」になるような、やる気のある初心者プログラマー向けのアプリケーション領域はほとんどありません。
Ocamlの限られた人気（成熟したライブラリ、デバッガー、IDEの欠如など）に与えられた実際的な理由の多くは、MicrosoftがF＃を第一級.NET言語として公式にサポートすることで解決されています。F＃が関数型プログラミングの人気を高めるのに役立つかどうかは興味深いでしょう。
問題の核心は政治だと思います。Ocaml開発者は主に研究に興味があり、豊富なライブラリを提供および維持するためのリソースを持っていません。しかし、これらのリソースを持っているコミュニティに製品の制御をリリースすることも望まないため、この問題を解決するためのいくつかの試みは、存在しない協力とサードパーティライブラリの資金調達に依存し、これらの試みは失敗しました。Ocamlの開発者が態度を変えない限り、バッテリーは同じ理由で故障します。
私はOcamlを使用して製品を開発していますが、単純なルールがあります。サードパーティのコードへの依存を最小限に抑えます。サードパーティのアイテムが有用な場合、可能な限り、ソースコードをパッケージに直接組み込みます。たとえば、OCS SchemeとDypgenはFelixパーサーの重要な部分であるため、ソースにコピーされるため、それらをある程度制御できます。コントロールはやや幻想的です（少なくともDypgenは非常に複雑であるため、それを維持することはできませんが、少なくとも、動作していると思われるコピーがあります:)
ライセンスには制限があるため、バッテリーは使用しません。そのため、ソースをコピーすることはできません。 Ocamlの標準ディストリビューションに直接組み込まれています。
C ++の世界では、Boostの使用を検討することもできます。これは、標準の一部ではないサードパーティライブラリですが、コミュニティからの強力なサポートがあり、実際には標準の開発プロセスと見事に同期しています。Boostで開発およびテストされたアイデアは、標準化できる既存のプラクティスの一種になり、標準化プロセスはコミュニティへの参加を可能にするほどオープンです。
Ocamlは非常に優れた製品であるため、実際に人気を博していますが、それが主流言語になるには十分ではありません。Javaは無慈悲で、数十億ドルのマーケティングとライブラリ開発で人気を博しましたが、結局生き残るためにはコミュニティにリリースする必要がありました。
私見、OCamlの大きな問題は言語ではなく（それは素晴らしい）、それを開発する人々、そして結果として彼のライセンスにあると思います：
http://caml.inria.fr/ocaml/license.en.html
コンパイラーにはQ Publicライセンスを使用します！はい、元TrolltechがQtライブラリに使用したライセンスです！そのようなライセンスで貢献を得るのを忘れてください。
7〜8年前にLanguage Shootout（http://shootout.alioth.debian.org/）をチェックしていた場合、OCamlは実行速度の点でCとC ++に少し遅れていました。その間、他の言語（Haskellなど）はより優れたコンパイラーになりました（異なるコミュニティアプローチのせいだと思います）。現在、OCamlの実行速度は過去ほど高くありません。
すぐに、私はOCamlを使用しません。なぜなら、本当に優れたハッカーが、本当にオープンソースライセンスを持ち、本当にオープンソースの振る舞いを持つコミュニティを作成するOCamlコンパイラを作らない限り、どこにもうまく行かないからです。
@jrockwayが言うようにお金に関するものであれば、F＃がjavaやC＃のような人気を獲得するかどうかがわかります。
私にとって、開発者は物事の機能的な方法に不快感を覚えていると思います（2009年のtechdaysのF＃セッションでは、約10人がほぼ100人で機能プログラミングを知っていると言っています）。
今年OCAMLを始めました。関数型プログラミングに手を汚したことはありませんが、OCAMLと問題を解決する関数型の方法から常に新しいことを学んでいます（しかし、C＃をあきらめるとは言えません） OCAMLを使用するには:)）。
まあ、F＃が人気になるかもしれません。
c-> ocamlがc-> lispよりも大きな精神的移行であることは役に立ちません。私は何度かocamlを検討しましたが、コスト/メリットは私にとってはそこにないことを常に知っていたので、それを再び取っておきます。見た目を難しくしたのはコンストラクトではなく、実際に見た目がきれいでした。「！」のまったく異なる意味を学ぼうとしていました。少なくともLispは非常に異なって見えるので、Lispの小さな断片をcと誤解するのは簡単です。
言語をリアルタイムの組み込みシステムで使用したい場合、ポインターが必要であり、GCを購入する余裕はありません。