あなたがSchemeを使うべきではないn個の理由

ちょっと前にこんなことを呟いた。

I often see this type of dis about Scheme or LISP in general but which standardised programming language has, say, socket in its standard? AFAIK, only Java. (Maybe Ruby as well?) I think it should be compared with their ecosystems instead of standards. (Then Scheme sucks I agree) https://t.co/XxvP6xrk04

— Kei (@tk_riple) 20 April 2018

Schemeは好きだがいろいろな理由を考えるとなかなかに現場では使えないというのは賛成である。そこで、あまり気乗りはしないが、使うべきではない理由をあげてみようと思う。これらは現状での改善点でもあるとは思うので、これを読んでなんとかしないとと思えたらぜひとも改善してみてほしい。また、ここに列挙するのは個人的に現場導入に躊躇する理由なので、他にもあるぞ！という方がいればコメントあたりに書いてくれると追記するかもしれない。

【標準だけでは機能が貧弱】

 よく言われることではある。っが、反論としては他の標準がある言語はどうよというのはある（例：CはPOSIX抜くとソケットすらない）。もう一つ反論としては、現在R7RS-largeのプロセスが（遅々として進まなないが）動いているので、ある程度決まってくると結構な機能が揃うと思う。

【開発環境が貧弱】

JavaならIntelliJ、Eclipse、NetBeansなどいろいろあるが、Schemeだと多分Emacs一択だと思う。 更に機能も貧弱。拡張としてGeiserがあるが、（使ったことないのでドキュメント眺めただけの情報だが）これもREPL＋αぐらいしかなさそう（例えば、リファクタリング機能みたいなのはなさそうだ）。

【ビルドシステムが貧弱】

JavaならMaven＋Nexus、JavaScriptならNPMがあるが、Schemeにはない。パッケージ管理で言えばSNOWがあるが、いまいち。処理系固有ならegg(Chicken Scheme)、PLaneT(Racket)があるが、処理系が固定される。（Racketは正式にはScheme方言になる）

【処理系が多い】

メジャーな処理系だけでも両手で足りないくらいある。選択肢が多いのはいいことだが、CのようにとりあえずGCCでよくね？的に決めるのは難しい。処理系選びに知識が必要になるので、初心者泣かせではあるだろう。（昔処理系の選び方を書いたが、今でもたまにアクセスがあるんだよね。2018年版でも書こうかな）

【コミュニティが小さい】

コミュニティの大きさ＝知識ベースだと言える。つまり、困った時に自力で何とかするしかない場面が圧倒的に多くなる。例えばStack Overflowにある質問を見ても数も少なければCSの学生レベルの質問がメインだったりする。また、RacketでWebアプリ作ってるんだけど、みたいな質問にはなかなか回答がつかなかったりする。

【ライブラリが少ない】

ポータブルなライブラリがものすごく少ない。例えばデータベースにアクセスするポータブルなライブラリは知るところでは拙作のr7rs-postgresqlしか寡聞にして聞かない。この辺は標準＋SRFIの貧弱差も出てしまうので難しいところではある。ちなみに、R6RS処理系ならば、拙作のr6rs-pffiがあるのでバインディングさえ作ってしまえば、夢は広がるはず(だれかChez対応のPR送ってくれないかなぁ、ﾁﾗﾁﾗ)。

とりあえず思いついたのを列挙してみた。ライブラリや開発環境の充実は個人でも頑張ればできそうな部分ではあると思う。Rubyが今ほどにポピュラーになったのはRailsが出てきたからという意見もあることを思うと、Schemeでポータブルに動くキラーアプリが出れば現状を打開できるかもしれない。