ExcelからElixirマスター番外編：なぜElixirや関数型は「難しい」と感じるのか？

【本コラムは、5分で読めます】
piacereです、ご覧いただいてありがとございます

前回で、入門編としての本連載は完了しているのですが、こんなにカンタンなはずのElixirや関数型言語の習得になぜ難航するかを整理してみます

Excelにしたのは「オブジェクト指向」の頭を避けるため

第2回の「forはforでは無い」では、for という、オブジェクト指向（以降OOPと略）の世界で慣れ親しんだもの（しかし実際は同じ for でも全く異なる for）を出すと、既存の知識に当てはめながら、Elixirを覚えていってしまう危険性について言及しました

そこには、「Enum.map という新しい概念を覚えなくても、for で良いでは無いか」といった、過去のパターンへの依存があり、パラダイムを移行することを阻害することもお伝えしました

そこを回避するために、for よりも先に、Enum.map を解説した訳です

「ExcelからElixirをマスターする」という尖ったテーマにした背景にも、同様の理由があり、以下2点の狙いがあったのです

１）Excelという、誰もが知っているものから入った方が覚えやすい　←主にプログラミング初心者向け
２）純粋に、OOPから離れた方が、素直にElixirを覚えやすい　←プログラミング経験者向け

本コラムは、上記２）について解説するのが趣旨です

それでは、OOPがどういったポイントでElixirの習得を阻害するのか、整理してみます

①「OOP」から「Elixir」の単純さは理解しにくい

皆さんが、OOPに初めて触れたとき、簡単なものだと感じましたか？

恐らく、それなりに「複雑なもの」だと理解し、時間をかけて習得していったのでは無いかと思います
（特に、手続き型言語に慣れていた方にとっては、かなりのギャップを感じたと思われます）

その習得を行っている間、OOP特有の以下慣習（以降では「概念」と呼びます）を、一気に全部、覚えたのでは無く、「徐々に使ううちに慣れていった」のでは無いでしょうか？

• クラス
• インスタンスの生成
• インスタンスのメソッド呼出
• インスタンスのメンバー変数へのアクセス（状態保持）
• メソッドやメンバー変数のアクセス制御（public、protected、private）
• 継承
• オーバーライド／オーバーロード
• インタフェース／型クラス
• クラス継承階層設計
• 階層的なネーミング設計
• 表層的なデザインパターン（Factory Method、Adapter、Templateなど）
• 構造的なデザインパターン（MVC、Composite、Decoratorなど）
• 振る舞い的なデザインパターン（Iterator、PubSub、State／Strategyなど）
• プロトタイプ
• ミックスイン／トレイト／ジェネリクス／多重継承、などなど．．．

そして、別のOOPを習得する際、これら概念が適用できたり、習得済み言語から引用できるため、あまり複雑さを感じることは無く、比較的、容易に習得できたのでは無いでしょうか？

上記リストを再度、ご覧ください

改めて見返すと、それなりに複雑な概念群をマスターしているのです

これはつまり、「OOPというパラダイムをマスターした『高み』にいる」状態であり、そのマスターした状態から、別のOOPを習得するのは、「過去の成功体験の繰り返し」 を行っている、とも言えます

一方、Elixirを見てみましょう

本連載で出てきたElixirの概念は、Enum.sort、Enum.filter、Enum.map のたった3つの関数と、「リスト」「マップ」の2つのデータ構造だけの、実に単純なものでした

ループやカウンタ、分岐すら使っていません

たったそれだけでも、Web＋DBアプリや、Web＋APIアプリは開発できたのです

実際、第5回の終盤でご紹介した下図のデータサイエンスプロダクトは、上記5つの概念と、多少のリスト操作を覚えれば、比較的カンタンに作れます

Web入力とDB更新、計算主体のロジックを作るには、もう少し覚えることがありますが、それでも同じことをOOPで行うよりも、10～20倍、シンプルだったかと思います

