Erlangについて思うところ

職場の今までいた部署が潰れてしまったので、新しい部署で仕事のためにErlangを学んでいる。基礎的な文法については学び終わったので、現時点でのErlangについての雑感を書いておこうと思う。

Erlangは多数派のプログラミング言語とはだいぶ違う文法を持っている。終端記号がドットであることもそうだが、比較演算子もだいぶ違っている。多くの言語が!=を使うなか、Erlangは/=を使っている。Less than or equal toが=<であるのも多数派とは異なっている。ただし、Greater than or equal toは>=だ。一貫性がない。

終端文字はドットだが、関数の中には一つの式しか書くことができない。式はカンマで区切ることができるので、以下のようになる。

func() ->
    expr1 , % カンマ
    expr2 , % カンマ
    expr3 . % ドット

このような文法はリファクタリングの時に問題になる。というのも、例えば関数の戻り値をexpr3の評価結果に依存した別のものにしたくなったとき、

func() ->
    expr1 , % カンマ
    expr2 , % カンマ
    expr3 . % エラー
    expr4 .

うっかりドットをカンマに修正するのを忘れるとエラーになる。

そもそも関数の文法も問題だ。関数は同名の関数群をセミコロンで区切って一度に定義する文法になっている。

Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr . 

関数群の最後はドットで終端するが、途中の関数はすべてセミコロンで区切る。これは関数を定義する順番を変えたときに、手でセミコロンとドットを修正しなければならない。

Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr . % エラー、リファクタリング中の修正漏れ
Name( P1 ) when ... ->
    expr ; 

変数が再束縛できないのもコードを汚くする。というのは、結局現実のコードでは式を評価した結果を元に更に計算を行い、その結果を束縛し、途中の結果については参照しないコードがある。

R1 = expr1 ,
R2 = Do_something(R1) ,
R3 = Do_something2(R2) .

もちろん、途中の評価結果を変数に束縛する必要はないのだが、あまりにも式が長い場合は可読性のために途中でわかりやすい名前をつけたくなる。しかし、変数の再束縛が許されていないために、変数名に意味のある単語を使わない文化圏の怠惰な数学者がよく使うX'や、gitを使えないバカがよく使う2020-01-18プロジェクト企画書(最新)(第二項)(承認待ち).zipのようなひどい変数名を作り散らかす原因になる。

他にもガードにBIFしか使えないとか型がないとか型がないとか特に型がないとかいろいろといいたいことはあるし、ErlangはHaskellの爪の垢を煎じて飲んでほしいのだが、汎用プログラミング言語としてみたErlangは貧弱で、主要なプログラミング言語とは違う文法を採用し、しかも融通がきかない不自然な文法で、まことにつまらない言語だ。まるでGOやJavaのような言語と言える。

ただ、言語としてはそれほど難しい概念もないので、習得は容易だろう。

ただし、あらゆる点で言語としておそまつな点が目につく。最初はクソ言語と思っていたが、途中からこれはBrainfuckと同じエソテリック言語の仲間だと思えてきた。

そして基礎的な文法を一通り学び終えた今では、ついにあるひとつの結論に達した。Erlangは分散コンピューティング用のDSLなのだ。SQLとかシェルスクリプトと同じであって、汎用プログラミング言語として考えるからクソ言語だと思うのであって、特定の分野専門のDSLだと考えれば悪い言語ではない。汎用プログラミング言語として考えたとき、SQLやシェルスクリプトはいかにもクソ言語というしかない。しかし、SQLやシェルスクリプトの価値はそこにあるのではない。Erlangも同様に、たまたま汎用プログラミング言語としての機能を備えてしまっただけで、本来は単なるDSLであり、ツールでしかない。1980年台にネットワーク越しのリモートコンピューター群をあたかも一つのコンピューターを扱っているかのように扱えるようなツールを実現したという点で価値がある。

さて、Erlangの基礎的な文法は一通り理解したのだが、まだこれでErlangの習得が終わったわけではない。これからErlangのプロセスやメッセージパッシングなどを学ばなければならない。まだもう少し時間がかかりそうだ。

膝の痛みがなかなか治らない

スノーボードによる膝の痛みがなかなか治らない。

30を超えてから新しい運動を始めると悩まされるのが靭帯と腱の損傷だ。筋肉痛というのは数日で回復するが、靭帯と腱の回復には数ヶ月かかる。これまでにボルダリング、ダンス、スノーボードと新しい運動に挑戦し続けているが、そのたびに靭帯と腱を損傷している。

残念ながら今の日本語圏のインターネットにはまともな情報がないので、せめて自分の怪我の状況と回復時の自覚症状ぐらいは書き残しておこうと思う。

ボルダリングでは指の腱を損傷した。原因は単純で、足を滑らせて指だけで極端な荷重変化を支えてしまったのが原因だ。指の腱を損傷すると、指の曲げ伸ばしと手首、手首の下辺りに違和感を感じる。回復の自覚症状はかなり急峻だ。病院に行ったところ、抗炎症作用のある塗り薬を処方された。塗るとわずかに痛みが減る。最初の一ヶ月ぐらいはほとんど回復が見られず絶望的になるが、ある日を境に1日単位で違和感が減っていく不思議な自覚症状の変化が現れた。

