関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違い

国内の不健全な言論環境

本エントリは、後世の記録のために残します。当方の主張の是非については、大げさではなく、長い時系列をもってフェアに判定されることを望みます。
このエントリは、2015年現在の国内における、関数型プログラミングをめぐる言論状況について分析し、広い読者に各自、色付きの情報を公正中立だと勘違いして惑わされないように注意を促し、正しい情報を見極めて理解を推進していただくために投稿します。
2015年現在、日本国内、あるいは少なくとも日本国内のSNS界隈には、ある一定数の人数が集う【自称】「関数型コミュニティ」なるものが存在しています。
【自称】「イスラム国」が、国際社会からは国家として認められていない物騒な存在であるのと同様に、国内SNSで今特に巷で騒がしい自称「関数型コミュニティ」の言説については、国際的なプログラミング界隈の言説とはまったく異なる特異な主張であることに十分に留意しておく必要があります。
もちろん、「特異な主張」というのは無碍に扱ってはなりません。「特異な主張」には発見もあるでしょうし、往々にしてきらめく知性もある「かも」しれません。
しかし、私見や独自見解、あるいは単なるより好みの「特異な主張」をまるで、それが広く世界的にコンセンサスがある「一般論」に見せかけたり、「関数型言語」に関するFAQ形式の一般的説明、と強弁するような事は、多くの学習者へ間違った理解や認識をもたらす行為であるのは言うまでもないことです。
さらに、自分たちの私見や独自見解、あるいは単なるより好みの「特異な主張」こそが正しく、その意向に沿わない見解、主張、意見を封じようと試みる行為が正当化されて当然という風潮が醸成されると、これはもう言語道断です。
そしてこれが今、日本国内の関数型プログラミングの言論界隈で起こっていることです。
【自称】関数型コミュニティの横暴な振る舞いによって、関数型プログラミングに取り組む数多くの識者、学習者、初心者は、恐れおののき、この辺のトピックについては腫れ物に触るように口を閉ざしてしまいました。
「めったなことを言うのはよそう」、ネットスラング系統の表現を使うと、
「この問題に触れるのは【地雷】を踏むようなものだ」といった感じです。
【自称】関数型コミュニティは、なんのことはない、単に自分たちの単なるより好みを、まるでそれが唯一無比の王道であるが如く世間に押し付けて喜んでいるわけです。私は彼らの横暴については学問、学究的な態度と認めることは到底できず、単なる感情的な排他的宗教行為であると見做しています。たまたま冒頭で【自称】「イスラム国」について言及してしまいましたが、まあ根本の思想的行動傾向としては同レベルです。
もうすこし公正にフェアに状況を俯瞰すると、国内の【自称】関数型コミュニティによる見解のようなものは国際的に存在はしているのでしょう。そして往々にして同様の感情的な排他的宗教行為を展開することもある、かもしれません。しかし、それはあくまでひとつの特殊な集団でしょうし、彼ら、一部の特殊な集団による言動が他のすべてを制圧するような愚かな状況には陥っていないことだけは確かです。
ここで「一般的」な国際的な論調と異なる、日本国内の【自称】関数型コミュニティによる独特な特徴とは以下のようなものです。

１．オブジェクト指向に傾倒しており、関数型プログラミングとオブジェクト指向を「マルチパラダイム」というように差異を曖昧にすることでパラダイムの違いを処理し、そもそものパラダイムの差異については認めようとしない。より好みを正当化するために根底の世界観の差異を曖昧にしようとする。
２．関数型プログラミングの根幹である、宣言的プログラミングでなく、命令形プログラミングに何故か執着している。
３．関数型プログラミングの根幹である、宣言的プログラミングと不可分である「遅延評価」でなく「先行評価」のほうを何故か好む。

もちろん、賢明な読者にとっては明白ですが、１から３は全部密接な関係があります。
２に執着するならば、３にも執着するんだろうな、ということですし、３に執着するならば、１に執着して当然なんだろうな、というようなことですね。
たとえば、ですが、前述のエントリでも引用した
らくだの卯之助 @camloeba