このように、ElixirとOOPでは、必要な概念・情報量のギャップが大きいため、OOPとの比較で見ていくと、あまりに単純過ぎるElixirを理解できない … という現象が起こります

つまり、「過去の成功体験の繰り返し」 が機能しないのです

Elixirを覚えていくこの先には、

• メンバー変数やグローバル変数のような『状態』を簡単に持てない
• 一度、代入した変数は、変更できない

といった、OOPでの慣習からすれば信じられないような概念も出てきます

しかし、これらElixirの概念は「メンバー変数による状態保持が大半のシーンで不要である」… つまり、「冗長さを排除できる設計改善の機会」となります

同時に、CPUやメモリを最大限活用し、シンプルな並行・並列プログラミングを実現するためにも大事な概念です

これらから言えることは、いつまでも 「過去の成功体験の繰り返し」 にしがみつくと、現代型開発の恩恵が受け取れなくなる … ということです

②プログラミング言語もパラダイムが異なれば全くの別物

上記ギャップは、「過去の成功体験の繰り返し」が機能しない、というだけで無く、ある種の妙な心理影響も引き起こします

たとえば、「xxxというプログラミング言語を習得できたのだから、Elixirも習得できるだろう」といった考えですね

しかし実際は、なかなか習得が進まない、という現実にブチあたり、そこから落胆や諦めに繋がります

多くのOOP経験者が、Elixirを始めとする関数型言語に移行できない裏側には、こんな心理的なギャップもあり、その深層には、「プログラミング言語だから同じ」という思い込みや誤解が、大きく作用していると考えます（もう1つの大きな理由は③にて後述します）

同じプログラミング言語でも、パラダイムが異なれば、全くの別物なのです

「パラダイムシフト」とは、まさにこのような状況を指しており、以前のパラダイムにおける知識やノウハウは、全く役に立ちません

役に立たないどころか、新しい概念の素直な理解・習得を阻害さえします

イメージとしては、波の流れが変わるポイントでは、以前の波の乗り方は、全く通用しないし、それを「いや、このままでいいんだ」と自分勝手な理屈でムリヤリ押し通したところで、波に飲まれるだけ、といった感じです

関数型言語の構文上でOOPを試したくなったり、ピュアな関数型言語よりもマルチパラダイム言語を選びたくなる … なんてのも、そうしたノイズの一種です

パラダイムシフトに対して取り得る最善策は、「過去のことは一切忘れ、素直にゼロから学び直す」という、ストレートでシンプルなやり方です

Excel／Googleスプレッドシートという、プログラミング言語とは言えないような、しかしリスト操作の基本が詰まっている題材は、このゼロから学び直す機会というものを素直に与えてくれます

ただ …

現実的には、OOP経験者の全員が、ゼロベースから学び直せるかと言えば、そうでも無いため、Elixirや関数型言語にシフトできない層も一定数、発生するでしょう

そこで起こることは、OOPをそもそも知らない世代への「世代交代」かも知れません …

実際、今の20代は、OOPを「常識」とは思っていないし、下手をすると、OOPに触れること無く、プログラマとしての仕事に着いていることもあります

そんなことも頭の片隅に置いて、自分の成長と、採用や新人育成、組織構築を見ていくと、ITの進化の波や、時代の波に飲まれずに、ゼロから学び直す姿勢を作るヒントになるでしょう

③関数型のことのように見える大半は、関数型と関係無い

もう1つ、OOPから来たプログラマが、関数型言語に脱落するポイントの代表に、以下のような新たな概念を羅列されるケースがあります

• ラムダ式／無名関数
• 高階関数
• カリー化
• パーシャルファンクション（部分関数）
• 遅延評価
• 副作用
• クロージャ
• 再帰（ループが無い）
• 部分適用
• 参照透過性
• ファンクタ／アプリカティブ／モナド
• 圏論

