Help us understand the problem. What is going on with this article?

Excelから関数型言語マスター番外編:なぜ関数型言語は習得できないか?

(この記事は、「fukuoka.ex(その2) Elixir Advent Calendar 2017」の3日目、
  および「Elixir Advent Calendar 2017」の4日目です)

昨日は、@takasehideki さんの「ElixirでIoT#1.1:ラズパイへのErlang/Elixir環境の構築」でした


fukuoka.ex代表のpiacereです
今回もご覧いただいて、ありがとうございます:bow:

この連載の、前回までの記事は、以下になります
 |> Excelから関数型言語マスター1回目:行の「並べ替え」と「絞り込み」
 |> Excelから関数型言語マスター2回目:「列の抽出」と「Web表示」
 |> Excelから関数型言語マスター3回目:WebにDBデータ表示
 |> Excelから関数型言語マスター4回目:Webに外部APIデータ表示
 |> Excelから関数型言語マスター5回目:Webにグラフ表示

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


:shamrock::shamrock::shamrock::shamrock: お礼:各種ランキングに43回のランクインを達成しました :shamrock::shamrock::shamrock::shamrock:

4/27~5/19までの23日間、毎日お届けした「季節外れのfukuoka.ex Elixir Advent Calendar」 は、Qiitaトップページトレンドランキングに4回、「はてなブックマーク」のホットエントリー「テクノロジー」カテゴリに2回もランクインし、他ランキングも含めると、トータル43回ものランクインを果たしました

Qiita「いいね」数は合計349件もいただき、fukuoka.exアドバイザーズとfukuoka.exキャストの一同、みなさまの暖かい応援に励まされていますので、引き続き、「季節外れのfukuoka.ex(その2) Elixir Advent Calender」でも応援お願いします:bow:

image.png

Excelにしたのは「オブジェクト指向のパターン」から離れてもらうため

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

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

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

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

1)Excelという、誰もが知っているものから入った方が覚えやすい ←主にプログラミング初心者向け
2)オブジェクト指向言語から離れた方が、素直にElixirを覚えやすい ←プログラミング経験者向け

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

それでは、既存のオブジェクト指向言語が、どういったポイントでElixirの習得を阻害するのか、整理してみます

加えて、関数型言語そのものの課題のようなものについても、少し触れます

※ネタ的に、怖い人も来そうなので、どうか微笑ましい目で、以下、眺めてあげてください (^_^)

①「オブジェクト指向」から「Elixir」の単純さは理解しにくい

皆さんが、オブジェクト指向言語に初めて触れたとき、簡単なものだと感じましたか?

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

その習得を行っている間、オブジェクト指向言語特有の以下慣習(以降では「概念」と呼びます)を、一気に全部、覚えたのでは無く、「じょじょに使ううちに慣れていった」のでは無いでしょうか?

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

そして、次のオブジェクト指向言語を習得する際、これら概念が適用できたり、習得済み言語から引用できるため、あまり複雑さを感じることは無く、比較的、容易に習得できたのでは無いでしょうか?

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

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

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

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

本連載で出てきた、Elixirの概念は、「Enum.sort()」「Enum.filter()」「Enum.map()」のたった3つの関数と、「リスト」「マップ」の2つのデータ構造だけの、実に単純なものでした(WebやDB、外部APIの知識は、オブジェクト指向言語でも共通なので除く)

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

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

image.png

Web入力やDB更新、計算主体のロジックを作ると、もう少し覚えることはありますが、それでも同じことをオブジェクト指向言語で行う1/10~1/20程度に留まるでしょう

このように、Elixirとオブジェクト指向で必要な概念・情報量のギャップは、相当大きいため、オブジェクト指向言語の概念に照らし合わせることでは、あまりに単純過ぎるElixirを理解できない...という現象が起こります

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

Elixirを覚えていくこの先には、「メンバー変数やグローバル変数のような『状態』を簡単に持てない」であったり、「一度、代入した変数は、変更できない」といった、オブジェクト指向言語からすれば、信じられないような概念も出てきます

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

同時に、CPUやメモリを最大限活用し、シンプルな並行・並列プログラミングを実現する上では、非常に大事な概念なので、いつまでも「過去の成功体験の繰り返し」にしがみつくと、設計/性能の両面で、恩恵を受け取れなくなります

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

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

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

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

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

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

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

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

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

image.png

関数型言語の構文上でOOPを試したくなったり、ピュアな関数型言語よりもマルチパラダイム言語を選びたくなるのも、こんな背景があるのでしょう

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

Excelという、プログラミング言語とは言えないような、しかしリスト操作の基本が詰まっている、地味に関数型言語に近いエッセンスを持つ題材は、このゼロから学び直す機会というものを素直に与えてくれます

ただ...

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

そこで起こることは、オブジェクト指向言語を一切知らない世代への「世代交代」かも知れません...

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

③関数型言語の概念のように見える大半は、関数型言語と関係無い

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

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

これらオブジェクト指向言語からかけ離れた概念を真正面から受け取ると、プログラミング経験の大小に関わらず、きっと辛いものとなるでしょう

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

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

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

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

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

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

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

image.png

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

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

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

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

終わり

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

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

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

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

インタビュー第1回:fukuoka.ex代表「piacere」とグロースハッカー「ゆじかわ」

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

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

image.png

また、福岡近辺にお住まいの方であれば、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

image.png

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

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

明日は、@tuchiro さんの「ElixirでSI開発入門 #6 Ectoで自由にSQLを書いて実行する(更新編)」です

p.s.「いいね」よろしくお願いします

よろしければ、ページ左上の image.pngimage.png のクリックをお願いしますー:bow:
ここの数字が増えると、書き手としては「ウケている」という感覚が得られ、連載を更に進化させていくモチベーションになりますので、もっとElixirネタを見たいというあなた、私たちと一緒に盛り上げてください!:tada:

piacerex
福岡でプログラマしながらIT商社とIT企業を経営してます。Elixir/Kerasをよく使う。Elixirコミュ#fukuokaex、福岡理学部#FukuokaScienceを主催。プログラマ歴36年/XPer歴19年/デジタルマーケッター/経営者/CTO/技術顧問数社。 シボと重力子放射線射出装置は別腹(^^)
https://github.com/piacerex
karabiner
主にシステム開発・アプリ開発・ Webサイト制作を行う会社です
http://www.karabiner.tech/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした