流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。仕事を辞めてぼんやりと路頭に迷っている内に半年が過ぎようとしている。Patreonプロジェクトを立ち上げたり(ご支援お待ちしてます🙇)、新しく思いついたことを少しずつ形にして、細々と実験を重ねたりしていた。油断していると一年ぐらいあっという間に過ぎ去りそうなので、せめてこの半年間の試行錯誤をここに記録しておきたいと思う。前回の記事「アウトライナーの新しい形を考える」では、筆者が個人的に開発中の、なんとも形容のし難いソフトウェアを、アウトライナーという比較的ポピュラーなソフトウェアと対比することで説明を試みた。ゴールは、単に情報を整理して多面的な知識ベースを作るということに留まらず、「発見」を支援する環境を提供することを目標にしている。現時点でその目標に到達できているかと言えば、あと一歩、決定的な何かが欠けているような気がしていた。そのアイデアについての試行錯誤を続ける内に、「発見」にフォーカスするならもっと違うアプローチが必要になるのではないかと考えるようになった。そこで思いついたアイデアを形にしてみたのが、「ユメアト.net」というサイトである。グラフ構造に従って旅行先を選択し、その足跡を記録して共有するためのサービスである。Tourism」と呼んでいる。なんのこっちゃと思われるかもしれないが、順を追って説明したい。」のように、テーマがあってそこから目的地を決めるケースが多いのではないかと思う。それをここでは「縦のつながりによる選択」と呼ぶことにする。カテゴリー(上位概念)から目的地を選ぶようなケースである。一方で、とある場所に出かけて行って、現地で見つけた意外な縁で別の目的地に導かれる、といったような「横のつながりによる選択」が行われることもある。この「横のつながり」あるいは「隣接関係」を辿る旅を支援する。「アウトライナーの新しい形を考える」の中で、ツリー構造とグラフ(ネットワーク)構造の比較を行った。呼ぶ理由なのだが、実際には縦より横の関係に力点を置く。縦のつながり、あるいはカテゴリーによる選択は、単純に言えば旅行者自身の「興味」による選択である。一度、興味(テーマ)が設定されてしまうと、そこから逸脱しようという動機付けはなかなか働かない。そのカテゴリーを極めようとするのが人情である。その壁を破るために、横のつながり(隣接関係)が重要なのではないかと考えた。過去の出来事の痕跡を残す場所を、史跡よりも広い意味で「ユメアト」と呼ぶ(由来にした松尾芭蕉の「夢の跡」はむしろ痕跡が残ってない場所のことだと後々気がついた)。ユメアトはそれぞれに関係する、共通の「固有名(人物や場所などの名前)」があるときに、横のつながりを持つ。Yumeato.net)。生麦事件のページを見ると、場所や日付などの基本情報と一緒に、沢山の関係する固有名が並んでいる。選択すると、彼が関わった他のユメアトの一覧を見ることができる。こんな感じでユメアトと固有名のつながりを辿って次の目的地を探しながら旅を続けて行く。以下は、筆者が去年の春頃から始めた旅の足跡をグラフ化したものである(こちらで実物を閲覧できる)。横のつながりを追う旅は、自分自身の興味の範囲に留まることなく、現地で見つけた痕跡とそこから辿れる縁に従って、カテゴリーを次々に横断して行く。筆者の例で言えば、地図上から適当に選んだ「玉川上水開削」の現場に始まり、巡り巡って、鉄道の父「井上勝」のお墓に訪れたり、その墓地で「賀茂真淵」という人物の墓を見つけた縁で、彼の生誕地である静岡県浜松市の神社を訪れたりと、この仕組みがなければ絶対に訪れなかったであろう場所に幾度も出会ってきた。隣接関係を辿って行くと、カテゴリーには囚われない自分だけの文脈というものが生まれてくる。それによって目的地が、単に観光地だから、あるいは有名だからという理由で訪れるのとは全く別の意味を帯びてくる。つながりを辿る旅を続ける内に、自分の中に自分だけの文脈ができて、新たなユメアトをより深く楽しめるようになっていることに気がつきました。なんの変哲も無い路地に、誰にも気付かれずひっそりと立っている石碑でも、自分の足跡につながるものであれば、宝物を発見したような気持ちになれます。ユメアトこの方法で旅をすれば、興味やカテゴリーによって目的地を選ぶよりも、より未知の世界に足を踏み入れて行く可能性が格段に高くなり、かつ、単にランダムに目的地を選ぶよりも、横のつながりによる文脈が積み重なった、よりリッチな体験として足跡を振り返ることができる。「発見」という観点から言えば、実際に現地に訪れる、物理的に移動するということも極めて重要である。そこには、先ほどの墓地の例のように、物理的(あるいは距離的な)隣接関係による発見が期待できる。実際に出かけてみると思いもよらなかった発見をするというのは、どんな形であれ、旅行をすれば誰でも普通に経験することなのではないかと思う。詳細な記録を付けているので、興味のある方は覗いてみて欲しい。旅行記のまとめも随時更新している。1851年にこの井戸を訪れて詠んだという和歌の歌碑。今年6月に訪れた「桜田門外の変」とここでつながりました。彼が桜田門外で暗殺されるのは、この歌を詠んでから9年後。2018実は以前、沢庵和尚の縁で東海寺に訪れたことがあります。流れが合流することになり、ああ、ここにつながるのかという嬉しい発見になりました。2018さらに、東海寺大山墓地のお墓を見てきたという話をしたら、実は浜松にもお墓があるということを教えて頂き、親切にも地図まで書いて下さいました。地元浜松でもその存在を知る人は少ないのだそう。これはもう行くしかない。2018隣接関係のコンセプトは、本屋に出かけてなんとなく書棚を眺めている内に、元々の目的とは違う本を発見することに似ているかもしれない。振り返ってみれば、インターネットも、そもそもはグラフ構造で発見のプラットフォームだったはずなのに、今ではカテゴリー内に閉じる方向に強化されてしまった。いうものを考えてみた。よる実践にコメントアウトライナーの新しい形を考えるアウトライナーというソフトウェアがある。アウトライナーはその名が表す通り、情報のアウトライン(輪郭)を作るためのソフトウェアである。情報のアウトラインを作るというのは、別の分野の言葉で言い換えれば、知識や考えの「デッサン」をすることに相当するだろうか。考えを文章として精密に表現する前に、その論の構造だけを抜き出して、全体として筋が通るような組み立てを考える。そもそもどのようなときに考えのデッサンをする必要性に迫られるのかを考えてみると、比較的込み入ったことを考えたり、あるいは、ある程度ボリュームのある論理的な文章を書いたりするときなど、頭の中だけでは容易に解決できないような複雑な問題に取り組むときに限られるだろうし、そう考えると日常的にアウトライナーを利用している人はそれほど多くないのかもしれない。それでも、日常生活の中でちょっとした考えをまとめたり、あるいは何か記録しておきたい事柄があった場合に、何らかのツール(紙のノートでも、パソコンやスマホでも)を使ってそれらを「箇条書き」にするという経験は誰にでもあるのではないだろうか。箇条書きにするだけではなく、字下げなどをして項目に階層を持たせて、もう一段深い掘り下げを行なっている人も少なくないのかもしれない。その階層構造の導入がいわゆるアウトラインを作ることに他ならない。字下げをして階層を作れるなら、アウトライナーなんて専用のソフトウェアは必要ないのではと思われるかもしれない。アウトライナーの強みは情報の構造を構造として扱えることにある。同じ階層にある項目を並び替えたり、ある項目を配下の階層ごと別の場所に移動したり、階層の中を上下に移動させたりなど、構造自体の操作を容易にしてくれる。その構造を眺めるときに、ある項目にフォーカスしたり、その場では不要な項目を折り畳んで隠したりと、情報の見え方も柔軟にカスマイズできる。ジャンルとしてはアウトライナーに近いソフトウェアである。以外にもそのようなソフトウェアを以前から作っていて、自分でもそれらを日常的に使ってきたので、アウトライナーというソフトウェアの存在は知っていても、実際にそれを利用したことはなかった。筆者がアウトライナーに抱いていたイメージは、扱う構造がツリー(階層)であるがゆえに、表現できる情報は、ある時点、ある視点からの知識のスナップショットに過ぎないということだった。ツリーというのは一次元の構造である。あるノードは必ず一つのノードに所属し、文脈は一意に固定される。最終的なアウトプットとしては当然スナップショットにならざるを得ないにしても、そこに至るまでの思考の過程においていくつかの文脈が入り乱れることもあるだろうし、そのようなものを表現できる思考のツールが必要ではないかと考えたのだ。ある時『アウトライン・プロセッシング入門』という本にたまたま出会って、それを読んでみたところ、まさに自分が抱いていたような懸念に言及した上で、本来あるべきアウトライナーの利用方法が語られていて、アウトライナーを利用していても結局はそこに辿り着くのだと分かって大きな感銘を受けた。実践的なアウトライン・プロセッシングは、トップダウンとボトムアップを相互に行き来する形で行われます。トップダウンでの成果とボトムアップでの成果を相互にフィードバックすることで、ランダムに浮かんでくるアイデアや思考の断片を全体の中に位置づけ、統合していきます。私はこのプロセスを「シェイク」と呼んでいます。行ったり来たりしながら「揺さぶる」からです。『アウトライン・プロセッシング入門』という感じで、実際には「トップダウンとボトムアップを相互に行き来する」ことで、アウトラインを作る過程で新たに発見した知見を構造に反映していくという、より発見的なアプローチが推奨されている。基本にランダムな入力があって、そこから構造を組み立てていくという、どちらかと言えばボトムアップに焦点を置いたデザインになっているところだろうか。全ての情報がフラットに表示されるタイムライン(複数人で利用する場合はチャットして機能する)と、組み立てられた構造を見せるドキュメントビューやグラフビューが分かれていて、片方はフロー、もう片方はストックという感じで、これらを相互に行き来しながら、構造を何重にも組み立てていくという仕組みになっている。「コト」と呼んでいる)は、複数の文脈に同時に関係しているかもしれないが、ツリー構造ではそれを表現することができない。そこで、関係をもっと自由に作ることのできるネットワーク構造を導入して、Aという文脈におけるX、Bという文脈におけるX、という感じで同じ情報を複数の視点から見れるようになっている。データベース的なソフトウェアだと言えるかもしれない。興味深いことに『アウトライン・プロセッシング入門』では、ツリー構造とネットワーク構造の対立についても言及されている。アウトライナーで扱う「生きたアウトライン」は、見た目はツリーでも通常のツリーよりずっと複雑な内容を扱うことができます。それは「流動的なツリー」だからです。それは常に変化する可能性をはらんだ「プロセス」であり、完成品ではありません。...確かにアウトライン上では、ある記述は「A」と「B」どちらかにしか分類できません。アウトライナーに入っている限り、それはある記述が「A」と「B」のどちらに含まれるべきかという思考プロセスの、最新のスナップショットにすぎません。今「A」に分類されている内容が、次の瞬間には「B」に再分類される可能性を常にはらんでいます。見た目上「A」に分類されているけれど、同時に「B」でもある可能性が常にある。それはもはや単純なツリーではありません。...そして重要なのは、アウトラインを最終的に完成品(たとえば文章)としてアウトプットするためには、いずれにしても「A」か「B」かを選ばなければならないということです。複雑なものを勇気を持って単純化しなければならない瞬間がくるのです。そのこと自体に思考を強制し、発動する効果があります。実は発想と呼ばれるものの多くが、この強制的な単純化から生まれてくるのではないでしょうか。「文章にしたり人に説明したりするとその対象がよりよく理解できる」と言いますが、それは複雑で絡み合った情報を、単純なツリーやリニアな語りに強制的に変換しなければならないからです。その過程で情報は咀嚼され、自分の視点が確定します。アウトライナーで編集されるアウトラインは、「流動的なツリー」であることでそのプロセスを促すのです。一方の網目構造では、複雑なものが複雑なまま存在できてしまいます。それは一見するといいことですが、ともすると素材が素材のままになってしまう可能性があります。情報を保管し、必要に応じて引き出すということを第一義に考えれば、複雑な情報を複雑なまま扱える網目構造のほうが優れているかもしれません。「文章を書き、考える」道具、つまり発想ツールとしてみた場合の有効性は、アウトライナー否定派がいうほど単純には決められないのです。採用するネットワーク構造(網目構造)に対して、説得力のある反論になっている。基本的にはそれほど違いはないと個人的には考えている。これはツールというよりもマインドセットの問題だからだ。この問題はプログラミング言語における、オブジェクト指向と関数型の対立に似ている。世の中にはオブジェクト指向言語とか、関数型言語というカテゴリーでプログラミング言語が分類されることがあるが、それらのカテゴリーがプログラムデザインのマインドセットを決定するわけではない。オブジェクト指向言語で関数型プログラミングを実践することは可能であるし、同じように関数型言語でオブジェクト指向プログラミングを実践できる。個々のツールがどういうアプローチに向いているかという傾向はある。データベース的というのは、その傾向を表している。しては、現状のアウトライナーではなかなか難しいと思われるアプローチを可能にしていきたいところである。することによって、知的生産の可能性を少しでも広げていきたい。そのためには『アウトライン・プロセッシング入門』で紹介されているアプローチの先にはどのような展開があり得るかということについて考えなければならない。その一つの可能性が「コトノマ」というコンセプトである。データベースでは、アウトライナーの一つの項目に相当する「コト」という単位の情報が相互につながりを持って、単純なツリーではなく、自由なネットワークを構成できるようになっている。ネットワークが大きくなるにつれて、他より多くのつながりを持つコトが現れるだろう。そのようなコトは、参加者にとって重要なコンセプトを表している可能性が高い。そのコトを「コトノマ」に格上げすることによって、そのコンセプトについてさらに深く掘り下げることができるようになる。この機能は、アウトライナーの「フォーカス」という機能の発展形だと言えるかもしれない。アウトライナーの持つ「文章の集合体」としての性質は、アウトライナーを開発する側でも必ずしも意識していない場合があるように感じます。この点に自覚的なアウトライナーは、それをサポートする「フォーカス」という機能を持っています(アウトライナーによって「ズーム」「ホイスト」「巻き上げ」などとも呼ばれます)。ひと言でいうと、アウトラインの中の任意の項目を一時的に最上位階層として表示する機能です。他の項目は見えなくなるので、その項目に集中することができます。『アウトライン・プロセッシング入門』コトノマは、そのテーマについての情報を集めるための専用のタイムラインを持つ他は、他のプレインなコトと同様に扱うことができる。ネットワークの中で重要なポイントを表すための特殊なコトだと言えるだろう。ネットワークを育てる内に、その過程で発見した重要な事柄がコトノマとしてネットワーク状に結節点を作る。そのコトノマのリストは、ネットワークを育てた参加者の足跡であると同時に、外からデータベースを見るときの入り口としても機能する。基本的な考え方で、アウトライナーと一線を画すのは、そもそもデータベース的なシステムだということもあるが、一人の人間がその全貌を掴めないぐらいの膨大なネットワークを作るというユースケースまで想定しているところだ。一人で利用するケースから、チーム、不特定多数のコラボレーションまで、あらゆる情報を蓄積して巨大なネットワークを作る。そのときそのときに必要なアウトプットのために、スナップショット的なツリーを作ることはあっても、全体として綺麗に整理された状態を保つということにはこだわらない。野口悠紀雄氏が「「超」整理法」で書いていたように、探すための分類・整理は結果的に徒労に終わることになるし、整理は情報を既知のカテゴリーに収めることになって、むしろ新しい発見を遠ざける原因になってしまう。「発想と呼ばれるものの多くが、この強制的な単純化から生まれてくる」という仮説が、確かにそうかもと思わせる一方、拙速な整理が、結局のところ既知のカテゴリーに立ち返ってしまう原因になるのではないかという予感もある。何か新しいことを発見するために、カテゴリーは結果として横断されなければならない。そのために「コトノマの連鎖」というものが重要になってくるのではないかと考えている。投稿した情報を眺めていく過程で生まれたコンセプトをコトノマに変換し、そこからまた発見される隣接概念をまたコトノマ化する。そのような隣接概念の渡り歩きによって生まれるネットワークを可視化することによって、その足跡が結果として未知のカテゴリーを生むのではないかと期待している。枠組みが、とりあえず一通り出来上がってきたので、実験しながら改善策を探るというフェーズに入っている。公開でその実験を行なっているのだが、参加者がまだ少ないものの、会話の中からストックとなる情報を組み立てる過程が少しずつではあるが現れてきている。その循環のプロセスは以下の通りである。普通のチャットのように、タイムラインにただ投稿したものは構造のないフラットな、時系列の情報になる。これがいわゆるフローの状態だ。情報はどんどん流れていって、常に最新の情報だけを目にすることになる。reply(返信)をすることである。よって、時系列の上に、文脈(話題)の構造が生まれる。この仕組みは全く新しいものではなく、2chの安価やツリー型の掲示板など、Webの黎明期からあちこちで利用されている。その構造を見せる方法には色んなバリエーションがある。タイムラインに複数の話題が混在していても個別に遡っていくことができる。連鎖によって生まれたスレッドを同時に複数開いて比較することも出来る。流れていかないように確保する。しておくかという判断は思ったよりも単純ではない。気ままにチャットを楽しんでいるようなときは、そのようなアクションがあることさえ忘れてしまう。自発的な選択という行為は案外ハードルが高いし、会話に参加する人数が多くなるほど、何を選択するか、という問題の重みは大きくなる。UIのデザインでその障壁を下げることは可能かもしれない。関係となるようなコトを追加して構造を作っていく。区別はなく、双方ともポストとポストの間にコネクションを作って辿れるようにする、という同じアクションである。将来的にはコネクションのタイプを指定できるようにしても面白いかもしれない。最後はコトのコトノマ(カテゴリー)化。重要なステップである。「コトノマ」とはチャットの文脈で言えば、いわゆるチャットルームに相当するものである。コトをコトノマに変換することによって、その話題についての専用のチャット・タイムラインを用意でき、議論をさらに掘り下げることが出来る。同時に、コトノマはコトと同じように扱えるので、相互に繋げたり、タイムラインにポストしたりすることも出来る。最終的な目的は、このコトノマのネットワークを作ることである。コトノマは、タイムラインでやり取りされている内容から自然に生まれてくるのが望ましい。ここまでの流れを追うと、コトノマが出来上がっていく過程というのは、基本的には「連想」によって駆動されることになる。あるテーマについて話しているときは、その隣接概念がコトノマの候補として上がってくるケースが多い。個人的にはこの連想だけだとつまらないと思っている。それとは少し違う方法でコンセプトの発見に誘導できないか、というのが今後の大きなテーマである。Cotoamiコンセプト考何気ない会話からどうやってストックに耐え得る知識を引き出すか?にコメントチャットでウィキペディアをつくる例えば、何か新しいことを始めようと思うと、どうしても「新しいことを始める」ためのフォーマットに乗っかってしまう。これは、「やるぞ」っていう意気込みが強ければ強いほど、むしろそうなってしまったりするし、その何かをやろうという構えが、本当はもっと柔軟に考えられたかもしれない可能性を狭めることになったりしないだろうか?例えば、新しいことを始めるぞということで、いついつどこに集まってブレストでもやろうということになって、立派な会議室なんかを予約して、場合によっては上司や先輩、あるいはよく知らない人などが集まった空間で、本当に価値のあるアイデアが出たりするものなのだろうか?それよりも、日頃たわいもなくしている雑談で、ふざけたりしながらいろんな話題を縦横無尽に移動する中で、「これってそもそもこういうことじゃない?」とか「これとこれを組み合わせたら面白そう」みたいな気づきから、自然にコンセプトが浮き上がってきて、それが結果として「ワタシたちの百科事典」になるような仕組みあったとしたら、それが本当に自分たちがやりたかったこと(必要だと思ったこと)の種になるんじゃないだろうか?例えば、みたいな会話が、という感じで「煽り運転」というテーマに辿り着く。そのテーマにつなげる形で、あちこちで見つけてきた情報を投稿していく。このテーマについて、もっと深く掘り下げる場所を作っておきたいということであれば、みたいな感じで、発言内容から新しいチャットルーム(ここではコトノマと呼んでいる)を作る。このコトノマが、会話に参加している人たちにとっての百科事典の項目になる。ひらめくTakeo氏、その勢いで新しいコトノマを作る。これはあくまでも例なので内容については深く考えないで頂きたい。いうことをやろうとか、こういう情報が必要だろうという予断を持つよりも、興味のまま、話を面白そうな方向へ転がす時に出てくるキーワードを拾い上げたり、それらの間にネットワークを作ったりすることによって、本当に自分たちが必要とするオリジナルなアイデアを生み出す。それが「チャットでウィキペディアをつくる」という実践である。流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。2017、2日目の記事になります。その辺を期待している方はブラウザ(のタブ)をそっ閉じして明日の記事にご期待下さい。いうよく分からないアプリケーションを作ったりしています。今回は、まだ駆け出しの関数型プログラマーである筆者が、関数型プログラミングの洗礼を受けたことによって、長年慣れ親しんできたオブジェクト指向に対する見方が変わってきたという話について書いてみたいと思います。言えば、外国語を勉強することで、初めて日本語というものを客観的に見る機会を得たという体験に似ているかもしれません。90年代からゼロ年代の中盤ぐらいまでにオブジェクト指向でプログラミングを始めた人間にとって、その考え方はプログラムデザインの共通言語のようになっていて、それ自体を疑うということには、なかなかなりづらい状況が長く続きました。ような著名な人たちがオブジェクト指向に対する批判や懐疑を表明しても、「使い方の問題だよね」という感じで、オブジェクト指向そのものの問題ではないというのが多くの支持者の反応だったように思います。凝集性(cohesion)とは何なのか?」)。fallacy(本当のスコットランド人なら◯◯などしない論法)」だとの指摘もあります。そもそもオブジェクト指向への批判が、関数型プログラミング界隈から行われることが多かったということもあり、その筋の人たちにとっては自明のことでも、オブジェクト指向しか知らない人たちにとっては、その指摘自体をうまく理解できないという非対称な構造がありました。Explicitnessそのような状況の中で、オブジェクト指向への敬虔な信仰を残したまま、関数型プログラミングの門を叩いたわけですが、そこでいきなりオブジェクト指向の中心的な価値を全否定されるという事件が起こります。ゆびてくオブジェクト指向では、状態というものがインタフェースの向こう側にあって、どのように実現されているか見えないようになっており、それがカプセル化、あるいは情報隠蔽と呼ばれる、複雑さを扱う技術の核心になっています。ところが、関数型プログラミングでは状態の遷移を隠さずに、関数の入出力として表現しようとします(状態の遷移が入出力で完結している時、この関数を「純粋な関数」と呼ぶ)。状態遷移が関数の入出力に限定されている時、プログラムの動作を把握するのは飛躍的に楽になります。一方で、オブジェクト指向ではプログラム上は簡潔に見えても、水面下に沢山の状態が隠されているので、何か問題が起きた時に状況を把握するのは容易ではありません。作者)「欲しかったのはバナナだけなのに、それを持ってたゴリラどころか、ゴリラがいたジャングルごとついてきた」って、分かりやすくてなかなか面白い表現ですが、それを言ったら、関数型だってバナナだけじゃ済まないだろっていう話もあるような・・・ところが、なぜオブジェクト指向が状態遷移を隠蔽していたかと言えば、インターフェースに対してプログラミングすることによって、プログラムが実現すべき要求だけを簡潔に表現できるということがあったと思います。せずに、単純に状態遷移を全て入出力で表現しようとすると、プログラムはとても読み辛いものになってしまいます。この関数型特有の問題に対応するため、いくつかの関数型言語ではモナドという「本来の計算とおまけを切り離す」ための仕組みが導入されており、これはオブジェクト指向でやっていた情報隠蔽が形を変えて現れたと言えるのかもしれません。ゆびてく興味深いのは、オブジェクト指向と関数型で、状態の扱いに関して言えば、全く逆の考え方になっているところです。オブジェクト指向では複雑性を扱うための核心となっていた考え方が、関数型プログラミングでは悪として扱われている。いう疑念が立ち上がってくることになります。参加して、そこで教えて頂いた、Elmアプリケーションのプログラムデザインについての動画を見ている内に、オブジェクト指向と関数型プログラミングはそもそも両立しないのではないかという印象はさらに強くなっていきました。この動画を見る限り、Elmのコミュニティには、オブジェクト指向からの編入組が結構いるのではないかという印象を受けます。いうのも、そこで語られていたのは、コンポーネントという、オブジェクト指向的なデザインを導入したみたけれど、どうもうまく行かなかったので、一度その辺の考え方をリセットして、もっと原理的なところからプログラムデザインを考え直してみようという話だったからです。動画の中で、オブジェクト指向と関数型というのは、プログラミング言語の問題というよりもマインドセットの問題なのだという話が紹介されています。言語のパラダイムとは関係なく、プログラマがオブジェクト指向のマインドセットでコーディングしていれば、たとえElmのような純粋関数型の言語であっても、オブジェクト指向的にデザインされてしまうということです。そのように考えると、マルチパラダイムの言語では、良く言えば、プログラマのマインドセットによって多彩なプログラムデザインが実現できるということになるけれど、悪く言えば、互いに相容れない複数のマインドセットを想定している場合は、単に混乱の元になるだけではないかという感じがして来ます。氏による「小さな関数は有害だと考えられる」というタイトルの記事です。Code」に書かれているような、オブジェクト指向時代に生まれた設計指針は、むしろ過剰な構造化を誘発して、可読性や柔軟性を欠いたコードになることが多いのではないかという、いかにもその筋で炎上しそうな指摘をしています。この指摘の背景には「そもそもオブジェクト指向が想定する抽象化が容易ではない」という問題意識があります。抽象化が容易でないのに、オブジェクト指向の設計指針には、その分割が本当に必要だと確信できるより前に、プログラムの分割を進めさせてしまうような圧力があります。Principle)SRPでは、「1つのクラスは1つの責務を持つ」を原則とします。1つのクラスに持たせないこと。