blog.8-p.info

水島さんが Scalaの学習コストについての私見 で、

実際、Scala難しいならKotlinも難しいとなりそうなくらい両者は似ている……というより、KotlinはScalaの主要な機能をほぼ継承しているのですが、その辺りはJetBrainsのマーケティングが上手なのと、ライブラリの互換性を軽視しなかったこと、厳格な立場をとる人があまりいないこと、JetBrainsの政治がうまい辺りが主要因だろうなと感じています（これは悪口ではなくて、逆にLightbendの言語マーケティングが上手くなかったというのが正直な実感です）。

と書いていたけれど、マーケティング、互換性、コミュニティ、政治、といってしまうのは、言語も含めたソフトウェアそのものの違いを無視しすぎていると思うので、そういう話をします。

Kotlin と Mapped Types

以前に書いた、Kotlin のコレクションと Mapped Types (2017) でもふれたはなしだけど、Kotlin はコレクションまわりのクラスをコンパイラの中で特別扱いしている。

Mapped types

Kotlin treats some Java types specifically. Such types are not loaded from Java “as is”, but are mapped to corresponding Kotlin types. The mapping only matters at compile time, the runtime representation remains unchanged.

これは、implicit conversion からはじまって、

scala.collection.JavaConversions

The transparent conversions provided here are considered fragile because they can result in unexpected behavior and performance.

Therefore, this API has been deprecated and JavaConverters should be used instead. JavaConverters provides the same conversions, but through extension methods.

それが上手くいかず、結局は明示的に変換しなくてはならなくなった Scala と、だいぶ様子が違っている。

Scala は、言語のほうに最小限の足場となるような機能を用意しておいて、その上に色々を作るのはライブラリでやります、という言語だと思う。言語側に implicit conversion を入れて、Java のコレクションとの相互変換は標準ライブラリとして提供するというのもそうだし、任意のメソッドをドットや括弧なしで呼び出せるというルールを作って、その上に演算子オーバーロードを作るのもそう。

これは Scala だけではなく、例えば C++ もそういう指向があったように思う。STL のコンテナはただのライブラリなんですよ、というのは C の配列を知っている身には新鮮で、良いことのように思えたのを覚えている。

IDE

全く別の話として、Kotlin は IDE ベンダの言語で、IntelliJ IDEA でちゃんと動くことが最初から指向されていたところも大きい。ただ、これは Borland の Delphi から Microsoft の C# までずっと続いていることで、あまり珍しいことでもない。

でも、当時 Scala が好きで、でも Emacs を使っていた私は、IDE の価値にあまり気づいていなかった。個人的な話を続けると、私はそのあと結構 Java を書いて、この「IDE に背中をあずける」感覚というのを実感する。IDE が警告を出したら、それは実際に何か問題がある、というのを前提としている人々にとって、IDE そのものの出来を疑わなくてはいけないのは厳しい。

価値観のちがい

そういえば、2018年の Scala By The Bay では、Scala を書いたことがないという Bryan Cantrill が出ていて、ソフトウェア/プラットフォームには “values” がある、という話をしていた。日本語にすると価値観だろうか。

例えば、C は Interoperability, Performance, Portability, Simplicity で、Scala なら Composability, Expressiveness, Interoperability, Integrity, Robustness かな、とこんな感じ。

氏がスライドで上げている色々から選ぶなら、Kotlin は Approachability や Compatibility を、Scala よりは重視していて、それはコミュニティの差というより、言語の設計から、いつ何に投資するかという優先順位づけまでに影響していると思う。

語らず作る

ここ数年、語ることはまあまあ出来ている (ブログを書いている) けど、作ることができてないので、だんだん作ることの比重を増やしていきたい。

語らないことは目標というよりは副作用に近い。寡黙さへの漠然とした憧れはあるけれど、これは考えるとあまり理がない。面白いものを作って、それについて話せるのが一番良い。ただ、時間の配分としては作るほうをがんばりたい。

読まずに書く

Twitter とかを見ていると「その話なら、おれにも言いたいことがあるぞ」ということが結構ある。でもこれは Duty Calls の一種で、あまり良くない。広いインターネットで、私がツッコめる程度にスキがあるひとは沢山いる。でも、それにツッコむことが自分の本来やりたいことであることは、あまりない。余暇の時間になんの問題を解くかを、他人に決めさせるべきではない。

これはすでにまあまあ出来てるので、継続していきたい。

もう一つは「この本を読んで勉強するぞ」と手をつけるも完走できないことが、ここ数年よくあって、ちょっと最近お勉強偏重になっていたんじゃないか、もっと泥縄で調べて何かを作るとか、勉強要素をコントロールする必要があったんじゃないか、というのがある。

