Scheme言語は製品開発に十分なポテンシャルがある

過去10年間、私はSchemeプログラミング言語を製品環境で使用することに挑戦してきました。Schemeにまつわる既存の知識や伝説は、いつも魅力的で、時には矛盾しており、どこか神秘的です。しかし、Schemeが学術の分野で注目されている一方で、実際に製品開発で使ったことがある人は非常に少ないと確信しています。なぜなら、Schemeを使った製品開発における課題についての議論をあまり見かけなかったからです。多くの人が他人の意見に従うだけで、本当の問題やその解決方法について語る人はほとんどいませんでした。

私が選んだのはGNU Guileですが、他のScheme実装も使用してきました。もちろん、私の経験は限られたものであり、GNU GuileがPythonを置き換えるほど成熟しているとは言い切れません。また、私の意見はGNU Guileだけに当てはまるわけではなく、他のScheme実装にも当てはまると考えています。Chez Scheme、Racket、Chicken Schemeなど、Schemeコミュニティがこの20年間でどのように進化してきたかを知るために、それらをぜひチェックしてみてください。

この文章でお伝えしたいのは、「SchemeをPythonの代わりに選ぶ理由」ではありません。それはこの議論の方向性ではないのです。もし、あなたがすでに関数型プログラミングのトレンドに気付き、その中でもよく知られた関数型プログラミング言語を試してみたいと思っているのなら、この文章は、製品開発におけるSchemeの力を知る手助けになるかもしれません。

## 使う価値はあるのか？Schemeを選ぶ理由

よくある質問ですが、なぜSchemeを使うのかという問いに対する答えは無数にあります。ただ、すべてを網羅的に挙げるのは時間がかかるので、簡潔にポイントをお伝えします。もしSchemeの世界に詳しくない方でも、以下を知っておくと良いでしょう。

- **優れた表現力**  
  Schemeはシンプルでわかりやすいコードを書けるため、複雑性を抑えた開発が可能です。

- **迅速な開発**  
  ビジネスロジックにおいて低レベルな詳細は主要な課題ではありませんが、Schemeは迅速な開発をサポートします。

- **バグを減らす**  
  複雑性が少ないことでバグが減る可能性があります。ただし、致命的なバグがゼロというわけではなく、それはプログラマーのスキル次第です。

- **コードの理解が簡単**  
  Schemeは理解しやすい言語です。これは、プログラムの分析やデバッグを行う際に非常に重要です。

- **標準化された言語**  
  Schemeは標準化された言語であり、その文法や標準APIは明確に定義されています。

- **完全なラムダ計算のサポート**  
  ラムダ式の組み合わせにより、必要なときに高い表現力を発揮します。

- **プロフェッショナルな開発視点**  
  ソフトウェア開発のプロとして見た場合、Schemeは投資する価値のある言語です。その理由については、この文章で証明していきます。

Schemeを選ぶことで得られる利点は明確です。この先の記事で、それらを具体的に掘り下げていきます。

## 幻想その1: Schemeプログラマーを見つけるのは難しい

確かに、プロのSchemeプログラマーを直接採用するのは簡単ではありません。プロダクトでSchemeを使用した経験がある人は多くありません。

しかし、5年前に初めてSchemeチームを構築しようとした際、私もこの問題について懸念していました。でも、2ヶ月後には「これは問題にならない」と気づきました。Schemeプログラマーを低コストで育成できるからです。ここで私の採用に関する短い話を共有します。

当時、システムプログラミングにはC++14を使用し、ビジネスロジックのスクリプトにはSchemeを使っていました。Schemeプログラマーの採用が難しいと考えた私は、C++の関数型プログラミング（FP）に着目することにしました。最近のC++には多くの関数型機能が含まれており、C++プログラマーであればFPについて多少なりとも知識があるはずです。流行ですからね。

もし候補者が十分に優秀で内定を出せると判断した場合、新人研修で彼らに **SICP（Structure and Interpretation of Computer Programs）** を教えることにしました。もちろん、SICPは初心者には大きな本なので、最初の2章だけを選びました。  
- **「データ抽象」**：オブジェクト指向の理解を深めるため。  
- **「手続き抽象」**：アルゴリズム実装のスキルを磨くため。  

一方で、**「メタ言語抽象」** や **「機械抽象」** は省略しました。当時はコンパイラを作る事業をしていなかったからです（今はしていますが、それはまた別の話です）。

研修は1ヶ月間行われました。その後、新人たちはプロダクトの小さな仕事、例えばバグ修正や小さな機能追加を始めました。SICPは単なる本ではなく、深い知見に基づいて作られた正式な教育システムです。このシステムを活用することで、短期間で研修を終えた新人が、学んだことを日常業務で即座に活用できるようになりました。

SICPの教育システムは、短期間で優秀なSchemeプログラマーを育成する助けになります。どの技術系企業にも新人研修期間がありますが、私たちはそれを1ヶ月で実現しました。これはコストパフォーマンスに優れた解決策です。この方法を5年間続けていますが、今のところ順調です。

