0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

量より質への転換――如何にして関数型言語とLISPはプログラミングの本質を覚醒させるか

0
Posted at

量より質への転換――如何にして関数型言語とLISPはプログラミングの本質を覚醒させるか

序:粗悪なるコードの量産に惑わされるな

昨今のプログラミング教育、あるいは世に溢れる技術論においては、「まずは一万行のコードを書け」「動くものを大量に作れ」といった、いわゆる「圧倒的量派」の言説が主流を占めているように見受けられる。
確かに、これは初学者が「構文(シンタックス)に親しみ」「エラーへの恐怖心を克服する」という初期段階においては、極めて有効な処方箋となり得よう。しかし、これらはあくまで歩行訓練の域を出るものではない。
もし読者諸氏の中に、LISPや関数型言語(HaskellやOCaml、あるいは現代的言語における関数型アプローチ)の概念に触れ、脳裏に一筋の光明が差すようなブレイクスルーを経験された方がいるならば、それは「作業という名の量」から「構造の理解という名の質」へと、プログラミングの次元が劇的に向上した動かぬ証拠である。
なぜ、粗悪なコードをいくら積み重ねても本質という高みには辿り着けないのか。 tender な新芽を摘むような真似はせぬが、なぜ関数型言語がその硬硬たる壁を打ち破るのか。ここに、その三つの理(ことわり)を論じてみたい。

一、命令型は「手順」を語り、関数型は「構造」を明かす

多くのプログラマが最初に手にするC、Java、あるいは一般的なPythonなどの言語は、その大半が「命令型言語」に分類される。これらは計算機に対する「手続きの指示(まずAを実行せよ、次にBを処理せよ、その結果を変数に代入せよ……)」に他ならない。
読者諸氏も省みられたい。このようなコードを量産しているとき、我々は単に「如何にして(How)動かすか」というパズルを解いているに過ぎない状態に陥りがちである。その結果として生み出されるのは、状態管理の混迷を極めた、いわゆる「スパゲティ・コード」である。動くには動くが、書いた本人でさえその全容を把握できぬ粗悪なコードが積み上がる原因は、ここにある。
然るに、LISPをはじめとする関数型言語が提示する世界は、「何であるか(What)」、すなわちデータと処理の依存関係(構造)の記述である。
・不変性(Immutability):状態を安易に変化させない
・副作用の分離:計算の純粋性を保つ
・高階関数:処理そのものを「値」として等しく扱う
これらの洗練された概念に邂逅したとき、我々の脳内における認知負荷は劇的に軽減される。「コードを美しく整理する」とは如何なることか、その本質(=質)が、霧が晴れるが如く見えてくるはずである。

二、LISPの神髄――「データとコードの等価性」という地平

特にLISP(Common Lisp, Scheme, Clojureなど)という、計算機科学の古典でありながら究極の言語に触れるとき、プログラミングのパラダイム(範式)は完全に覆る。
LISPが内包する最大の特徴、それは「コードもデータも全く同じ形式(S式)で表現される」という事実である。これを通称「同実異名性(Homoiconicity)」と呼ぶ。

「自分が記述しているコードそのものが、単なるデータのリストであり、それをマクロによって自由に変形・拡張できる」

この領域に達したとき、プログラマは「言語という既存の枠組みに縛られてコードを書く」という奴隷的拘束から解放される。眼前に横たわる問題を解決するために、「言語そのものを拡張する」というメタ(高次)的な視座を獲得するに至るのだ。
この抽象化の視座を持たぬまま、既存の言語仕様の枠内でいくら低品質なコードを量産したところで、プログラミングの本質的な抽象化能力が身につくはずもないのである。

三、「真に優れた抽象化」の妙味を知ること

「量」に固執する徒が陥りがちな罠は、安易な複写(コピペ)や、似て非なる条件分岐(if文)の乱造である。これらは打鍵(タイピング)の鍛錬にはなろうとも、設計(デザイン)の訓練には到底なり得ない。
関数型言語の作法、すなわち map, filter, fold/reduce といった高階関数や、カリー化、パターンマッチングの美しさを知るが良い。そこには、「たった数行で構成され、もはやバグが混入する余地すら存在しない美しいコード」が厳然として存在する。
この「圧倒的高質なる抽象化」の快感を知ったプログラマは、例えその後、再びオブジェクト指向言語などの実用言語の地平に戻ったとしても、紡ぎ出すコードの「筋(すじ)」が劇的に向上していることに気づくであろう。自らの手から生み出されるコードの品格が変わるのである。

結び:鋳造の理を学んだ技術者へ

古き格言にこのようなものがある。

「百の粗悪なフライパンを作るより、一つの美しい鋳造技術を学ぶ方が、結果として優れた料理人を研ぎ澄ます(sharpening)」

「動けば良い」という次元の「量」をこなすフェーズは、既に過去のものとなった。計算機科学の峻厳にして美しいロジックという「質」に触れたからこそ、諸氏の脳内回路は接続され、「真に理解した」という境地に達したのである。
その思索の方向性は、完全に正解である。ここで得た知見は、一過性の流行に左右されぬ、一生モノのプログラミングの武器( intellectual weapon )となることを確信されたい。
良きプログラミングの旅路を。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?