親業との兼ね合い

一方で、親業もがんばりたい。「趣味をがんばるのは、親として完璧になってから」というのは持続性がなく、不健全だと思うけれど、こと交換可能性について考えると、親業が一番低く、会社員業は高く、インターネット創作活動は一番高い。親というか、家族としての役割を果たすのが一番難しい、というのは、今年の3月にも書いた。

子育てと自転車。趣味との両立 は良かった。自転車やプラモデルに比べると、ソフトウェア開発は子供ウケしない気もするし、スマートフォンも含めたコンピュータに触れる子供の割合を考えると、そんなこともないのでは、とも思う。娘の誕生日プレゼントを作る みたいに、うまいことマージする道があると良いのだけど。

品数を減らして、イテレーションを増やす

ブログは、イテレーションをそこそこに品数を増やすアプローチだと思う。Twitter は、書ける文字数制限があるので推敲に推敲を重ねます、という道も理論上はあるけれど、実際にはさらにイテレーションを減らして、量が増えている人が多いと思う。

私は、Twitter から引いてブログにいたのだけど、さらにもっとイテレーションを重ねて、結果として品数が減ってもいいかと思っている。

ブログをずっと書いて、インターネットの議論を眺めていると、自分の書くことも、周りも、話題がループしている感じがちょっとある。それはブログ的なアプローチの限界でもあるように思う。

11月からやっていた、daemon/logger: read the length header correctly が無事マージされた。

Docker Engine (プロセスでいうと dockerd) の RSS がどんどん高くなっていって、最終的には Go ランタイムの panic で死んでしまうというバグで、OOM when following “local” logs of high-log-output container として3月には報告され、私は11月から手をつけはじめた。

Go < 1.16 では RSS を信用してはいけない

RSS (Resident Set Size) がどんどん高くなるということは、メモリリーク? と思うけどあんまり怪しいところはない。調べていくと、runtime: default to MADV_DONTNEED on Linux を見つけた。

In Go 1.12, we changed the runtime to use MADV_FREE when available on Linux (falling back to MADV_DONTNEED) in CL 135395 to address issue #23687. While MADV_FREE is somewhat faster than MADV_DONTNEED, it doesn’t affect many of the statistics that MADV_DONTNEED does until the memory is actually reclaimed under OS memory pressure. This generally leads to poor user experience, like confusing stats in top and other monitoring tools; and bad integration with management systems that respond to memory usage.

Go では 1.12 から 1.15 まで MADV_FREE を使っていたのだけど、これは Linux がユーザー空間に露出している各種統計情報には反映されず、色々と混乱を招いていたので、1.16 から MADV_DONTNEED に戻る、らしい。

なので、RSS だけ見てメモリリークっぽい挙動でも、実際にはメモリリークではない、ということがあるらしい。

Docker Engine が中で使っているログフォーマット

Docker Engine が中で使っているログフォーマットは

[メッセージ長][Protocol Buffers でエンコードされたログメッセージ][メッセージ長]

という形になっている。で、どうやらここのメッセージ長が変になってしまって、巨大なメモリを確保しているらしい。ということで、メッセージ長が 10,000 を越えたら、その時点のログを適当なところに保存して、そのメッセージ長を16進数で表示する、という雑な変更を入れて、

% docker logs -f $(docker run --rm -d --log-driver local alpine cat /dev/urandom) > /dev/null

なんてやってみると、panic: too large 95e09737 といって dockerd が死ぬ。保存したログファイルを読んでみると、確かに 0x95 0xe0 0x97 0x37 というバイトの並びは、ログの中の、メッセージ長ではない部分に存在する。

何が悪かったの?

Decode() が諸事情でメッセージ全体を読みきれなかったときに、今まで読んだバイト列をどこかに保存しておいて、次に Decode() が呼ばれた時はそれをつなげる、という処理が抜けていて、メッセージの途中をヘッダと解釈していたのが原因だった。

原因がわかってしまうとどうってことないけれど、Protocol Buffers まじりをバイナリエディタで開いて眺める、なんてあんまりやらないので新鮮なバグでした。

今年も新型コロナウィルスの年で、とはいえ、それに伴う生活の変化、例えば家から働いたりすることは、だいたい去年にはじまっていたので、あまり代わり映えのしない年だった。

音楽

• Sen Morimoto - Live on KEXP at Home

家の一室で仕事するのに慣れたのか、音楽を聞くのはちょっと減ってしまったように思う。

