神は細部に宿る

私は小学生の頃に数年ほどヤマハ音楽教室に通ってエレクトーンを学んでいたことがある。 子供向けということもあって理屈っぽいことはあまりしなかったし、やめてから何十年もたった今では指の動きなどもまるで上手くいかないので結局のところ何も身につかなかったわけだが。

その当時に使っていた楽譜は倉庫にしまったままにしていて廃棄はしていなかった。 音感もないので楽譜を見てもどんな音楽だったかも思い出せないし、ふと思いついてパソコンに楽譜を入力して再生してみたのだ。 具体的に使ったソフトは MuseScore である。 主旋律を入力してから伴奏を入力して、それから細かな指定を付けていくという順序で入力した。

主旋律があるだけでもどんな曲かわかる程度にはなるのだが、詳細を入力するたびに美しくなっていくことがわかる。 全体から見ると些細に思えるスタッカートやテヌートひとつひとつが確実に音楽の美しさに貢献していることがわかる。

作品をよりよくするにはただひたすらに細かな部分をよりよくし続けるという積み重ねなのだなと感じたのであった。

Document ID: a7a0448f949eb74fe932d8a8982eb1fc

土葬

現代の日本においては遺体(いたい)は原則として火葬される法律になっている。 しかし実際に日本のあらゆる土地で火葬が当然になったのはそう古い話ではない。 私の地元 (香川県西部の一地方) では 1950 年頃までは土葬が標準だったようだ。 (時期については聞き取った老人の記憶が元になっているのでそれほど正確ではない。 しかし今でも生きている老人の幼い頃に土葬が標準だったのはかなり確かな事実である。)

そしてその土葬に使われていた土地が私の自宅のすぐそばにある。 それほど大きな土地ではない。 民家がひとつくらいなら建てられるだろうかといった程度の面積である。 きっとこの土地には何百年かの間は延々と遺体が埋め続けられたのだろう。

今では特に何に使われることもなく細い木がたくさん茂(しげ)っている。 時期になれば少し彼岸花が咲いたりもする。 自治会の裁量でたまに伐採したりもしているようだ。

私にとってはごく当たり前にそこにある土地なので特に深く考えたこともなかったが、この土地に生える木の養分の幾(いく)らかは遺体に由来するものだったりもするのかもしれない。

Document ID: 46c13be89e7e240f0e110d4f6e6aac03

夢枕

私の母の夢の中にその母 (私にとっては祖母) が現れたことが二度あるのだと母が言っていた。 いわゆる「夢枕に立つ」というやつだ。

一度目は祖母が死んだ直後だったという。 祖母の葬式の準備にてんやわんやで疲れていた母に対してその姉 (私にとっては伯母(おば)) が休むようにいい、母は少しばかりうたたねをした。 そのときに夢の中に現れた祖母は「冷蔵庫に蓮根(れんこん)があるから子供に金平(きんぴら)を作ってやれ」と言ったそうだ。 そして祖母の家の冷蔵庫には実際に蓮根があり、母はそれを持って帰って金平を作った。 その時点では私は生まれておらず、私の兄も乳児だったので金平を食べはしなかったようだが。

二度目は母の甥(おい) (私にとっての従兄(いとこ)、祖母にとっては孫(まご)) について「大豆入りのカレーを食べさせたら良い嫁(よめ)が得られる」と述べたそうだ。 (結局のところ、彼は今でも独身なのだが。)

全く無意味で意味のないただの夢だ。 しかし死んだ肉親が現れるとなると特別な何かを感じてしまうこともあるのだろう。

Document ID: be6b1bab64ada8c801e8d92b1c947d79

フローチャートの功罪

プログラミングを指導するにあたってフローチャートを多用することに否定的なプログラマは多いようだ。 フローチャートの表現力は限定的であり、現代的なオブジェクト指向や関数スタイルに対応付かない古い方法であるというのがその主な論拠(ろんきょ)である。

プログラムの処理の流れというのは様々な側面があり、もちろんフローチャート的な側面もあるのは間違いないものの、プログラミング入門においてはフローチャートばかりがあまりに頻出(ひんしゅつ)するというのは頷(うなず)ける話ではある。

だが、私はフローチャートを多用するプログラミング入門教育についてそれで良いと思っている。 訓練する前の人間は手順を表現するということがまるっきり出来ないのが普通だからである。 だからまずはフローチャートで表現・理解することを目標にするのは手頃であろうし、それが身に付かないようでは他の視点を持つことはどうせ出来ない。

初心者の段階を終えていつまでもフローチャートに拘泥するようでは良くないが、入門の段階でフローチャートを中心にする分には問題ではないだろうと思う。 (現実には最初に身に付けたことを後々まで引き摺ってしまうのもよくあることではあるだろうが。)

Document ID: 0f4470d7af129ad0029ffdf299bca37d

library declaration

プログラミング言語 Scheme についてぼんやりと仕様 (R7RS) を眺めていてふと思ったことがある。

define-library を解釈する時点ではライブラリは読み込まれていないのでこれは通常の構文よりもメタな存在だと考えられる。 define-library 以下の <library declaration> 部に現れることができるとされている begin 等の宣言も同様にメタな存在 (普通の構文としての解釈は行われない) だと考えていいのだろうか？

具体的に言えば以下のような書き方をしてもエラーではないのだろうか？

(define-library (foo)
  (export foo)
  (import (except (scheme base) begin))

  (begin
    (define foo 'foo)))

Gauche や Sagittarius で試してみると通ることが確認できるが foment ではエラーになる。

仕様の 5.6.1 では

The begin, include, and include-ci declarations are used to specify the body of the library. They have the same syntax and semantics as the corresponding expression types.

とあるのだが define-library の性質を考えると same syntax というのが字句的にマッチするという意味にもそうでないようにも思える。 あるいは未定義だと考えるべきなのだろうか。

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