関数型言語とオブジェクト指向の研究は両者とも同じ数学的基盤に支えられて行われています。片方で主に知られている研究者がもう片方の学会で発表するのはごく普通の事です。こちらは「λマン」がオブジェクト指向の国際学会に登壇している様子です。
https://www.flickr.com/photos/drjason/280369547/in/set-72157594342576801 …
らくだの卯之助 @camloeba 2015-01-24 02:36:54
@h_sakurai あの方の記事に関数型言語を良く知らない人が流れ込んで、あそこから得体の知れない何かを得ているのを複数観測しました。私はそれを出来るだけ止めたい。これはマズいという記事は消えて頂くかそれとも順位が下がってもらいたいが、そのために火事場するのは逆効果です

例の「焚書」行為に(実際にそのように働きかけたことは確認)勤しんだことを批判した方ですが、Qiitaでは、当方のアカウント停止行為があった後、当方にあてつけて「粛清したい」という言葉遣いもされていたのを見ました。
上記引用のとおり、「関数型言語とオブジェクト指向の研究は両者とも同じ数学的基盤に支えられて行われています。」と、同じ数学的基盤だと強調されています。
プログラミングとはなんであれ詰まるところは数学的行為であるので、あらゆる手法は数学的であるし、数学的に同一基盤、共通項を見いだせてもそれは驚くに値しません。当たり前のことです。
実際このことは、中世そしてルネサンス以後、「天動説」と「地動説」の論争においても、さんざんキリスト教神学者とガリレオ・ガリレイなどの数学者の間でも必ず持ちだされました。
詰まるところ、天体の回転運動なので、いくらでも同じ「数学的基盤に支えられている」と言えるんですね。本質的にはなんら変わらない、単なる数式上座標軸の置き方の違いに過ぎないと。これがガリレオが異端ということで有罪判決を受けてからローマ法王がごく最近に公式に誤りを認め謝罪するまでキリスト教によって３００年くらい延々と正当化されてきた欺瞞的説明の仕方です。
ここでもちろん問題は、「天動説」と「地動説」のようなパラダイムや世界観の違いは、単なる数式上座標軸の置き方の違い、ではない、ということです。関数型プログラミングとオブジェクト指向についてもそれは同様でしょう。
@camloebaというアカウント名でも明白ですが、この人は、
OCamlという関数型、オブジェクト指向のマルチパラダイム言語の愛好者です。
もちろん、プログラマにとって、どの言語を道具にするか？というのは、これこそまさに宗教的より好みと言って過言でない重要な選択であるので、もう、この時点でこの人物の言説には【色】が着いていることを普通に認識して割り引いて評価する心構えが必要です。
さらに、Wikipedia日本語版で、OCamlの項目を見てもわかりますが、
http://ja.wikipedia.org/wiki/OCaml

MinCaml[編集]
MinCamlは、ペンシルベニア大学（当時）の住井英二郎がOCamlで実装した、Caml似のMLの小型版である。同作者により、コンパイラが OCaml 自身で書かれている。MinCaml は、2004年度の未踏ソフトウェア創造事業に採択された。

同様に、前回、独自見解を一般論に見せかけて強弁していると批判した、Eijiro Sumii @esumii氏のお名前が確認できますね。
【自称】関数型コミュニティの中心メンバーとも思える彼らの技術的立ち位置は、けっして中立公正なものではなく、個人のより好みが強く反映された【色つき】のものである、という客観的認識は、広く共有したうえで、一連の騒動は理解されたほうが健全である、と私は考えています。
というより、私は、関数型プログラミングとオブジェクト指向のパラダイムとしての対立について言明することで、この彼らのなんのことはない、単に自分たちの単なるより好みにすぎない、OCaml愛好スタンスとしての関数型、オブジェクト指向のマルチパラダイムの親和性を実質否定した、彼らがより好みする先行評価、命令形よりも遅延評価、宣言型の優位性を主張したというだけで、彼らから延々と「有害」だの「低湿なワードサラダ」だの「キチガイ」だの侮辱、罵倒され続けているわけです。
いや別に良いのですよ、１−３に執着しても。あくまで一個人としてのより好みとしてのスタンスであるのならば。そうではなくて、あたかも１−３が絶対真理であるがごとく他者に押し付け、侮辱し、人格否定までするような真似が愚かであるということです。
以前いただいたメールもひとつだけ引用しましたが、基本的に結構多くの人が、上記のような状況に「論理的」にまったく納得していません。私達は馬鹿ではないのです。「論理的」には納得してはいないが「地雷」であるとの認識が強いので、公に言葉を発することを恐れている人がかなり多いです。だから私の方へ多くのメールが寄せられたりするわけです。
下手なことを発言して、【自称】関数型コミュニティに眼をつけられると、自分も面倒に巻き込まれると恐れているのですね。非常に言論として不健全な状況に今我々はいると感じています。
プログラミングは、本来自由に、無制限な発想が発揮できる、現実世界では稀有な一種の芸術的側面が強い創作的活動分野であり、こういう状況はあってはならないと私は信じています。
メールのひとつで、
関数型プログラミングとオブジェクト指向の抜き差し可能な関係について整理して考える
というブログの論調について質問をいただきました。
以前、私が、
[関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える]
というタイトルで、
「関数型プログラミングとオブジェクト指向のマルチパラダイムである」というのは、
概念的に無理があるので整理するという趣旨でポストした記事を「茶番」として当てつけるタイトルの対抗記事です。
このブログ執筆者による記事の結論的な成果物としては、