Live on KEXP at Home の Sen Morimoto は、後世の人々に説明が必要になるような、パンデミック下の生活を切り取っている感じがよかった。途中で、Mitski の “Washing Machine Heart” をカバーしていたと思ったら、年末に Mitski の新しいアルバムが出ることになった (実際に出るのは来年) のも良かった。

本

• 玉村豊男『料理の四面体』

なにがきっかけで読んだのか覚えていないけど、玉村豊男『料理の四面体』は面白かった。色々と軽い本は読んだけれど、重い本は読めず。

年の後半では、ニュースの消費を見直そうと、週刊誌の The Economist を月に一冊買うようにしていた。年末には “The World Ahead” という特別号が毎年出るようで、今は The World Ahead 2022 を読んでいる。

インターネット

• A Brief History & Ethos of the Digital Garden

hysysk さん経由で知ったデジタルガーデニング、Zettelkasten や Roam Research のようなナレッジマネジメント勢と、The Whimsical Club や Neocities のようなホームページ勢が同居している、ちょっと曖昧な言葉だけど「公開したら終わりで長期で手を入れたりはしない文章を、時間軸に並べることが、本当に良いやりかたなのか?」というブログ時代になって忘れていた問題を、もう一度問い直していて良かった。

去年のベストでふれた「インターネット縄文時代」はあまり流行らなかったけど、インターネットの流行が一周している感じは、洋の東西を問わずにあるように思う。

ポッドキャスト

• CoRecursive

プログラマへのインタビュー中心のポッドキャスト。2018年から続いているけど、私は今年から聴きはじめた。有名ソフトウェアの作者だと SQLite や Zig の作者なんかが出ていて、なかなか人選が渋い。他のインタビュー系ポッドキャストに比べると、比較的積極的に編集されていて聴きやすい。

YouTube

• “The Spirited Man” by Van Neistat

Casey Neistat の兄、HBO の The Neistat Brothers では共演していた Van Neistat の YouTube チャンネル。とりわけ最近のサムネイルはだいぶ YouTube っぽくなってしまっているけど、内容は、日記というかエッセイというか、独特で良い。

テレビ

• Mr. Robot

同僚がおすすめしていたので見はじめたら、ハマってしまって、深夜に連続で3話みるとかそういう体に悪いスケジュールで見た。ストリーミングでアメリカ連続テレビドラマを一気に見るの、漫画喫茶で単行本を一気に読むような、充実感と背徳感がある。

おわりに

この記事は 2021 Advent Calendar 2021 の19日目です。18日は june29 さんの思い出し 2021でした。明日は yamanoku さんです。過去の自分のベストはあと2年分あります。

• ベスト オブ 2019
• ベスト オブ 2020

それではみなさま良いお年を。

Twitter で議論をするのと、Excel を方眼紙にするのは似ている。道具には向き不向きがあり、なんでもを目の前にある見知ったソフトウェアですませるべきではない。

Twitter は議論に向いたソフトウェア/メディアとは言い難い。議論に巻き込みたいひとが使っている率が高いところは良いけれど、それ以外は、短文を投稿するメディアであるという人々の認識も、リツイートやお気に入りのような機能で外部から茶々を入れられるのも、こみいった話をするのに向いた場所とは言い難いと思う。

Excel を方眼紙にしない程度には分別のある人々が、Twitter で議論めいたものをしているのをみると残念に思う。議論というか、だれかのつぶやきにだれかが反論して、程度のことなんだけど、それを Twitter でやりだしたら、こじれないものがこじれませんか、と思ってしまう。

一方で、Excel 方眼紙をしている人には「フリーカーソルではないですが Word なかなかいいですよ」と言える一方で、Twitter の代わりというのはあまり見当たらない。私はブログが好きで、ある程度の込み入った話は長く書いたほうがいいですよ、と思っているけれど、トラックバックのないブログはあまりに離れすぎている、という気持ちはわかる。

じゃあ Twitter は何にむいているのか

「発見」かなあ。ひとが多いこと、リツイートや、最近のお気に入りをタイムラインに表示する機能も、自分の近所で新しいものを発見するには良い。

議論にむいたソフトウェア/メディアとはなんなのか

私は、Design Doc 的な提案文章を書いて、それについて話し合うのに慣れてしまっている。最初に認識をあわせられるし、私の発言に誰かが反論する、というより「問題 vs. 私達」という感じが出しやすいのが気に入っている。

ただ、人類はWeb会議に向いていないので、もっとMiroを活用すべきとかを読むと、リアルタイムであることを受け入れると、もうちょっと軽い方法もあるのかなあと思う。