Rust 入門してみた

プログラミング言語 Rust に興味が出ている。 公式の入門書の日本語訳が無料で読めるので基本的なことを理解するだけならそれほどハードルは高くない。

私はとりあえず練習として簡単なプログラムをひとつ完成させただけでまだまだ Rust を使い込んでいるわけではないのだが、 Rust はとても良いプログラミング言語だというのが現時点での感想だ。

私は以前に Haskell の入門書をいくつか読んでその型システムとても有用なものだと思ったものの、色々と不満があって普段使いするほどにはならなかった。

  • Haskell は静的な型検査をしっかりやっているのにメモリの管理は GC なの? (完全とは言えなくてもメモリ解放のタイミングをある程度はコンパイル時にわからないものか?)
  • Haskell は ML 系を踏襲した文法なので、 慣れの問題ではあるが C や C++ に慣れた身からするとどうにも使いづらさがある。
  • Haskell だけでは低レイヤを扱い難い。 結局は C (など) の助けが要る。

Rust ではこれらの不満が解消されつつ型システムはかなり似ているので私の好みに合うプログラミング言語だと思う。

Document ID: 7890bf8618279b5eea88ea6d1a00aedb

分散リポジトリ

URL は永続的であるべきだ。 情報は永続的であるべきだ。 それはウェブの理想的な運用であるが、現実はそうではない。 情報の保持にはそれなりに費用もかかるのであるから、途中で放棄せざるを得ないこともあるだろう。

無料でウェブサイトを開設できるサービスのジオシティーズが終了したときには大きく話題になったりもした。 大規模にやっているサービスが消えると時代がひとつ消えたかのように空白になってしまう。 今なら、たとえばツイッタやピクシブが消えれば失なわれる情報は多い。

インターネットは情報にアクセスするために複数の経路を持つことを趣旨として設計された。 しかし情報の保持はかならずしも分散されていない。 技術的には CDN (Content Delivery Network) といったものも活用されているが「サービス」に所有されていることにはかわりなく、いずれ消える不安はいつでもある。

だからサービスとして堅牢であることを指向するよりは、ユーザが簡単に情報を複製できる仕組みが積極的に活用されて欲しいと思うのだ。 ブログは RSS で全文配信されて欲しいし、 Git リポジトリとして公開されていればなおよい。 小説作品なら ePub 形式が好ましい。

Document ID: b74bacc704af355c368b28eb86a818ff

ニブシ

私の地元 (香川県観音寺市) では不動産屋のことをニブシというのだと父から聞いた。

とりあえずウェブ検索で調べてみたところ、方言を紹介したページでニブシという語は取り上げられているものの由来は書かれていない。

父の不確かな記憶によると売買したときの手数料の取り分が二分(にぶ)だからだったような気がするのだという。 つまりニブシを漢字で書くと二分師 (または二分士) ということなのだろう。

地域の情報というのは思ったよりもインターネット上には流れていない。 ささいなことだがここに書きとめておくことにした。

追記

土地の取引(とりひき)について明るい人に尋ねたところ、売買額の 2% ずつを売主と買主から手数料として徴収する (合計 4%) という習慣があったということに由来するそうだ。

Document ID: d20cf3396032b5fbc9bf815b91de2b0b

Fire HD 8

小説家になろう」という小説投稿サイトの小説を読むのに使っていた Sony Reader RPS-350 が数カ月前に壊れてしまった。 Sony Reader は既に生産しておらず、現在出回っている電子インクを使った読書用端末の主要なものはやや高価路線なこともあって雑に普段使いするために買うのは躊躇われるのでどうしたものかと思っていた。

そして結局は電子インクを諦めてタブレットコンピューター Fire HD 8 を購入した。 ストレージが 16GB のモデルである。 値下げキャンペーンの期間だったので 5680 円という安値で買えた。

実際に使ってみると Fire HD 8 は値段の割にはずいぶんと出来の良い端末に思える。 一昔前のパソコンよりは快適なくらいだ。 おそらくアマゾンから電子書籍や映画を買うことを見越して端末は安目に設定しているのだろう。 私はアマゾンからコンテンツを買うつもりはないので申し訳ないが。

こんな夢をみた「三人の死体」

こんな夢を見た。

夢の中の私は学校 ((じゅく)かもしれない) の教室にいた。 私も含めてその場にいる人は学校の制服らしきものを着ていた。 白い半袖のワイシャツと黒いズボンだ。 そして、どういう理由だかわからないが私は席を移動することになり、机と椅子を教室の最後列に運んだ。 新たに隣の席になった人と「上手く便乗して移動できたな」という意味の会話をした。