考えてみてください。この研修にはお金を一切かけず、SICPの知識を短期間でプロダクトに反映させることができました。

## 幻想その2: Schemeは速くない

もうそんなことはありません。Chez Schemeをご存知ですか？

数年前、私がまだ大学院生だったころ、プログラミング言語の速度に非常に興味を持っていました。しかし、プロの開発者になってから、プログラミングには少なくとも3種類の「速度」が存在することに気付きました。

1. **学習速度**: 知識ゼロの状態で、どれだけ簡単にその言語を学べるか？  
2. **開発速度**: コーディング作業をどれだけ減らせるか？  
3. **実行速度**: 実行がどれだけ速いか？

これを知ったとき、私はRuby on RailsがなぜWeb開発で人気なのか、急に理解できました。それは「遅い言語」と見なされていたにもかかわらず、です。

もし実行速度だけを考えるのであれば、アセンブリやマシン語のほうが良い選択肢になるでしょう。

## 幻想その3: エコシステムが言語にとって最も重要

友よ、この推測をもう信じないでください。実際の仕事では真実ではありません。

真実の話が欲しいなら、これをお伝えします: **言語こそがエコシステムにとって最も重要**です。

PythonのエコシステムはPython言語専用です。Pythonには歴史的な理由で大きなエコシステムがありますが、それは他の言語にも同様の規模のエコシステムが必要だということを意味しません。

唯一の真のエコシステムがあるとすれば、それはCエコシステムです。多くの動的言語のモジュールは、既存のCライブラリのバインディングにすぎません。

そのため、言語が良いFFI（Foreign Function Interface、外部関数インターフェース）をサポートしていれば、すべてのCライブラリを活用できます。今日、人々は分散処理についてより関心を持つかもしれません。分散システムは異種混在型である可能性があり、1つのエコシステムですべてを構築する必要はありません。

一方で、大きなエコシステムには十分な数のパッケージが含まれているかもしれませんが、それがすべて高品質で適切にメンテナンスされているとは限りません。それを盲信するべきではありません。

この幻想を打ち破りましょう。エコシステムはある状況下では重要かもしれませんが、言語にとって最も重要ではありません。言語を作成する際には、そのパラダイム、文法、表現力、最適化ペナルティのみを考慮します。これらがプログラミング言語にとって最も重要なことです。

過去には、プログラミング言語は企業によって作成・推進されていました。報酬なしでそのエコシステムに貢献する理由はありませんでした。そのため、商業化された言語コミュニティにおいてはエコシステムが重要でした。そうでなければ、成長は遅くなり、投資が無駄になるでしょう。しかし、今日ではプログラミング言語は主にFOSS（Free and Open Source Software、自由でオープンソースなソフトウェア）コミュニティによって推進されています。エコシステムはFOSSの力のもとで自然に成長します。

経験豊富な開発者は、言語の表現力を気にするでしょう。なぜなら、それがコーディング効率を左右するからです。

## 短所その1: Schemeはまだディープラーニングには完全対応していない

近年、ディープラーニングが注目を集めています。ここで、GNU Guileで書かれ、LLVM JITを使用し、TensorFlowを基盤とした**AISCMプロジェクト**をご紹介します。このプロジェクトは動作しますし、とてもクールです。私もいくつかパッチを提供しました。しかし、残念ながら、このプロジェクトに多くの時間を割くことはできません。

ですので、もしSchemeを本格的にディープラーニングに活用したいと考えるなら、ぜひAISCMに貢献することをおすすめします。

ただし注意してください。AISCMには既に中規模のコードベースが存在しています。また、OpenCVやFFmpegのサポートも含まれています。これらは著者のJan Wedekind氏による功績です。

他のScheme実装におけるディープラーニング関連の進捗については、私が把握している情報が少ないだけかもしれませんが、現状ではあまり詳しくありません。単に私の視野が狭いだけの問題かもしれません。

## 短所その2: Schemeのコミュニティは分裂している

歴史的な理由から、Schemeには多くの実装が存在しますが、その結果コミュニティは分裂しています。しかし、現在は少し希望が見えてきています。

まず、Schemeの標準化は過去10年間で良い進展を見せています。R7RSはSchemeを小さな言語と大きな言語に分けました。私見ですが、これは良い一歩だと思います。なぜなら、Schemeのミニマリズムを保ちながら、Schemeを産業レベルのライブラリ仕様にする方法を提供しているからです。

私自身のビジネスはR7RS-smallに依存しています。これはまるで私たちのビジネスのために作られたようなものです。後でその話をします。

もう一つの希望は、モダンなパッケージマネージャーです。