さっそく、ObjectのHaskellによる実装を作った。Object型に加え、Objectのインスタンスとして利用するためのユーティリティ関数も備えている。

http://hackage.haskell.org/package/objective
その「思想的背景」としては、

オブジェクト指向の仕組みが、たった一つの型の特殊な場合として表現できるのは、なかなか魅力的ではないだろうか。

ということで、メールのご質問とは、（私の元ネタ記事としての皮肉は横においても）、
岡部はどう考えるか？ということでした。
端的にお返事さし上げたのは
「結構どうでも良い」
「好きなように楽しんでおられるのだし、それがプログラミングの醍醐味なのではないか？」
ということでしたが、この回答にイマイチ満足もされなかったようで、
もう一歩踏み込んだ考察を示しました。
まず、Haskellというのは、有名な関数型言語ですが、
クロージャの機構が他の多くの関数型言語同様に実装されているので、
オブジェクトや、オブジェクト指向のレイヤを整えることなんて（超簡単に）出来て当然である。
それを実装したところで、わざわざ意見が異なる人間の対抗言論としてブログエントリして公開することで「言論的攻撃力、抑止力」として機能しうる！という考えているっぽいのは、まるで理解不能であるし、また、成果物をライブラリとして公開してHaskellコミュニティが評価してくれる、魅力的だと人気を得るとは到底思えない、という旨お返事しました。
何度も繰り返しますが、そもそも、関数型とオブジェクト指向というのは、思想的背景が異なるので、それが技術的に片方がもう片方をエミュレートするレイヤをこしらえようと何にしようと、マルチパラダイムにしようと何にしようと、根本の、そもそもの異なる思想背景からすると本末転倒であるのは論を待ちません。
論を待たないことで、私は個人的にはあくまで、至極当たり前のことを当たり前に論じているだけだと思っているわけですが、そういう当たり前の行為を、いわば「イレギュラー」なより好みをもって、私の主張のほうが異常だ、と強弁する連中が少なくない、ということです。
上記ブログの執筆者は、Twitterアカウントで

ふみ(OOP系Haskeller)
@fumieval
オブジェクト指向の使い手であり、単なる音楽好きでもある

で、「オブジェクト指向の使い手」(OOP系Haskeller)と自己紹介しているわけですが、
まあ普通に、オブジェクト指向から対比的に関数型を論じる私の論調が気に入らないことは、理解できます。非常にわかりやすい感情論のスタンスです。
わかりやすいのは良いのですが、より好みの違いをもって、他人にヘイト行為を展開するのが、この、
【自称】「関数型コミュニティ」なるものの特徴です。
@fumievalはさっそくヘイト行為を流布すべく行動に打って出ました。
関数型プログラミングコミュニティにおける災害