すると、教室の外から入って来た人が私にかなり分厚い書類の束を渡しながら、外へ出るようにと教室の皆を(うなが)した。 私は受け取った書類を机に仕舞(しま)った後に外へ出た。 建物の出入口は民家の玄関のような幅しかなく、扉も民家の扉といった雰囲気だった。 ぞろぞろと出ていく人達に続いて私が扉に手をかけると、扉が妙に重い気がしたので、何かが引っ掛かっているのではないかと視線を動かした。

結果としては (少なくとも外観からわかる範囲では) 扉に異常はなかったが、扉を開けてすぐの目の前にある左側の軒下(のきした)に死体が引っ掛かっていた。 その死体は作務衣(さむえ)のような服を着ていて、私はそれを「陶芸家風だな」と思った。 思わず「うわぁ」と声を出すと、すぐ前を歩いていた男性が振り向いたので死体を指差して示すと、彼もまた驚いていた。

割と目につくところにある死体なのに私の前を歩いていたたくさんの人達はこれに気付かなかったのだろうかと視線を進行方向に戻すと、十メートルほど向うにある大木からふたつの死体が落ちてきた。 この死体は背広を着ていて、夢の中の私は何の理由もなくそれを刑事の死体だと思った。

以上。

この夢には私の知っている人も場所も登場しない。 推理物を読んだ記憶などから構成されたのかもしれないが、物語を読んだときにはないひどく不快な印象が残った。

Document ID: de2fb1118fccbba93f576a88850b319b

64bit 版の Windows 10

私は 32bit 版の Windows 10 を使っていた。 私が Windows 7 を使い始めた当時、まだ 64bit 対応のアプリケーションが少なかったことや、実際に乗せているメモリが 4GB 以下であったこともあって 32bit 版の方が安定している印象があったのだ。 Windows 10 にアップグレードしたときも、特別な理由があったわけではないのだが 32bit 版の Windows 7 からアップグレードしたら 32bit 版の Windows 10 にアップグレードされたからそのまま使っていた。 (のち)に 8GB までメモリを追加したが RAM ドライブとして活用するだけで、あいかわらず 32bit 版の Windows 10 を使っていた。

数年ほど前からはさすがにもう普通のパソコンで使う分には 64bit 版にすべきだろうと感じていたのだが、 64bit に移行するとなるとまずはハードディスクの内容を退避させる必要や、あらたに 64bit 版のアプリケーションに入れなおすなどの作業が生じる。 要するに面倒くさいのだ。 それでなかなか踏ん切りがつかずにいた。

さて、私が使っているインターネット回線は使用継続年数に応じてポイントが与えられる制度があり、ポイントに応じて様々な景品と交換できる。 その制度を利用して外付けハードディスクドライブを手に入れた。 バックアップ用のドライブを入手したことを契機として重い腰を上げて 64bit 版の Windows 10 に移行した。

やってみると思ったほど手間ではなかった。 まだ以前の通りの作業環境の準備が出来たわけではないが、メモリを潤沢に使える快適さを多少ながら実感できている。

Document ID: f21c3bfc3bc1871fcd12d29c84065a20

パイプとコンソール

私はプログラミング言語 SchemeWindows 10 の上でよく用い、日常的には GaucheSagittarius といった処理系を使うことが多い。 使っているエディタは Emacs なので、処理系を呼出すのも Emacs からだ。 ふと他の FomentOtus Lisp などといった処理系も Emacs から使ってみようと思い立ってやってみると暴走状態に陥った。

しかし、 Emacs ではなく VSCode からだと問題なく動作するのである。 この違いが生じる原因は Emacs は処理系とパイプで接続しているが、 VSCode はコンソール API を再現している (らしい) ことによるものと思われる。 実際、標準入出力の接続先を GetFileType API で確認してみると違いがあることがわかる。

Windows のコンソールの制御はコンソール制御系の API を使うことで可能になっている。 コンソールにはスクリーンバッファと呼ばれるオブジェクトが結び付けられていて、スクリーンバッファに対する操作をすれば表示に反映されるのだ。 ただ、日常的にはテキスト表示をするときは標準出力に対する操作としてプログラムを書くことが多いだろう。 これは Windows の C ランタイム (いわゆる MSVCRT) が仲立ちして上手いことやっている。

Foment や Otus Lisp の場合は、コンソールに繋がっていないにもかかわらず対話的な使い方をしようとすることに充分な配慮がない、あるいは配慮はしていても WindowsUnix と違う部分で上手くいってないのだろう。 具体的にどこで問題があるのかは突き止められなかった。

430b29f08f2eef8ec6086be263925a11