『関数型プログラミングに目覚めた！ IQ145の女子高生の先輩から受けた特訓５日間』を大変多くの方々にお買い求めいただき、感謝します。本書の全目次を公開し、質問を受け付けます。という記事を当ブログにUPする前後から、多くの読者の方から、励ましのお言葉、著書の評価、ご質問をいただいております。どうもありがとうございます。
いただいたメールの中でも度々言及される、関数型プログラミングの古典の『計算機プログラムの構造と解釈』（Structure and Interpretation of Computer Programs。原題の略称SICPがよく使われる）の論評、本書との関連性についての記事など、その系統のお話をする、著書の副読記事シリーズを先に開始しようと思いましたが、メールのご質問の対応が追いつかなくなる前に、１エントリずつに分けて公開したいと思います。すべてのメール、また個々のメールで大変やりとりも長くなっているものもあり、全部は公開できないことはご了承ください。
またもちろん、公開してほしくない、ということであれば、その都度メールで釘をさしてください。
「関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間」質問です
ご挨拶
はじめまして。34歳のITコンサルティング業に携わっているものです。
この度、「関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間」を購入し、ドキドキワクワクしながら、先日１周読み終えたところです。この度、「質問を受け付けます」の投稿を拝見し、メールした次第です。この本のことは、Qiitaで話題になっている時から存じ上げていました。
2015年1月から関数型プログラミングを独学で学びはじめ、ネットを徘徊しているうちに岡部さまの記事に目がとまり
しばし（数日間）釘付けになっていました。無料なのにとんでもない記事を発見してしまった！と。
刊行されることがわかり、amazonにて即予約しました。私は数学的背景がありません。もっと言えば文系です。さらにいうと高校生の時に数学に挫折し文系転向しています（笑）。
ですが、関数型プログラミングが私の環境に与えるかもしれない影響を考えると、是が非でも身に付けたいと思えるようなテーマであり今からでもゼロから学び始める価値があると感じました。そして、いつかの若かりし自分に喝をいれたいという気持ちも湧き上がって、勉強にはまっています。なお質問者の取り組みレベルですが、次の書籍は勉強素材として活用し、ある程度内容を理解しているつもりです。
- プログラミングの基礎
- すごいHaskellたのしく学ぼう!
- 関数プログラミング実践入門
- なぜ関数プログラミングは重要か
- 離散系の数学（コンピュータサイエンス大学講座）(理系の部下に勧められて勉強中)
- 関数プログラミング 珠玉のアルゴリズムデザイン（これは途中で本をそっと閉じました）
これらのあとに関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間」を読み、感銘を受け、関数型プログラミングに関係する際の拠り所にしよう！と思っている状態です。できればキーワードはすべて暗記して、自分の言葉として定着化させたいです。
それではよろしくお願いいたします。
質問箇所
Day3
計算や入出力の命令というハードウェアモードのマシン操作は論理の物質化だが、関数でラッピングしてふたたび論理化せよ
質問事項
関数型プログラミングのスコープにおいて、計算や入出力という論理の物質化（ハードウェアのマシン操作）は、プログラマ（例えばアプリ開発者としての私）が行っても良いものなのでしょうか？
質問補足
私自身が何かの機会で勉強会の発表を務めた際に、もし尋ねられたらどうしよう、という動機で質問させていただきました。私は、関数型プログラミングの学習は Haskell を通じて行っています。この言語仕様では、いわゆる純粋な関数しか「私は」書けないので、計算や入出力は行っていないことになると思います（そして、入出力に関しては、IOモナドでのみ許されている）。
ですが、 javascprit のコード上では、セキヤはハードウェアのマシン操作をコードに落とし込んでいます。これは、本では車輪の再発明ということで説明されていて、実際はライブラリや先行事例を利用するようにあります。ただ現実の開発現場では、未知の問題として、もしくはセキヤのように敢えてハードウェアのマシン操作を「私が」書く必要性に迫られることもあるかと思います。この場合、関数型プログラミングのパラダイムで、どのように問題解決すれば良いのでしょうか。
言い換えると、関数型プログラミングをしているが、ハードウェアのマシン操作をすることもある（つまり命令する) 、というような言い回しは存在するのでしょうか。
もしかすると、本では（またはこのリンクhttp://kenokabe-techwriting.blogspot.jp/2015/04/amazon_28.html)、「そうである」と示してくれているのかもしれません。しかし、これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない、と私が解釈していることもあり、どうにも自信がなく、ついにメールで直接質問してしまいました。
追伸
もいただきましたが、私の文章力、道理の示し方、論理構成、肉付け方、アウトプットについて、あまりにも過分な評価のお言葉をいただき、面映いので、さすがに割愛させてください。
申し訳ございません。本当にありがとうございます。
回答いたします（岡部）
はじめまして、著者の岡部 健です。
この度は、著書をご購入いただき、また、ドキドキワクワクしながら一生懸命読んでいただいて本当に嬉しいです。どうもありがとうございます。先日１周読み終えたところです、というとのことでまた何度か精読していただけるのでしょうから、なおありがたく存じます。
本書は、類書というものがひとつも存在せず、どのプログラミング本でも書いていない、本当に大事なことを書いたつもりです。僭越なものいいとなりますが、大変勉強しておられる延長で、なお本書を読解する大きな価値を見出していただけたことは、本書の解説内容が伝わったと実感でき、執筆した甲斐があります。プログラミングの勉強のために離散系の数学まで勉強しておられるってすごいですね。
また、私の及ばない文章について、過分なお褒めのお言葉もいただきまして嬉しいです。
どうもありがとうございます。
追伸にあった読み物についてですが、まずは無料の私のまた長い文章である、量子コンピュータ記事は面白いと思います。
本書を気に入られたのであれば、私の書き方や、哲学面も抵抗なく、参考になるのではないでしょうか？重複する内容も書いておりますし、読み応えはあるはずです。
http://kenokabe-techwriting.blogspot.jp/2015/01/blog-post_28.html
http://kenokabe-techwriting.blogspot.jp/2015/01/2.html
書籍ですが、率直に申し上げて、少なくとも、私自身が感銘を受けるほどに参考になった関数型プログラミング本はございません（苦笑）
関数型プログラミングは、「異なる考え方」が必要だ、とさんざん喧伝されるわりには、その「異なる考え方」がいかなるものか？心底実感ができてパラダイムシフトである、と理解できた文献はどこにも存在しなかったのです。
「異なる考え方」については、あらゆる書籍でも冒頭部分に申し訳程度に「さわり」があるだけで、その部分を本気で読者に伝えたいと思っている著者はあまりおられないようでした。そしてそれはおそらく、そこに踏み込むとまさに本書のように「関係ない哲学が延々と書かれている」「技術書としての体をなしていない」批判が容易に予想ができますから、執筆者としての防御本能も働いていることは想像できます。また、今となって読み返すと、その著者ご自身がどの程度その「異なる考え方」に踏み込んで理解しているのか？疑問もあります。
このような状況に結構、私は不満でしたので、本書の執筆の機会をいただいて、不明であったときの自分に是非読ませたいと思った内容そのままの本を今回全力で書きました。
あと、なんで人から薦められる技術系の本ってあんなにおもしろくないんでしょうね（笑）
薦められるくらいなのでよほど面白い、役立つのだろう、と期待値があがるせいでもあるのでしょうが、個人的には読んでよかった！という経験がこれまで一度もないもので、私のほうからはプログラミング本でオススメできるものはないです。
そのような状況の中、XX様のこのメールもそうですが、これまで、それなりの数の読者の方々から、本当に感銘を受けていただいた、喜んでもらったことがわかるフィードバックをいただいております。
これは多分他の書籍が提供できなかった紛れもない価値を創出した、と著者として自信が持てました。
本書は読み手を選ぶ本ではありますが（著者の意図としては残念です、念の為）、価値と良さを理解できる方は、本当にプログラミングスキルが他の人より向上すると思います。
ですから、おめでとうございます（笑）
その他私の記事では、おそらくご存知でしょうが、当ブログのReact解説2編です。
これは、本書ではまずまずいろんな事情で私の力が及ばず、私が考える品質基準としては解説が最後まで行き届いておらず、不十分で申し訳ないな、と思ったので、出版後にUPした記事です。
本書の延長として読んでいただけるとありがたいです。
FRPで実用的にアプリケーションを組むにあたり、今後必ず参考になるように書いてあります。
関数型プログラミングの「異なる考え方」について解説してある書籍について、フェアに補足しておく必要があります。
関数型プログラミング本の古典として、しばしば参照されるのは、SICPです。私がブログ記事にも書いているからか、読者の方々からも言及があります。
素晴らしいことに上記Wikipedia記事の外部リンクに、無料でHTML,PDF版が閲覧できます。
MITのCSコースの教科書として用いられ、関数型プログラミングの聖典とまで一部ではいわれているようなので、それこそ権威としてありがたく時間をかけて読む方は多いようです。
私個人が楽しめた楽しめなかったかは別として、SICPは高く評価します。
SICPを高く評価する理由は、この返信とも関係があるのですが、
また更に長くなるので、SICPについては、なぜ聖典と言われるのか？
考察とともに、続く記事に分離して論じます。
関数型プログラミングのスコープにおいて、計算や入出力という論理の物質化（ハードウェアのマシン操作）は、プログラマ（例えばアプリ開発者としての私）が行っても良いものなのでしょうか？
本書で解説しておりますとおり、ハードウェアモードの命令型の上層で宣言的なコードとして存在するのが、「関数型プログラミングのレイヤ」なのですが、
必要に応じて、ハードウェアモードの層を関数型プログラミングのひとつのパーツとして、
プログラマ自身が設計して用意する必要があります。
すなわち、関数として設計して用意するということです。
あとその関数を、設計した自分自身で、関数型プログラミングの部品として利用するわけですね。
そして、命令型、入出力っていうのは、やったらやりっぱなしですが、
関数でラッピングする＝関数として設計して用意する
ということは、やったらやりっぱなしでなく、必ずその論理部品としての関数の返り値があるわけです。
これもそのハードウェアモードの作業との兼ね合いにおいて、どういう返り値にしたら、
論理的に整合性がでるか？考えながら設計します。
私自身が何かの機会で勉強会の発表を務めた際に、もし尋ねられたらどうしよう、という動機で質問させていただきました。私は、関数型プログラミングの学習は Haskell を通じて行っています。この言語仕様では、いわゆる純粋な関数しか「私は」書けないので、計算や入出力は行っていないことになると思います（そして、入出力に関しては、IOモナドでのみ許されている）。
ですが、 javascprit のコード上では、セキヤはハードウェアのマシン操作をコードに落とし込んでいます。これは、本では車輪の再発明ということで説明されていて、実際はライブラリや先行事例を利用するようにあります。ただ現実の開発現場では、未知の問題として、もしくはセキヤのように敢えてハードウェアのマシン操作を「私が」書く必要性に迫られることもあるかと思います。この場合、関数型プログラミングのパラダイムで、どのように問題解決すれば良いのでしょうか。
言い換えると、関数型プログラミングをしているが、ハードウェアモードのマシン操作をすることもある（つまり命令する) 、というような言い回しは存在するのでしょうか。
もしかすると、本では（またはこのリンクhttp://kenokabe-techwriting.blogspot.jp/2015/04/amazon_28.html)、「そうである」と示してくれているのかもしれません。しかし、これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない、と私が解釈していることもあり、どうにも自信がなく、ついにメールで直接質問してしまいました。
素晴らしい質問ですね。
IOモナドについては、私自身今回の著作との関連を見極めて、おいおい記事をあげようと思っています。
これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない
これは、基本、「神の眼」が見透す、時間に伴う状態変化を扱わない、
論理破綻がない、参照透過な、宣言型で書くべきだ、っていうことなんですが、
あくまで、水面より上の見えるところでその世界を構築したらそれでいいのですよ。
部品として、ここはハードウェアモードだ、ちゃんと返り値もある関数だ、ってやれば、
全体としては何の問題もないですよね？？
これを、いずれにせよハードウェアモードを書くんだったら「関数型」だけのコードなんて書けない、
だから、関数型はプログラミングは銀の弾じゃない！
マルチパラダイムだ！とかいう人もいてQiitaでも論争になったわけですが、
そもそもパラダイムっていうのは、世界観、枠組みの話であるわけです。
あくまで、世界観、枠組みの階層のトップに、水面上で、参照透過な世界を構築するという、
その枠組みにおける至上命題がある。
それはシングルパラダイムなんですね。
そのシングルパラダイムの枠組みの下層で、ハードウェアモードの作業をすれば良いです。
もっというと、たとえば、LoDashや、Underscore、Reactという外部の関数型ライブラリが存在します。
これは「関数型ライブラリ」であるわけで、
当然関数型パラダイムを実現するためのライブラリであるわけです。
でも、その「関数型ライブラリ」自体は、多分ふんだんに命令型のソースコードをもって設計されている。
それら関数型ライブラリの中ではハードウェアモードの命令型のマシン操作をやっているでしょう。
その結果、いろんな便利な関数が提供されています。そして関数型プログラミングが実現できる。
これはマルチパラダイムとは言わない。
Undersocre,Reactで組むのは、関数型プログラミングじゃないマルチパラダイムなのか？
そんなことはなくって、単なるシングルパラダイムの関数型プログラミングです。
自分で「足りない」と思ったら、
たとえば、MY関数型ライブラリを外部に切り出して作ったらどうでしょう？
それ適用してやったら、おんなじように、単なるシングルパラダイムの関数型プログラミングだと言えますよね？
時間変化を扱うには、IOモナドなら解決というのは、結構な思考というか、理路の欺瞞があって、
まさに本書のDay3,4あたりでみっちり書いている世界観の話があります。
FRPですね。
たとえば、Reactは、IOモナドとは関係ないですが、まさにIO、UIの関数型ライブラリとして機能します。
いただいた返信
水面より上の見えるところでその世界を構築したらそれでいいのですよ。
なるほどですね。とてもすっきりとしました。関数型プログラミングを学ぶ際、入り口からOOPとの違いとして明確に述べられている世界だったので、プログラマは常にその世界にいなければならないものなのだという考えに自然と縛られていました。
何か、自由になった気分です（笑）また、昨日のメールに含ませるのを失念したことがあるので、この返信に添えさせてください。
岡部さまの大事にしておられる、読者に対する関数型プログラミングの世界観の形成というのは、私の仕事である、「事業会社の情報システム部・業務部門に対する企画提案と推進」でも非常に重要な成功要因です。この感覚を持っていない人は意外と多く、そういう人は、のっけから「なぜやるかよりどうやるかを考えろ」などと周囲に言ってしまう有様です。
必ずしもその分野のプロではないステークホルダーに対して、やろうとすることの世界観を共有できるかできないか。これは例えばサービス開発のプロジェクトにおいて、一丸となって最後までやり切る原動力、苦しいときの拠り所、つまりぶれない信念の共有になると信じています。
その意味でこの本は、私がやろうとしている関数型プログラミングについて、私のぶれない信念を形成するために非常に価値がありましたし、それは著者がそのような意図で制作されているからなのだと思っています。
曲解しているようでしたら、生暖かく見過ごしてやってください。
以上、重ねて御礼申し上げます。どうもありがとうございました。
岡部の回答
この感覚を持っていない人は意外と多く、そういう人は、のっけから「なぜやるかよりどうやるかを考えろ」などと周囲に言ってしまう有様です。
必ずしもその分野のプロではないステークホルダーに対して、やろうとすることの世界観を共有できるかできないか。これは例えばサービス開発のプロジェクトにおいて、一丸となって最後までやり切る原動力、苦しいときの拠り所、つまりぶれない信念の共有になると信じています。
「やろうとすることの世界観を共有できるかできないか」
これは、特に最近アメリカではかなり広く共有されている考えかたですね。秀逸な知見であると同意します。
TEDカンファレンスの著名なスピーチ
サイモン シネック: 優れたリーダーはどうやって行動を促すか
http://u-note.me/note/1075
どうしてアップルはあれほど革新的なのか？
スティーブ・ジョブズ、キング牧師、ライト兄弟は何故成功したのだろう？アップルも他社と同じような広告代理店 ・コンサルティング会社を利用し、同じような人材が集まっている。なのにアップルだけが革新的な商品を世に送り続けている。
偉大な人間の考え方〜『WHY』から考えよう〜
「What」→「How」→「Why」ではなく、
「Why」→「How」→「What」ということですね。
人は「何を」ではなく、「なぜ」に動かされる
という知見です。
欧米のITブログや、ソフトウェア開発プロジェクトの冒頭紹介文は、以前は、
What is xx? であったのが、最近では、
WHY xx ? から始められることが大変多くなっています。
たとえば、FacebookのReactですが、
GUIDSの最初は、
https://facebook.github.io/react/docs/why-react.html
What is React? ではなく、
Why React?となっています。
https://angularjs.org/
でも、
Why AngularJS?
What is AngularJS?ではありません。
その意味でこの本は、私がやろうとしている関数型プログラミングについて、私のぶれない信念を形成するために非常に価値がありましたし、それは著者がそのような意図で制作されているからなのだと思っています。
曲解しているようでしたら、生暖かく見過ごしてやってください。
曲解はされておりません。まさにその通りなんですよね。
ご覧の通り、本書のDay1は無料公開もしておりますが、まさに、
Why Functional Programming?
「やろうとすることの世界観を共有できるかできないか」
この一番大事なことについて、かなり意図的に書いております。
なぜ、関数型プログラミングが魅力的でパラダイムシフトする価値があるのか？
それが最も大事で、読者が知りたい、求めている情報です。
そもそも私の知見ややり方一切合切含めて全否定された方による、その経緯における解説、
「関数型言語」に関するFAQ形式の一般的説明
http://qiita.com/esumii/items/ec589d138e72e22ea97e
というものがあります。
この解説記事は、初心者対象、らしいですが、
Why Functional Programming?に相当するっぽい唯一の具体的部分は、
関数型プログラミング・関数型言語の何がうれしいの？
例えば、上のsum関数であれば、sum(s,i)の戻り値がs + i + (i+1) + (i+2) + … + 10に等しいので、sum(0,1)が0 + 1 + 2 + 3 + … + 10に等しい、ということを数学的に検証（証明）することも比較的容易です！ 後述の高階関数を用いれば、関数を部品に分けたり組み合わせたりすることが容易になるので、さらに独立性や検証可能性を高めることができます。
ということですが、はたして、関数型プログラミング・関数型言語の何がうれしいの？と知りたい初心者の方が、上記をみて「うれしい」と思えるかどうか甚だ疑問です。
だいたい、ほとんどの人は「数学的に検証（証明）」したいがためにプログラミングに取り組んでいるわけではありませんよね？この時点で世界に大きなズレがある。いったい誰のための解説なのか？
そして、この記事の他のすべての部分は、WHYでなく、WHATです。
何？何？何？で書かれています。
それが何？であるかどうかを列挙されても、けっしてWHY？世界観を共有することはできません。
考え方の違いを理解することはできません。
オブジェクト指向と関数型は対立していますか？
いいえ、データとそれに対する操作（メソッド）のまとまり（オブジェクト）を基本にシステムを構築するオブジェクト指向と、「副作用を用いない」関数型プログラミングとは、直交（独立）な概念です。
本書でも解説しております通り、そもそも「オブジェクト指向」いう言葉を使い出したのは、
パーソナル・コンピューティングの父と言われるアラン・ケイです。
「オブジェクト指向」とは、パーソナル・コンピューティング黎明期における、アラン・ケイやその他のビジョナリーによるアイデアであり、思想であり、その世界観を、新しい概念として彼らがまとめたものです。
「指向」という日本語の言葉でもわかりますが、それは方向性です。
この記事の解説者の一連の主張は、「オブジェクト指向」の理解がまず間違っているし、
関数型プログラミングの「パラダイム」「世界観」としての対比の解説としても間違いです。
「イミュータブルなオブジェクト」だとか、もはや「オブジェクト指向」のパラダイムではないわけですね。
この記事はそもそも、私の主張への対抗言論としてUPされたものであり、特にこの
オブジェクト指向と関数型は対立していますか？
の項目はそうです。
しかし、最初は、「同じ研究者（自分も含めて）が研究している」「どこそこの権威ある基調講演があった」というものごとの説明、理路ではない権威主義の言葉があるだけで、反論としても成立していないことを、私は批判しました。それを受けて、この項目に追記されたのが現バージョンなのですが、
もちろん、どんな言語（というかどんな技術や概念）でもあるように、関数型言語のファンでオブジェクト指向が嫌いという人も一定数はいますし:-)それは思想・信条の自由です。上の記述はあくまで理論の話です。
とさらに、言い訳がましい言及が追加されただけです。
オブジェクト指向とは「パラダイムの話」であり「思想」「世界観」であり、「あくまで理論の話」ではありません。
なんでこんな珍妙な氏の説明になるのか？というと、この解説者は、技術、ものごとの背景に存在する、アイデア、思想、哲学、世界観、パラダイムというものをまったくリスペクトしていない、まったく気に留めない、少なくとも、その解説では重視するどころか、ご丁寧にも、
関数型言語は哲学や宗教と関係がありますか？
ありません。いやひょっとしたらいつか何らかの関係が見出されるかもしれませんが、これまでのところ、まっとうな言説は寡聞にして知りません。
参考リンク：ソーカル事件
（詳しい方へ：ライプニッツのモナドが…とか、カリーハワード対応する数理論理学の起源は哲学だから…とかは、ここでは「関係がある」に含めません。哲学科出身の計算機科学研究者の先生方もいらっしゃいますが、一部で見られるようなトンデモ議論は伺ったことがありません。
とまで書いておられます。
まず、これは学問の素養として説明しておかなければなりませんが、
古来から、哲学と宗教の境目はありませんでした。それは現代においてもそうです。
ガリレオ・ガリレイの時代に、
哲学の一部は自然科学となり、
哲学の一部は宗教となり、実際に自然科学者であるガリレオ・ガリレイが宗教により有罪とされた、と反目することになっていくのですが、本来は、哲学と宗教は同じものです。
特に、我が国日本においては、宗教といえば胡散臭い、と思う人が多いのですが、
もともと仏教が大陸から伝来した聖徳太子の時代では、それは進んだ文明の学問として伝来しました。
聖徳太子はインテリという「逸話」「伝説」が有名ですが、
土着宗教である神道と戦争してまでも、聖徳太子と蘇我馬子が仏教を広めたのは、それが学問であったからです。
http://www.shoto9taishi.com/buddhism/
など、今適当に検索してみましたが、他の豊富なWeb記事からも、
以上の説明が結構な「基礎知識」であることは、誰でも追認可能でしょう。
哲学の素養がある方の本書の書評を引用したこともありますが、
私の知識的背景としては、本書で素材とされる言語JavaScriptに相当長期間の馴染みがあり、
西洋哲学史や宗教哲学にある程度の素養を持ちます。また言語やシステムを創案する立場に
共感しやすく、そうした設計の背景となる哲学や思想を聞くのが好きな傾向にあります。
逆に、関数型プログラミング自体には何も予備知識がなく、本書で初めて触れた状態です。
プログラミングを哲学の投影のように扱い、背景思想を語ることに、多くの方が批判的な
ようですが、逆に、私はその点を、この著作最大の美点として推します。類書はたしかに
これまで存在せず、異色の試みですが、私はこういうスタイル・切り口の著作があれば、
他の著者や言語の本であっても喜んで読むでしょう。
哲学は歴史的に見て、あらゆる学問の源泉・母体となった学問ですが、現在においても、
その中核にあって、しかも内部の各分野が緊密に連携しています。プログラミングに
関係する論理学や数理哲学だけでなく、言語哲学・科学哲学周辺まで背景知識として
持つことが、言語設計の理解の助けになるだけでなく、面白いことだと私は思います。
オブジェクト指向の誕生経緯についても本書で解説していますが、
それはアラン・ケイをはじめとするソフトウェア開発の先駆者による哲学です。
偉大なソフトウェア開発の背景には
「UNIX哲学」
https://www.google.co.jp/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8&client=ubuntu#q=UNIX%E5%93%B2%E5%AD%A6
でもなんでもそうですが、哲学が存在します。
関数型言語は哲学や宗教と関係がありますか？
ありません
まっとうな言説は寡聞にして知りません。
一部で見られるようなトンデモ議論は伺ったことがありません。
などとまで言い切るのは、「無知」によるものである、と断言できます。
いい加減に取り返しのつかないことになる前に軌道修正されたほうが良いと思います。
ちなみに「ソーカル事件」というのは、
Wikiepediaでもどこでも書いているとおり、
数学・科学用語を権威付けとしてでたらめに使用した人文評論家を批判するために、同じように、科学用語と数式をちりばめた無意味な内容の疑似哲学論文を作成し、これを著名な評論誌に送ったところ、雑誌の編集者のチェックを経て掲載されたできごとを指す。
という「権威主義」への批判のための社会実験でした。
まさに、この解説者のように、本当の背景思想を解説せず、言葉を、権威を持ってでしか物事の解説の土台としない作法を批判した事件です。反論になっているどころか、ご自身の解説の仕方にそっくり当てはまるような事件であり、同時にまた「ソーカル事件」という意味、背景というのを理解もせず「権威主義的解説」として乱用しているのか？とただただ残念です。
私はこの指摘をこれまで何度かしており、彼はいい加減に訂正撤回すればいいのに、と思っているわけですが、ずっと掲示し続けています。
私はトンデモ議論をしているのではありません。この侮辱的言及も撤回していただきたいと思います。
私にあてつけとして掲示し続けたいだけで、読者に正しい知識を与える、という本文はもうどうでも良いのでしょう。間違っていることがわかったら訂正する、それ以上間違った知識を学習者に拡散しない、それが学者の学徒の、言論人のあり方ではないでしょうか？
少し話が発散しましたが、XX様のメールで、
関数型プログラミングを学ぶ際、入り口からOOPとの違いとして明確に述べられている世界だったので、プログラマは常にその世界にいなければならないものなのだという考えに自然と縛られていました。
理解されているとおり、多くの解説、広く国際的な知見としては、
ソフトウェア開発の手法として、その紹介の入り口として、
関数型プログラミングは、OOP（オブジェクト指向プログラミング）と対比されます。
対立するパラダイムとして紹介されることが普通で、実際その知見は正確です。
関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違いより再掲すると、
以下が ##広く一般的で国際的な【「関数型言語」に関する一般的説明】です。
まず、マイクロソフトのサイトから見てみましょう。
念の為ですが、マイクロソフトから引用するのは、「権威」を拝借したいから、権威主義的説明を試みたいからではありません。一般にマイクロソフトが「権威」であると考える人は居ないでしょう。マイクロソフトというのは、まさに、IT世界で、広い範囲で、どこにでもあるWindowsその他のプロダクトを提供している、一般に馴染の深い国際的な企業であり、その技術的説明も一般的で普遍的であるという観察と前提に基づいています。
関数型プログラミングのパラダイムは、問題解決に適用する純粋関数型の方法をサポートするために、わかりやすく作成されています。 関数型プログラミングは、宣言型プログラミングの一種です。
一方、C#、Visual Basic、C++、Java などのオブジェクト指向プログラミング (OOP) 言語を含むほとんどの主流言語は、主に命令型 (手続き型) プログラミングをサポートするために作成されています。
命令型の方法では、開発者はコードを記述して、目的を達成するためにコンピューターが実行するステップを詳細に示します。 これをアルゴリズム プログラミングと呼ぶこともあります。 一方、関数型の方法では、実行される一連の関数として問題が組み立てられ、 それぞれの関数に何が入力され、何が返されるのかが、慎重に定義されます。 この 2 つの方法の一般的な違いを次の表に示します。
| 特性 | 命令型の方法 | 関数型の方法 |
|---|---|---|
| プログラミングの焦点 | タスク (アルゴリズム) の実行方法と状態の変化の追跡方法。 | 目的となる情報と必要な変換。 |
| 状態の変化 | 重要。 | 存在しない。 |
| 実行の順序 | 重要。 | あまり重要ではない。 |
| 主要なフロー制御 | ループ、条件、および関数 (メソッド) 呼び出し。 | 関数呼び出し (再帰を含む)。 |
| 主要な操作単位 | 構造体またはクラスのインスタンス。 | ファーストクラス オブジェクトとしての関数とデータ コレクション。 |
OOP 開発者向けの移行
従来のオブジェクト指向プログラミング (OOP) では、ほとんどの開発者が命令型/手続き型スタイルのプログラミングに慣れています。 純粋関数型スタイルの開発に移行するには、考え方を切り替えて、開発に適用する方法を変える必要があります。問題を解決する際、OOP 開発者は、クラス階層を設計し、適切なカプセル化に焦点を絞り、クラス コントラクトの観点から考えます。 何より重要なのはオブジェクト型の動作と状態であり、それに対処するために、クラス、インターフェイス、継承、ポリモーフィズムなどの言語機能が用意されています。
一方、関数型プログラミングでは、計算の問題を、データ コレクションの純粋関数型変換の 1 つの課題として捉えます。 関数型プログラミングでは、状態や変化するデータを避け、関数の適用を重視します。
一目瞭然ですが、マイクロソフトのこの解説記事は、
関数型・宣言型プログラミングとオブジェクト指向・命令形（手続き型）プログラミングを、対比的なパラダイムとして解説しています。
またかなり明示的に、OOP 開発者向けの移行、
「考え方を切り替える」、「開発に適用する方法を変える必要がある」ことが論じられています。
この解説が広く一般的です。
以下、すでに述べたことの繰り返しとなりますが、重要なことなので最後にまとめておきます。
関数型プログラミングは、OOP（オブジェクト指向プログラミング）は、
パラダイムとしては対立する位置にある、それはまず理解することは何よりも重要です。
WHY、世界観を理解することからはじまります。
それはシングルパラダイムであり、対立するものが「同じレイヤ」で同居するマルチパラダイムではありえません。
その前提を理解してですが、パラダイムは、階層構造が存在します。
本書で解説しているとおり、関数型プログラミングでもハードウェアモードが土台にあります。
多くの場合、そのハードウェアモードの作業は、別の誰かがやってくれており、
「車輪の再発明」をする必要はありません。
JavaScirptの場合でも、関数ライブラリとして提供されています。
それは、Haskellのように言語仕様として最初から実装されていることと本質的になんら違いはありません。
Facebook-Reactも関数ライブラリのひとつで、DOMという物質的要素（ハードウェアモード）を仮想化して論理として関数型のパラダイム（コンポーネント指向）でとりまわすのですが、このReact自体はハードウェアモードで書かれています。
同様に、自身足りないと考えればMy関数ライブラリをハードウェアモードで用意します。
My関数ライブラリを公開することで、他の人が評価し、「車輪の再発明」をする必要をなくすかもしれませんし、それはあくまでシングルパラダイムの世界で完結した事象であるわけです。
0 コメント:
コメントを投稿