type t (* void *)

ソフトウエアのこととか

プログラミング: パラダイムの話って良くわからないんですよね

小さな問題を分からないといい続けないでさっさと目の前の問題を解けという声が聞こえる。

パラダイムの議論がしっくりこない

よく言われるやつ。

手続き型プログラミング

計算機の内部構造の延長線上にある、アセンブリ言語を構造化したプログラミングスタイル

オブジェクト指向プログラミング

オブジェクトのメッセージ受け渡しにより処理を記述するプログラミングスタイル。
良くインターフェイスと実装の分離、みたいな利点が言われるけどメッセージパッシングがOOPの本質だとしてどこからインターフェイスの話がでてくるの?*1

関数型プログラミング

関数を最小単位として、小さな式を組み合わせて大きなプログラムを書くパラダイム*2。こういった対比では、それはOOPでも一緒じゃね?と言われたりするので、「できるだけ副作用を抑えるプログラミングスタイル」と説明したりするが副作用があるとインスタンスを複数作れないので不便で、その副産物だと思う。

ジェネリックプログラミングの方法の違いという意味ならわかる

どういう風にジェネリックな(データ型に依存しない)プログラミングを行ってきたのかという話ならまぁ分かる気がする。

パラメトリック多相

'a -> 'aみたいなやつ。 この多相性を利用すると'aの内容に依存した処理が書けない+値制約のおかげで必然的に副作用抑えめになる。今の所謂OOP言語にはだいたい有るけど歴史的に関数型プログラミングしていた人たちが活用していたよね。

継承を使った方法

interfaceを継承して違う関数を同じ名前でアクセスする。密結合なコードが簡単にかけて便利。OCamlとかにもある。

MLのfunctorを使った方法

モジュールを受け取ってモジュールを返すfunctorを使ったプログラミング。

型クラス

Ad-hoc多相を一般化するための方法。インターフェイスとしても使えるのでは。

結論

気持ちの問題だけどジェネリックプログラミングを実現する方法で整理すると納得度が上がりました。 ちなみに副作用を抑えるプログラミングスタイルのこともImmutable programmingとか名前つけて議論することも出来る気がするけどこの対比構造には入れられないね。Actorモデルを使った並列プログラミング手法もパラダイムと呼んで良いものな気がするけどそれもパラダイムとかプログラミングスタイルって呼んでいくのかな。

*1:インターフェイスと実装の分離は良いことだと思ってますが別にCで実装とヘッダーファイルを真面目に書いたりMLのmoduleプログラミングでも同じことが普通に起きます

*2:プリミティがあったりするがまぁ言語の意味論的には関数だと思って考えたら良いのでは