これらOOPからかけ離れた概念を真正面から受け取ると、プログラミング経験の大小に関わらず、きっと辛いものとなるでしょう

しかし実は、「Elixirや関数型言語を習得する上で必須では無い」と聞いたら、受け取る印象も随分と変わるのでは無いでしょうか？

実際、本連載の中で使った概念は、「ラムダ式／無名関数」だけです

しかも、それを「ラムダ式／無名関数」とは表現せずに、説明を完結させました

ですので、本連載でWeb＋DBやWeb＋APIを作った方は、「ラムダ式／無名関数」という単語を知らなくても、ElixirでWeb＋DBやWeb＋APIを開発できるようになっている … という訳です

後々、人と会話する中で、説明のために用語を覚えていく必要性は出てくるかも知れませんが、純粋に開発を行うだけであれば、特に必要無いのです

ちなみに上記概念の大半は、「関数型言語の概念ですら無い、各言語固有の概念」だと言ったら、「えっ！？」と驚くのでは無いでしょうか？

この詳細について知りたい方は、こちらのコラムをご覧いただくと、雰囲気が伝わるのではないかと思います（けっこう長いですが）

更に、「Elixirでは、上記概念のほとんどを知る必要も無い」と言ったら …

「今までの関数型で右往左往させられたのは、一体なんだったんだ…」という怒りの声すら聞こえそうです

実際、私もElixirに出会うまで、ずいぶんと右往左往させられた感じで、脱落とカムバックを繰り返しました

ここには、関数型言語の啓蒙や教育、情報流通に関する、大きな課題があるのでは無いだろうか、と感じています

終わり

Elixirには、上記のような状況を好転させるパワーやポテンシャルがあると実感し、「ExcelからElixirマスター」という本連載を書き上げました

また、「fukuoka.ex」というコミュニティで、Elixirのプロダクション採用推進や、エンジニアへの啓蒙を継続的に行っているのも、同じ動機からです

普段の仕事の中でも、Elixir／Phoenixからの恩恵を多大に受けており、「高い開発効率」と「膨大なデータやアクセスの高速処理」を両立しており、更に「サービス停止や障害の少なさ」にも助けられています

私も含む「fukuoka.exアドバイザーズ」の面々も、似たような体験をしており、そうした体験をインタビュー形式でまとめた記事がありますので、本連載でElixirに対する興味を持ったり、高まった方には、きっと面白い内容だと思いますので、ぜひご覧ください

インタビュー第1回：fukuoka.ex代表「piacere」

インタビュー第2回：SIマイスター「つちろー」と性能探求者「enぺだーし」

インタビュー第3回：カーネルハッカー「ざっきー」と今後の「fukuoka.ex」の展開

また、福岡近辺にお住まいの方であれば、6/22（金）19時に天神で、「fukuoka.ex#11：DB／データサイエンスにコネクトするElixir」というMeetUpに遊びに来てください

特別ゲストは、Erlang／Elixirの両面で世界的に有名な「力武 健次さん」と、北九州の飯塚市で「e-ZUKA Tech Night」を6年間主催し続けるハウインターナショナルの「谷口 耕平さん」のお二人と、実に豪華なイベントです

私は、「1家に1台、パーソナルなデータ分析AIを全員が持つ2020年を作る」というタイトルで、Elixirによる、ブラウザUI上からサクっとデータ分析プラットフォームを披露するLTをお届けします

また、fukuoka.exの発足から、ちょうど1周年となる、記念的なイベントでもあるため、このコラムを気に入っていただいた方と、ぜひ一緒に盛り上がりたいです

大人気により、一度は満席となりましたが、増枠しましたので、下記URLよりご参加ください
https://fukuokaex.connpass.com/event/87241

次回は、更にフロント側の表現力を上げていく、Vue.jsとPhoenix APIの連携 を行います

また、本連載のエッセンスを使いつつスタートする新シリーズ「関数型でデータサイエンス」もお楽しみください