ダンスでは足首が痛くなった。つま先を上げる方向に足を動かすと、足首が痛くなる。医師の診断によるとアキレス腱を痛めたそうだ。一ヶ月ほどダンスを中断して、痛みがやや収まったものの、依然として残るので病院に行ったところ、処方はロキソニンテープとジクロフェナクNa（鎮痛抗炎症剤）とレバミピド（胃薬）とアセトアミノフェン（解熱鎮痛剤）であった。薬の鎮痛効果により痛み自体は軽減されるのだが、痛みがなくなるわけではなく、回復して痛みが減ったのか、単なる鎮痛効果で痛みがわかりにくくなっているだけなのか判断に困る。そのまま更に1ヶ月ほどは自覚症状は変わらなかったが、ある時を境に急激に1日単位で症状が軽くなっていった。

そして今悩まされているのが膝だ。原因はスノーボードだと思われる。ダンスで膝を痛めなかったのはよくわからない。いかにも膝に負担の掛かりそうな動きもしたのだがダンスでは問題がなく、スノーボードに1日行っただけで極端に膝を痛めてしまった。

当初は右膝の内側に痛みがあったのだが、今は左膝も少し痛み、かつ膝の外側にも痛みがある。膝の内側の痛みしか自覚症状がなかったときに医者にかかったところ、膝関節内側側副靱帯(MCL)を痛めたのだろうということだ。処方は足首と同じだ。

肝心の治療経過だが、一ヶ月経過した今、まだはかばかしくない。未だに痛みが残っている。当初は階段を上がるととても大きな痛みがあったが、今は階段を上がるぐらいでは痛みはでない。当初は膝に負荷をかける動きをすると痛みが出ただけで、安静にしていれば痛みはなかったのだが、今は膝に負荷をかけても痛みはそれほどないが、常に膝に違和感を感じている。この安静時の違和感は安定せず、痛みがないときもあれば、痛むときもある。自覚できる痛みがないからとうっかりと地下鉄の階段を上がってしまった翌日は痛みが出ている気がするので、膝への負荷に遅延して安静時の痛みが生じているのかもしれない。

靭帯と腱の回復には2ヶ月かかるという個人的な経験則からすると、回復にはまだ一ヶ月かかる計算になる。スノーボードのシーズンは短い。特に今年は雪が少なく例年より短くなるだろう。

この記事をここまで書いてから2日立った。たまたま膝の調子が良かったのでボルダリングに行ったところ、回復の兆しを感じた。翌日も痛みがあまり膝に残らない。

改めて考えてみると、今まで靭帯や腱を痛めたときの痛みの自覚症状は、いつも同じような状況だ。まず受傷直後はそれほど痛くない。翌日から数日も痛みはあるもののそれほど痛くはない。ただし、少しでも負荷がかかったならば危険な痛みを感じるので運動はできない。その後一ヶ月以上、運動を完全に控えても痛みが収まらない状態が続く。多少の負荷をかけても当初感じた危険な痛みはないのだが、やはり痛みはあるので運動はできない。このような状態が一ヶ月以上続いて絶望するが、ある時急に回復の兆しを感じる。そうすると少しぐらいは負荷を書けても痛みは感じなくなり、運動も様子を見ながら再開できる。そして、不思議なことに運動をすると回復が早まる。

2月にはスノーボードに復帰できるかもしれない。

2020年の日本には2020年にふさわしい日本語の掲示板がない

情報の流通において最も効率的なのはテキストだ。テキストを効率よく流通させる方法として、古典的なインターネットにはメール、チャット、掲示板があった。

このうち、メールは古典的なEメールがまだ生き残っている他、現代的なSNSがメールの機能を代替し始めてきた。日本では今の所LINEが最も普及しているようだ。

チャットもそうだ。古典的なIRCはまだ生き残っている。しかし現代的なSNSや、Slackのようなサービスが代替し始めてきている。

では掲示板は？　現代の日本には現代的な掲示板サービスが欠けている。

もちろん、掲示板機能を提供するWebサービスはたくさんある。しかし、日本語圏でWebサービスを提供しているものは、いずれもかなり限定的な目的に特化したものだ。例えばユーザー同士で質問と回答をしあうサービス（Yahoo知恵袋など）とか、ソーシャルニュースアグリゲーション（はてなブックマーク）のようなサービスはある。しかしテキストの流通機能としては貧弱であり掲示板ではない。

2ch/5chのような古典的な掲示板はある。しかし見たところ技術的負債と開発リソースの不足により、ほとんど当時のまま運用されているようだ。2020年に使いやすい作りではない。