まとめました。
@fumieval
あるQiitaユーザーにより、関数型プログラミングに関して、用語をでたらめに使用した記事が投稿され、Googleの「関数型言語」の検索結果の上位に出たり、記事の内容を実際に信じてしまうなどの被害が出ている。
これらの記事は「ポエム」と呼ばれ批判の的となっている。問題は予想以上に深刻となり、Qiita自体の評価の低下や記事の削除などの騒ぎになる。
補足
2015/1/26現在、元凶であるkenokabe氏はQiitaの利用権限を剥奪され、記事は閲覧できないようになっている(https://qiita.com/kenokabe を参照: “このアカウントはユーザー資格を取り消されています。”)

もちろん、「Qiitaの利用権限を剥奪」っていうのは、こういう人物を中心とした
【自称】「関数型コミュニティ」なるものによる熱心な働きかけの成果であり、
用語をでたらめに使用した、というのも、歪曲誇張された情報であり、
Googleの「関数型言語」の検索結果の上位に出たり、記事の内容を実際に信じてしまうなどの被害が出ている、といういうのも、【自称】「関数型コミュニティ」の縄張り意識、宗教的より好みといいう主観的被害にすぎません。
要するに気に入らない意見を封殺した、ということですね。
Googleの「関数型言語」の検索結果の上位に出たり、記事の内容を実際に信じてしまう、
って、こういうことですか？
関数型とオブジェクト指向のパラダイムが違う、という世界的に当たり前の常識、
関数型言語は宣言型であり、宣言型ならば、当然遅延評価がデフォルトであるべきである（事実Haskellはそうなっている）という常識を信じることはいけないということなのでしょうか？
以上の常識は【自称】「関数型コミュニティ」なるもののメンバーのより好みからすると「気に入らない」事実なのでしょうが、それは彼らが強弁する「一般的」「常識」よりも、確実に、国際的な常識であるわけです。
そんなに、オブジェクト指向が素晴らしくて、先行評価、手続き型・命令形に執着したいのであれば、わざわざ関数型言語なんて無理して使わなければいいのに、と素朴に思うわけで、Haskellが純粋関数型言語で（クロージャでオブジェクトが当たり前に実装できるっていうのはまったく別の話）、デフォルトで遅延評価で、完全に宣言型のコードになるのは、それ相応の理由があってのことです。
関数型とオブジェクト指向のパラダイムが違う、なんてことは、これはもちろん私が「キチガイ」だから、私の独自研究による独自主張で世の中をひっくりかえす妄想として流布している、わけもなくて、どこでも世界中で普通に明言されていることです。
【自称】関数型コミュニティの横暴な振る舞いに抑圧されている方々は、そういう当たり前の常識さえも抑圧されかねない状況にあり、極めて異常な状態がまかり通っている昨今の国内状況であると危惧しています。
いいのですよ？私のように当たり前に正しいことを発言して。
ほんとうのところ、彼らは少数派であり、間違っているのは、特殊でイレギュラーな個人的なより好みを絶対的社会通念がごとく押し付けてくる彼らなのですから。
以下が

広く一般的で国際的な【「関数型言語」に関する一般的説明】です。

①
まず、マイクロソフトのサイトから見てみましょう。

念の為ですが、マイクロソフトから引用するのは、「権威」を拝借したいから、権威主義的説明を試みたいからではありません。一般にマイクロソフトが「権威」であると考える人は居ないでしょう。マイクロソフトというのは、まさに、IT世界で、広い範囲で、どこにでもあるWindowsその他のプロダクトを提供している、一般に馴染の深い国際的な企業であり、その技術的説明も一般的で普遍的であるという観察と前提に基づいています。

関数型プログラミングと命令型プログラミング
関数型プログラミングのパラダイムは、問題解決に適用する純粋関数型の方法をサポートするために、わかりやすく作成されています。 関数型プログラミングは、宣言型プログラミングの一種です。
一方、C#、Visual Basic、C++、Java などのオブジェクト指向プログラミング (OOP) 言語を含むほとんどの主流言語は、主に命令型 (手続き型) プログラミングをサポートするために作成されています。
命令型の方法では、開発者はコードを記述して、目的を達成するためにコンピューターが実行するステップを詳細に示します。 これをアルゴリズム プログラミングと呼ぶこともあります。 一方、関数型の方法では、実行される一連の関数として問題が組み立てられ、 それぞれの関数に何が入力され、何が返されるのかが、慎重に定義されます。 この 2 つの方法の一般的な違いを次の表に示します。

特性	命令型の方法	関数型の方法
プログラミングの焦点	タスク (アルゴリズム) の実行方法と状態の変化の追跡方法。	目的となる情報と必要な変換。
状態の変化	重要。	存在しない。
実行の順序	重要。	あまり重要ではない。
主要なフロー制御	ループ、条件、および関数 (メソッド) 呼び出し。	関数呼び出し (再帰を含む)。
主要な操作単位	構造体またはクラスのインスタンス。	ファーストクラス オブジェクトとしての関数とデータ コレクション。

OOP 開発者向けの移行
従来のオブジェクト指向プログラミング (OOP) では、ほとんどの開発者が命令型/手続き型スタイルのプログラミングに慣れています。 純粋関数型スタイルの開発に移行するには、考え方を切り替えて、開発に適用する方法を変える必要があります。
問題を解決する際、OOP 開発者は、クラス階層を設計し、適切なカプセル化に焦点を絞り、クラス コントラクトの観点から考えます。 何より重要なのはオブジェクト型の動作と状態であり、それに対処するために、クラス、インターフェイス、継承、ポリモーフィズムなどの言語機能が用意されています。
一方、関数型プログラミングでは、計算の問題を、データ コレクションの純粋関数型変換の 1 つの課題として捉えます。 関数型プログラミングでは、状態や変化するデータを避け、関数の適用を重視します。

---

一目瞭然ですが、マイクロソフトのこの解説記事は、
関数型・宣言型プログラミングとオブジェクト指向・命令形（手続き型）プログラミングを、対比的なパラダイムとして解説しています。
またかなり明示的に、OOP 開発者向けの移行、
「考え方を切り替える」、「開発に適用する方法を変える必要がある」ことが論じられています。
この解説が広く一般的です。

②
次に、現在「関数型プログラミング」で検索すると、Google上位にヒットする、英語の記事の翻訳です。
上記マイクロソフト記事と同様に、2015年現在の日本国内の歪な言論状況には影響を受けていません。
【翻訳】2015年の最優先事項は関数型プログラミング！
https://medium.com/@jugoncalves/functional-programming-should-be-your-1-priority-for-2015-47dd4641d6b9

—もはやOOP（オブジェクト指向プログラミング）は”クラウドモンスター”から私たちを守りきれない
おそらくあなたは、”Clojure”、”Scala”、”Erlang”といった言葉や、”Javaにラムダ式が導入された”という話を聞いたことがあるでしょう。そしてそれらの言葉が”関数型プログラミング”と関連があるのをご存じかもしれません。プログラミングコミュニティに参加していれば、おそらく既にこのテーマが議題に上がっているでしょう。
もはやオブジェクト指向プログラミングは私たちを守りきれない
私たちはとうとう、分散処理や並行処理を実行するアプリケーションを持つようになりました。残念なことに、まだその準備はできていません。並行処理や並列処理を行う”現行の”（すなわち最も使用されている）モデルでは、たとえ問題を解決できても、多くの複雑さが伴います。
より優れたアプリケーションには、そのためのシンプルで信頼性の高い方法が必要です。上で説明したFPの機能を覚えていますか？　純粋関数や不変状態は？　そうです。既に取得した結果と異なる結果を出すことのない1つの関数を、別々のコアやマシンで1,000回実行できるということです。つまり、1つのコアで実行するコードを1,000個のコアで使用することもできます。これでまた救われます。
「でも、なぜOOPを使い続けてはいけないの？」
少なくとも並行処理や並列処理に関しては、もうOOPはあなたを守りきれません。というのも、OOPが可変状態に直接依存しているからです（OOP実装として最も一般的な、命令型言語において）。呼び出すオブジェクトのメソッドが、現在のselfやthisを変えるものと想定されているのです。全てのスレッドが正しくアップデートされ同期するよう保っていくには、かなり複雑な対処が必要となるでしょう。
私はここで、現在あなたの使っているパラダイムが何であれFPへ移行すべきだと主張するつもりはありませんが（そうすべきだと言う人もいるでしょうが）、FPをマスターする必要があるのは間違いありません。JavaとC++11は既に、ラムダ式を取り入れているのです。近いうちに、ほぼ全ての現代的でメンテナンスされている言語は、FPの機能に依存するようになるでしょう。既に大半はそうなっています。

以上、「でも、なぜOOPを使い続けてはいけないの？」とか、もはやオブジェクト指向プログラミングは私たちを守りきれないなどなど、「オブジェクト指向の否定」、関数型とOOOの対立を煽っている、ということで、【自称】「関数型コミュニティ」なるもので活動で勤しむ方々からは、きっと「キチガイ」扱いされてしまうのでしょう。

OOPが可変状態に直接依存しているからです（OOP実装として最も一般的な、命令型言語において）

オブジェクト指向が一般的に、命令型パラダイムであり、宣言型ではない、ミュータブル（可変状態）であり、参照透過ではない、というのは、これは基礎中の基礎のコンセンサスが世界的に存在しているはずで、上記のような言及はごくごく常識的でまっとうで、普通のものであり、私もまったく同じことを繰り返し書いているだけです。

③
The Manifesto for Not Only Object-Oriented Development
オブジェクト指向だけじゃない開発宣言
http://notonlyoo.org/
というサイトが存在します。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
クラスよりも、関数と型を、
可変性よりも、純粋性を、
継承よりも、コンポジションを、
メソッドディスパッチよりも、高階関数を、
nullよりも、Optionを、
価値とする。すなわち、左記のことがらに価値があることを認めながらも(但しnullは除くが)、私たちは右記のことがらにより価値をおく。

これはもちろん、オブジェクト指向でなく、関数型プログラミングへ価値転換すべく、
双方を対比的に比較しているわけです。
繰り返しになりますが、上記のような言及はごくごく常識的でまっとうで、普通のものであり、私もまったく同じことを繰り返し書いているだけです。


④
Javaによる関数型プログラミング ―Java 8ラムダ式とStream（Amazonリンク）
という、オライリーという、プログラミング界では広く認知されている出版社から刊行されている関数型プログラミングの解説書の紹介文です。

内容紹介

本書はJava 8で追加された新機能のうちラムダ式とStream APIに焦点を絞り、これらを使った関数型プログラミングについて解説します。
今までのJavaには存在しなかったこの新しいパラダイムに踏み込むことで、冗長さを排し、より簡潔なプログラミングを実現します。
しかし、これを使いこなすためには、従来のJavaにおける考え方を一旦捨て去り、新たな考え方をもってプログラミングを行わなければなりません。

ここでも、
「新しいパラダイムに踏み込む」
「従来の考え方を一旦捨て去り、新たな考え方をもってプログラミングを行わなければならない」旨がかなり明確に強調されています。

繰り返しになりますが、上記のような言及はごくごく常識的でまっとうで、普通のものであり、私もまったく同じことを繰り返し書いているだけです。

そうすれば、
関数型言語とオブジェクト指向の研究は両者とも同じ数学的基盤に支えられて行われています。
だとか、

オブジェクト指向と関数型は対立していますか？
いいえ、両方とも基礎理論はほとんど同じ人たちが研究していますし、純粋関数型オブジェクトの理論もあります（第32章）。むしろ、オブジェクトと第一級関数やデータ抽象の考え方（第2章・第3章）など、類似も少なくありません。フェライゼンというScheme等の著名研究者による「オブジェクト指向プログラミングに関する欧州会議」(ECOOP)における基調講演（特に22ページ目）や、ワドラーというHaskell等の著名研究者による「オブジェクト指向プログラミング・システム・言語・アプリケーションに関する国際会議」(OOPSLA)における基調講演等々もあります。

などと、色付きのスタンスの人々による珍妙な言説(かつ手口としては権威主義的強弁)が「一般的だ」と【自称】「関数型コミュニティ」においては強弁され続けて、挙句の果てに私のように人格否定までされているわけです。

ボトムラインとして、なぜ【自称】「関数型コミュニティ」の彼らは、
このように広く国際的に語られている
「新しいパラダイムに踏み込むこと」あるいは、
「従来の考え方を一旦捨て去り、新たな考え方をもってプログラミングを行わなければならない」事情について、はっきりと語らないのか？
あるいは、はっきりと語る私のような論調について、論調について罵倒するにとどまらず、論調そのものを消し去ろうとしたり、挙句の果てに人格攻撃までして反発しているのでしょうか？

「同じ基盤だ」「同じ人が研究している」と延々強調し続けている言説、態度は、もちろん、
「新しいパラダイムに踏み込むこと」
「考え方を切り替えて、開発に適用する方法を変える必要があります。」
「従来の考え方を一旦捨て去り、新たな考え方をもってプログラミングを行わなければならない」
といった転換を有耶無耶にするための行為であることは明々白々であり、何故そんなことをわざわざ「一般的だ」と「嘘」をついてまで強弁するのか？そこには、知的誠実な学究的態度は見受けられず、知的誠実でない排他的宗教的より好み、スタンスによる感情的な反発があると見做さざるを得ません。

事情を知る傍観者は、自分まで妙な個人攻撃の餌食になってはたまらない、と口をつぐむ。
それが現状です。

FAQ オブジェクト指向と関数型は対立していますか？
「いいえ」
と断言しているので、どんなものかと読み進めてみると、文章の最後には
上の記述はあくまで理論の話です。紹介記事の冒頭に書いたとおり、「単純な関数型言語に、複雑なオブジェクト指向はいらない」という考え方もあります（私個人の好みもそれに近く、OCamlのOはほとんど使っていません。参考リンク：「オブジェクトは OCaml の鬼子」）。のような、言い逃れのような玉虫色のわけのわからない事でお茶を濁されてしまい、馬鹿をみるのは、真面目に読んで混乱して終わった学習者だけなので、こういう説明は止めてもらいたいです。
そもそも、「上の記述はあくまで理論の話です」というオチのようだが、「オブジェクト指向」というのは、そもそも「理論」ではありません。文字通り「指向」、パラダイムであって、理論ではない。 こんなものは、どこでも書かれている初歩的な知識。
「直交・独立な概念」。文中にある、このFPvsOPの議論のそこら中で大変重宝されているようにみえる常套句であるが、非常に「トリッキーな概念」であるので要注意。というか、はっきり言うと単なる我田引水の「誤魔化し」である。なぜならば、あらゆる概念において、どの角度で切って分析するか？によって、常に「直交・独立な概念」を切り出すことが可能であるから。

＞要するに、オブジェクトの状態を破壊的に更新するか（命令型）、新しい状態を持つオブジェクトを作り直して返すか（関数型）というだけの違いです

「だけの違い」でなく、理論ではない指向、パラダイムとしてのオブジェクト指向にとってそこは大きな違いであり、その断面で分析すると「直交・独立な概念」ではありえない、と言うことだって簡単にできる。パラダイム、指向の対比において、「直交・独立な概念」などと相手が言い出したときは、其の人は単に論理的思考能力に劣るか、なんらかの誘導したい帰結に無自覚、其の両方か疑うべきでしょう。

理論ではなく、パラダイム、指向の話で、他のパラダイムとの際をひたすら有耶無耶にっすることに努め、玉虫色を強調するほど愚かなことはありません。なぜこういうことが起こるのか？というと、そもそも、FPvsOPというのはよく知られた対立軸であり、周囲に波風を起こしたくない（特に和を尊しとする我々日本人には顕著）、穏当に、というバイアスと、論者の「保身」がある。割を食うのは常に真面目に勉強したいと思う学習者である。小中高、あるいは大学でそのような曖昧な説明しかしない愚かな教師にあたって迷惑を被った人も多いと思います。


賢明な読者の方々は、ここで提供しているごく一部の情報にとどまらず、あくまでご自分の手で、国際的な情報、広い観点を検索して追認されることは可能ですし、その上で諸々の情報を比較検討して、どちらの情報がフェアで正しいのか？
何か禍々しいものが国内の言論には存在しているのではないか？確認してみることができるでしょうし、ひたすら権威を振りかざして強弁するだけの横暴に組み敷かれたり、惑わされるのではなく、ご自分の手と頭を使って、正しい情報を確認されることを望みます。

PS.

オブジェクト指向と関数型は対立していますか？
にて、

＞まさに「オブジェクト指向」と「命令型」を慎重に区別した上で、「オブジェクト指向言語と関数型言語」ではなく「命令型スタイルと関数型スタイル」を対比した、正確な記述だと思います。私の当記事の「メジャーなオブジェクト指向言語が命令型言語ベースのため」以下の部分もご参照ください。

という反応がありました。

繰り返しになりますが、まず「オブジェクト指向」という言葉は、パラダイム、指向性を示すものであって理論ではありません。

その上でより正確に「オブジェクト指向」という言葉について説明すると、

これはそもそもアラン・ケイが提唱した概念です。

http://d.hatena.ne.jp/sumim/20040525/p1

というブログ記事が一般にわかりよくまとまっているので引用します。

• 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。
  • アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、
  • ビアルネ・ストラウストラップによる、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽象データ型のオブジェクト指向」。
• この二つの「オブジェクト指向」は、オブジェクト指向という呼称、「クラス」や「オブジェクト」といった SIMULA67 由来の言語機能を共に使用してはいるものの、考え方の方向性が全く異なっており本来きちんと区別すべきものである。
  • もちろん SIMULA67 でも、前二者のオブジェクト指向を（限定的ながら）実践することは可能だが、SIMULA67 をもって「初のオブジェクト指向言語」としてしまうのは（ニガードやダールがまるで「オブジェクト指向」を考案したり「クラス」や「オブジェクト」をそのために設けたかのような）誤解や混乱を与える可能性があるので控えるべき。
• 残念ながら、教科書的な記述の多くはこれら二つを書き手に都合のよい解釈でごちゃまぜにしてしまっており、しばしば学習者に対して無用な混乱を生じさせている。

>一般に語られる「オブジェクト指向」はたいてい、この出自も文脈も目的も本質も異なる２つが、ただオブジェクト（あるいはクラス）という言語機能を共通に活用するというだけの理由でごっちゃにされて非常に合点のゆきにくいものになっています。教科書レベルの記述すら例外ではありません。個人的には、「メッセージ」 and/or “三点セット”だのを持ち出しておきながら、ケイ and/or ストラウストラップの主張への言及無しに「オブジェクト指向」を語ろうとする文章は、どんな偉い人、どんなに有名な人が書いていても（ノウハウとして役立つ内容であるかどうかはともかく、こと「オブジェクト指向」の紹介としては…）“眉唾もの”だと思って差し支えないと思っています。

とあるように、正確には、オブジェクト指向というくくりのなかでさえ、２系統のパラダイムが存在します。

オブジェクト指向と関数型は対立していますか？

＞（後者はいわゆるイミュータブルなオブジェクトとして広まりつつあるようです）。

などと間違った情報が書かれているのですが、リンク先の英語版Wikipedia記事には正しい説明があります。

>In imperative programming, values held in program variables whose content never changes are known as constants to differentiate them from variables that could be altered during execution. Examples might include conversion factors from kilogram weights to pounds or the value of Pi to several decimal places.

要約すると、

「イミュータブルなオブジェクト」ImmutableObjectとは

命令型プログラミングの文脈においても、パイその他の変更不能なConstant（定数）として知られている、とあるように、「広まる」も何もありません。
「イミュータブルなオブジェクト」とは、命令型、関数型、そしてオブジェクト指向、いかなるパラダイム、言語においても普遍的に我々が接する以前からある馴染みのある概念です。

「後者」（副作用を用いない純粋関数型オブジェクト指向）が、一般的になりつつある、というように読者を誘導せんばかりの当該記述ですが、明確に間違っています。

「副作用を用いない純粋関数型オブジェクト指向」であるのならば、この混乱した「オブジェクト指向」のパラダイムにおいて、わざわざ「オブジェクト指向」と言う意味は一体どこにあるのでしょうか？

引用している https://msdn.microsoft.com/ja-jp/library/bb669144.aspx において、もっとも読者にとって重要な事柄は最後の総論部分です。

OOP 開発者向けの移行

従来のオブジェクト指向プログラミング (OOP) では、ほとんどの開発者が命令型/手続き型スタイルのプログラミングに慣れています。純粋関数型スタイルの開発に移行するには、考え方を切り替えて、開発に適用する方法を変える必要があります。

問題を解決する際、OOP 開発者は、クラス階層を設計し、適切なカプセル化に焦点を絞り、クラス コントラクトの観点から考えます。何より重要なのはオブジェクト型の動作と状態であり、それに対処するために、クラス、インターフェイス、継承、ポリモーフィズムなどの言語機能が用意されています。

一方、関数型プログラミングでは、計算の問題を、データ コレクションの純粋関数型変換の 1 つの課題として捉えます。関数型プログラミングでは、状態や変化するデータを避け、関数の適用を重視します。

混乱した「オブジェクト指向」のあるかないかさえ不明な「理論」なるものによる分類は、プログラマーの誤解によるものなどではなく、そもそも「オブジェクト指向」というものがそういう漠然としたパラダイムである、ということにすぎず、現実上ほとんどのOOP開発者にとっては、対立するパラダイムとして頭を切り替える必要のある関数型スタイルが存在します。

「副作用を用いない純粋関数型オブジェクト指向」ならば、それは単に「関数型プログラミング」です。わざわざ枠組みがよくわからない、広く一般的には命令型として普及している「オブジェクト指向プログラミング」の一種だ、直交していると強調するのは誤りです。