- 関数型プログラミングと静的保証を重視する開発者が、複数の言語を経験した末に OCaml のバランスの取れた設計を高く評価
- Haskell の 複雑な型システムと遅いコンパイル速度と比べて、OCaml は単純さと実用性をあわせて提供
- Go の 高速なコンパイルと簡潔なランタイムに似ているが、関数型言語の パターンマッチング・代数的データ型 といった強みを維持
- 高速なビルド、静的バイナリ、充実したドキュメントツール（odig、utop） により、生産性とアクセスのしやすさが高い
- 単純さと表現力の バランス、そして洗練された言語設計が OCaml の最大の魅力として示される
プログラミング言語の経験と比較
- さまざまな言語でアマチュアおよびプロフェッショナル向けソフトウェアを開発した経験を通じて、良い言語の特徴を整理
- 高速なコンパイル速度、単純なランタイム、強い静的保証、関数型の構成要素、優れた性能、ドキュメント品質を重要な要素として提示
- Haskell は関数型プログラミングの考え方を身につける助けになったが、複雑な文法と遅いコンパイルが問題として指摘される
- コミュニティの 複雑性を追求する傾向 や space leak のようなランタイム問題により、保守が難しい
- Go は単純さ、高速なコンパイル、優れたツール群、簡潔なコード理解を可能にする
- しかし 保守的な設計、冗長なエラー処理、明示的な null チェックの欠如 により、バグが発生しやすく不便
- REPL の不在と、関数型のアイデアに対する否定的な姿勢も限界として挙げられる
OCaml の主な強み
- OCaml は上記の基準をほとんど満たす言語として評価される
- 強い静的保証: 代数的データ型、多相バリアント、パターンマッチングをサポート
- 単純なランタイム: ガベージコレクションを使いながらもシステムレベル言語として動作
- 高速なコンパイル速度: Dune ビルドシステムにより Haskell や Rust より高速
- 静的リンクされた単一バイナリの生成 で配布が容易
- 優れたドキュメントツール: odig（オフライン文書の閲覧）、utop（REPL）、インターフェース・実装ファイルの分離構造
- 自動型推論 機能によりコード記述の効率が向上
- インターフェースファイルに型を定義する構造が、明確なコード探索に役立つ
言語設計と印象
- OCaml は古い言語だが 洗練された設計感覚 を保っている
- 一部の オブジェクト指向機能 や複雑なライブラリは不要だと評価
- 全体として 単純さと表現力のバランス、優れたドキュメントとツールのエコシステム が OCaml の中核的な魅力
- 著者は「単純だが表現力のある言語」として OCaml を高く評価し、他の言語では得がたい満足感に言及
1件のコメント
Hacker Newsのコメント
OCamlを少し使ってみたが、いろいろ問題があった。
Windowsサポートがひどい。OCaml 5になってようやく「かなり悪い」程度まで改善された。
文法は人間にとって読みづらく、構文エラーになると1文字間違えただけでも1000行のエラーが出る。
Ocamlfmt は複雑な
match文まで1行にしてしまい、可読性が落ちる。ドキュメントも簡潔すぎて、例がほとんどない。
OPAM は理論上は良さそうだが、実際にはバグが多く、32個以上のUnixグループに所属していると
curlを見つけられないバグまであった。関数シグネチャの型注釈が任意なので、静的型付けの利点が薄れる。
エコシステムも小さく、ファイルコピーですら組み込み関数がない。
単方向連結リストへのこだわりも非効率的だ。
それでもCやPythonよりはましだが、Rust より優先して選ぶことはなさそう。
CLRをターゲットにしているのでデプロイがずっと簡単で、.NETエコシステムをそのまま活用できる。
C#やVB.NET向けのNuGetライブラリをほぼそのまま使えるので、エコシステムが非常に大きい。
F#のドキュメントはずっと充実していて、例も多い。
参考リンク: F# 言語リファレンス, F# Core Docs, F# Cheatsheet
curlバグが本当にあるのか気になって調べたが、issue #5373 で確認できた。実際には musl 関連の問題で、OPAMがそのバイナリでビルドされていたことで起きた現象だった。
ocamlformatは janestreetプロファイルに設定すると、デフォルトよりかなり良くなる。関数シグネチャの型注釈の問題は
.mliファイルを提供すれば解決するが、たいていはそうしていない。その代わり、VS Code向けOCamlプラグインは初心者にとって最高の体験を与えてくれる。
今どきのハードウェアでは、基本コレクションは vector であるべきではないかと思う。
以前は ocaml.org から直接インストールすらできず、mingw や wsl を経由する必要があった。
だから実質的にはWindows向けOCamlは存在しなかったようなものだ。
Goの言語設計者たちが関数型プログラミングの発想をほとんど取り入れなかった理由は明確だ。
Rob Pike の言う通り、Googleの開発者の多くは若くてC系言語に慣れた人たちで、簡単に学べる言語が必要だった。
関数型言語への発想の転換には時間がかかるため、Goはそのコストを避けようとした。
「ML」という単語を見るたびに今でも胸が高鳴るが、Meta Language ではなく Machine Learning のことだと気づいてがっかりする。
最近は「AI」という言葉が乱用されているのがもっと嫌だ。
本物の AGI が出るまではAIという言葉を使わないでほしい。
Richard Feldman の 講演 を見ると、関数型言語が一般化しなかった理由がよく説明されている。
プラットフォーム独占の言語であるか、キラーアプリがあるか、莫大なマーケティング資金が必要だ。
Pythonが急成長した理由も、AIエコシステムの中心言語になったからだ。
私もOCamlで関数型を学び、HaskellやZigでプロジェクトをやってみたが、結局は「使える道具を使う」という現実に戻ってくる。
OCaml、Rust、Haskellは「学びたい言語」としては人気があるが、「実際に広く使われている言語」ではない。
TorchはもともとLuaベースで、すでに人気の高かったPythonへ移っただけだ。
FP陣営は現実の技術変化に無関心で、その間に C, Pascal, Perl, Tcl のような言語が市場を取っていった。
結局FPは「大聖堂の中の司祭たち」にとどまり、命令型言語が大衆を得た。
F#を使ってみたが、Actorベースの並行性は理解しやすかった。
ただ、mutable Array が出てくると複雑になった。
実務でOCamlをF#より好む理由が気になる。
一方のOCamlは グローバルロックの除去、高速コンパイル、モジュール・GADT・エフェクト のような強力な機能を備えている。
F#は依然としてWindowsサポートやSIMD、アンボックス型で優位だが、OCamlも徐々に追いつきつつある。
ライブラリは多いが、その大半は F#らしくない。
OCamlのほうが ネイティブエコシステム は大きい。
C#との相互運用性は良かった一方で、C#からF#ライブラリを使うのは悪夢だった。
結局C#のシェルを残すことになり、コードベースが混成になってしまう。
.NETエコシステムは豊富だが、OOP中心の発想が強く、FPスタイルと衝突する。
Visual Studioは便利だが、CLIベースのワークフローには不向きだ。
コンパイル速度はだんだん遅くなり、テストもぎこちない。
OCamlを使ってみると、言語の人間工学的な設計がずっと自然だと感じる。
F#は「OCaml for .NET」と呼ばれるが、実際には ML系言語にすぎず、ほとんど別の言語だ。
OCamlは古い言語なのでOOP機能は削ってもよさそうだが、Standard ML のほうがより完成度が高いと思う。
構造的型付けのレコードや open recursion、
Js_of_ocamlのようなJSバインディングに役立つ。レコード更新もサポートしていないので不便だ。
OCamlは2000年代初頭からずっと「ほぼ完璧な言語」だった。
だが、摩擦要因が解消されるころには、すでに他の言語がその発想を取り込んでいた。
学ぶ人は少ないが、学んだ人はみな新しい言語を作る。
出典
すでに多くのプロジェクトがOCamlでうまく動いているし、
エフェクトシステムまで追加されて、むしろさらに先に進んでいる。
人気と実力は別物だ。
人気 ≠ 優秀さ であり、音楽でも同じだ。
トレンドと惰性で決まるにすぎない。
よく使われる言語ほど嫌う人も多く、
なじみのない言語ほど過大評価されやすい。
OCamlの人気が低いのは、その効率を実感する ユーザー層が小さいから だ。
そしてFP陣営の 教条的な態度 も一因になっている。
Elixir はOCamlに似ていながら、より一般化の可能性がある言語だと思う。
不変性、パターンマッチ、Actorモデル などFPの利点を備え、
BEAMランタイム 上で安定して動く。
静的型付けはないが、段階的型検査の導入が進んでいる。
.NETエコシステムをそのまま使えるのに、OCamlより知名度が低い。
実際にSaaSバックエンドで使っている会社も多い。
そのためFP言語は依然として主流ではない。
OCamlは GCベースのシステム言語 という点でGoに似ている。
手動メモリ管理や borrow checking よりGCを好む。
D言語のGCも優れていたが、「GC」という言葉そのものが人々を怖がらせたのが問題だった。