私の考える2020年の品質の掲示板とは、RedditやHacker NewsのようなWebサービスだ。どちらもソーシャルニュースアグリゲーションだ。そういう意味でははてなブックマークはとてもいい線を行っている。しかしはてなブックマークは掲示板ではない。単に1行コメントが書けるだけで、他人のコメントを参照してテキストを積み重ねることができない。はてなブックマークはソーシャルニュースアグリゲーションというよりはオンラインブックマークとして設計されているので、結果として掲示板にはならなかった。

結果として、日本には2020年にふさわしい現代的な掲示板がない。ないということはどこかが作れば儲かるのではないかと思う。誰かがやってほしい。

Arch Linuxがパッケージ圧縮フォーマットをxzからzstdに変更

Arch Linux - News: Now using Zstandard instead of xz for package compression

Arch Linuxがパッケージの圧縮に使うフォーマットをxzからzstdに変更した。

Archでは圧縮レベル20を使うことにより、xzにくらべて0.8%サイズが増加するが、デコード速度が1300%向上するという。

CanonicalによるUbuntuは2018年にzstdに移行するテストをしていて、その結果による、圧縮レベル19を使うことにより6%のサイズ増加だったということだ。

zstdとはFacebookのYann Colletが2016年に発表した圧縮フォーマットとそのリファレンス実装のことだ。軽く調べてみたところ、メモリ使用量が多く並列実行に力を入れている設計と実装のようで、現代のコンピューター向けという感じがする。

未来のタクシーはネットカフェになる

深夜にのんびりとRedditを眺めていたところ、以下のような1年前の記事が話題になっていた。

Mean streets: Self-driving cars will "cruise" to avoid paying to park

内容はこうだ。自動運転が実用化されたならば、車は駐車せずに自動運転で周辺を運転するようになる。なぜならば、燃料費と摩耗費よりも駐車料金のほうが高くつくからだ。

たしかに一理ある。都市部の駐車料金は高い。なぜなら土地が高いからだ。自動運転により人件費がなくなれば、後は「車の燃料費と摩耗費＜駐車料金」であるならば車を運転し続けたほうが安い。

この考えを推し進めると、将来、タクシーはネットカフェになる。

ネットカフェは簡易的な個室とインターネット、マンガや映画を提供している。貧乏人はネットカフェを簡易宿として利用している。これらネットカフェの機能は、自動運転による無人タクシーで代替できる。

つまりこうだ。都市部を自動運転による無人タクシーが流している。客はこのタクシーを呼び止め中に乗る。中にはフラットに倒すことのできる椅子とコンピューターと携帯電話網によるインターネットが提供されている。またマンガや映画のストリーミングサービスも提供されている。客がネットカフェ機能を利用している間、この無人タクシーは周辺、あるいは指定した目的地まで運転する。この無人タクシーは簡易宿としても利用できる。客は椅子をフラットに倒して寝ることができる。その間もタクシーは周辺を運転する。

荒唐無稽だとも思えない。現実のネットカフェは、土地と建物を用意するのに大掛かりな費用がかかる。しかも場所は固定で、車のように柔軟ではない。

どの程度現実的なのだろうか。車の摩耗費、メンテナンス費用、通信費用、コンテンツ契約費は償却して無視するとしよう。後に残るのは燃料費だ。現在、日本のガソリン価格はレギュラーが146円/Lだ。最新のハイブリット車は20km/Lを上回る燃費を持っている。

ただ、このネットカフェとしての無人タクシーにおいて、燃費というのは「距離/燃料」ではない。本当の燃費は「時間/燃料」だ。このネットカフェとしてのタクシーは走行をしなくても常時電力が必要なので、停止していても燃料を消費する。運転は燃料消費を最小にするが、走行距離を最大にする必要はない。たとえ信号や渋滞や燃料補給によって都合よく停止している時間が長くても、燃料消費が少なければ問題はない。

もしガソリン1リットルで1時間の燃費（時間/燃料）があるのだとしたら、1時間あたり146円の費用がかかる。

あるいは、蓄電池を搭載した完全電動車とすることもできる。この場合、無人タクシーは充電拠点の周辺を運転することになる。

都心部のネットカフェの料金と比較してみよう。都心部のネットカフェの相場は、30分で300円、3時間で千円、6時間で2千円、12時間で3千円程度だ。自動運転による運転手の人件費のかからない無人タクシーとしてのネットカフェは物理ネットカフェと同じ料金で利益を出せそうだ。

では肝心の駐車場の料金はどうだろう。都心部の駐車場の料金はまちまちだが、無人タクシーは場所の利便性を考えなくてもよい。利便性の悪い場所にある駐車場は、都心部であっても夜中は500円といった安いところもある。長時間利用する客を乗せた無人タクシーは、安い駐車場が空いているのならば駐車場を使い、そうでなければ道路を燃費（時間/燃料）のよい運転で流すのがよいだろう。

高度な自動運転が実用化され、このようなネットカフェとしての無人タクシーが大量に公道を流すようになると、公道が渋滞して社会問題になるはずだ。しかし法改正は技術開発よりも時間がかかるはずで、このような未来はありうるのではないか。