私はGNU Guix、GNU Guileで書かれた関数型パッケージマネージャーを選びました。ほとんどのGNU GuileライブラリはGNU Guixでインストールできます。パッケージマネージャーがエコシステムを作り出します。実際、私たちは「エコシステム」とは言いません。なぜなら、それは商業的な概念だからです。GNUはオペレーティングシステムのコミュニティです。

もちろん、RacketやChicken Schemeにも優れたパッケージマネージャーがあります。これらはそれぞれ、良いコミュニティ形成に寄与しています。

ともあれ、一貫した標準仕様と素晴らしいパッケージマネージャーがあれば、分裂したコミュニティを修正できるかもしれません。しかし、それには時間がかかるでしょう。

## 短所その3: Schemeは純粋ではない

関数型プログラミングの愛好者は、純粋な関数型プログラミング言語を使いたいかもしれません。これは副作用がないことを意味します。

確かに、Schemeは純粋ではなく、マルチパラダイム言語であり、関数型プログラミング言語だけではありません。しかし、Schemeは他の純粋な言語で見られるような完全な関数型機能を提供しています。Schemeには副作用がありますが、何をいつ使うかを自分で決めることができます。私は、副作用を禁止するのは良いアイデアではないと思います。人々は言語を使用する方法を選ぶ自由を持つべきです。Schemeはこの自由を提供しています。これが良いことか悪いことかはわかりませんが、とにかく、選択の自由があります。

## 長所その1: SchemeはWeb開発に適している

現在、ほとんどのGUIプログラムはSaaS（サービスとしてのソフトウェア）に置き換えられています。そのため、伝統的なGUI開発ではなく、Web開発を取り上げました。

2013年、私はGNU GuileでモダンなWebフレームワークである[GNU Artanis](https://qiita.com/NalaGinrut/items/092aa745567a8404fc30)を書き始めました。その時、SchemeをWebで使うための簡単なケースを作るつもりでした。

GNU Artanisが物流ロボティクスシステムで業界レベルのSOA（サービス指向アーキテクチャ）を完成させるのを助けてくれるとは思っていませんでしたが、実際にそうなりました。今ではGNU Artanisはもはや小さなコードの塊ではありません。それは、URLリマッピング、リレーショナルマッピング、HTMLテンプレート、非同期コルーチンサーバーコア、ReactなどのモダンなJavaScriptフロントエンドフレームワークとの統合を含んでいます。たった1分でサイトやサービスを作ることができます。

RacketやChicken SchemeもWeb開発において良い選択肢です。GNU Artanisの開発を始める前、私はChicken Schemeを使ってWebプログラミングをしていました。

## 長所その2: Schemeは低コストで投資する価値がある

Schemeは何十年も学術的に研究されてきました。組み込みシステムから分散サーバーの開発まで、ポジティブな結果を示すSchemeに関する論文が多数あります。

では、そんなに優れた言語であれば、学び使うのはどれほど難しいのでしょうか？その答えは「第一の幻想」セクションで説明されています。

実際には、Schemeのトレーニングにお金を一切かけていません。そして、SICPという素晴らしい教育システムがあり、その知識を短期間で製品に転換することができます。

「ゼロコスト」の話は本当です。もちろん、私の給料は含んでいませんが、私はあまり時間をかけてトレーニングしていないからです。もちろん、プログラミングの問題については議論しますが、ほとんどはScheme特有のことではなく、一般的なプログラミングに関する話です。もしあなたがSchemeを学んだことがあれば、彼らは自分たちで流暢にSchemeのコードを書くことができるでしょう。

そのコストは非常に低いため、試してみるのには害はありません。

## 長所その3: Schemeはコーディング時間を節約する

C/C++の熟練したプログラマーとして言わせてもらいますが、システムプログラミング以外の部分でC/C++を使ってコーディングする時間を無駄にすべきではありません。ビジネスロジックは要件に応じて変更されることが多く、すべてをC/C++で書くのは柔軟性に欠けます。リファクタリングやデバッグに時間を費やすのは避けるべきです。

Schemeは強力な表現力を持っており、コーディングの作業量を減らすのに役立ちます。

しかし、どう使うかによって異なります。

もし、多くのライブラリがあなたの作業を節約してくれると期待するのであれば、Schemeは選択肢ではありません。通常、これは概念実証（PoC）のためにPythonを選ぶことが多いです。

C/C++コードベースに依存するスクリプトにSchemeを使うのは、非常に良い方法です。Schemeはミニマリストであり、システムにスクリプトコードとして埋め込むのが簡単です。

## 長所その4: 本物のコンピュータサイエンスの知識でチームを作る

コードレビューで再び悪いコーディングに対して不満を言ったことはありませんか？その際、チームメンバーに本物のコンピュータサイエンスの知識を提供する機会を与えなかったことに気づいたことはありますか？Schemeはその機会を提供してくれます。そして、それは学びやすく、最終的には製品で使用するのに十分なものです。

結局のところ、武器を賢明に選びましょう。そして、いろいろなことを学ぶことは決して悪いことではありません。