買った本
向井さんにコメントをいただき，慌ててオープンソースマガジンの先月号を買いに行って来ました．
OSM 2006年 10月号
この号は，以前も異様に執筆陣が豪華だったので，本屋に行った時に目をつけていたのに，なぜか買い忘れていた号 ! 2 重の意味でしまったー と思いつつも 「落ち着け… 素数を数えて落ち着くんだ… 北海道の時間は，本州よりも一週間ぐらい遅い… まだだ ! まだ間に合う ! (かも) いいや，押すね ! バイツァ・ ダスト !!」
と行ってみたら，まんまとふつうにありました．さすが札幌クオリティ．11 月号の発売日が 10/7 なのに気にしない ! そこにシビれる，アコがれるゥウウ !!
# 以前さかいさんの記事がなかなか読めなくて落ち込んだりもしたけど私は元気です．私，この街が好きです．OSM のバックナンバーに，時を越えて会うことができるから ☆
とまぁ，当初は FUSE 記事が目当てだったのですが，なんだかメジャーな匂いがして，ミーハーチックな自分がいやになってきて，なんだか飽きてしまいました．これじゃまるで，OSM で特集されたから飛びついたみたいじゃないか… っ !
(サブカル系マイナ嗜好厨キモすぎ > 小生)
という，(実は普通にメジャーな) インディーズバンドを追っかける田舎の中学生みたいな未熟でどうでもいい感性は置いておいて．
実はまだ Shiro さんの記事しか読んでないのだが，ひじょーーーーーーーーーーに面白かった．
特に
「stalin は，Siskind 氏が本業の傍ら，専ら個人で使うために開発している処理系のため開発ペースが速いとは言えませんが，実行時性能の高さには定評があります (ただし，そのつっこんだ最適化のために，コンパイル時間が数十分に及ぶこともあるのですが)」
の括弧内の部分．あー，やっぱりー と w
C/C++ みたいに，型が付いてて，分割コンパイルを許す言語は，コンパイル時間は短くできるんですけど，そのぶんプログラム全体まるごとのみこんで最適化，みたいなことは，あんまり行わないような気がします．
Linkers & Loaders を読んでいたら，せいぜいリンク時に GC (どこからも参照されていなくて使われてない関数や変数を取り除く) やインライン展開などの最適化を行うのがせいぜい，みたいな．
まぁ，それはそれで，動的リンクや分割コンパイルのメリットを最大限に享受でき，コンパイル時間も現実的になるという良さもあるのですが．私は，ここらへんのフラットさ，柔軟性の乏しさが，長年 C 言語の重大な欠陥というか，嫌なところだと思って来ていたので．
でも，そういう主張は気いたことが無かったので，今回のコレを読んで，「おお，やっぱり，これはアリなんだ ! 」と勇気付けられました．やっぱり動的な言語は，プログラム全てのみこんで，その宇宙の中で型付けしてフロー解析して最適化してくしかないんですよね．逆に言うと，かなり突っ込んだ最適化もできるので，C/C++ とかの，何重ものライブラリ階層を挟んだフラットなコードよりも速いコードを容易に出せる可能性が生まれて来る．
ET 言語ってのは，基本的にはアトム置き換えで実行が進んで行くので，もうひたすら部分評価部分評価で，関連する全ルールを全て取り込んでゴニョゴニョするというやり方で，今私は ET の最適化コンパイラ (C がオブジェクトコードなので，正確にはトランスレータかも) を作っているのですが．
# ちなみに，ET 言語については，ここらへんでもちょこっと書いてた．
これらの最適化は，とにかく時間がかかるので，「う〜ん，いろいろ厳しいと言うか，現実的じゃないのかな… 」と思うこともあったのですが．
逆に考えるんだ，コンパイルに 1 時間かかっちゃってもいいんだ，と考えるんだ !
(今のところは，小さなプログラムしか扱ってないので，せいぜい数十秒ですが．それでもかなり長い気がします．もし，e-lerning system みたいな，非常に巨大なシステムをまるごとコンパイルするときには，いろいろ工夫しないと駄目かも)
まぁ，普段はインタプリタで実行すれば良いわけだし．なにも言語処理系だけでエラーチェックをする必要もないわけだし (あと，ET 言語の場合は，そもそもプログラム自体が中間言語の表現方法に過ぎないので，仕様のレベルで型が付いてれば，そのまま型付きの言語と同じようにコンパイルもできるだろうし．私にはまだそんな技術はありませんが)．
あと，Matz さんの書いた，プログラミング言語の歴史を振り返る記事が，(おこがましいですが) 私が昔書いた記事と切口とかがほとんど同じ (というか，あたりまえか w) だったので，けっこううれしかったです．おー，だいたいはそれっぽいこと書いてたんだな，と．
テキトーな小生の卒論
まぁ，紙面や読者層の都合もあったのでしょうが，Prolog や制約プログラミング方面がごっそり抜けてたのが，ちょっとひどいと思いましたが w
上 (産業界) のほうがやたら細かいのに，下 (アカデミック) の方は，ML → Haskell とか，略しすぎのような w KRC とか Miranda という流れは無視という．
良く知りませんが，ここらへんの構文とか，パタンマッチとかには，けっこう Prolog の影響も大きかったんちゃう ? という気もしますな (もう細かい歴史はほとんど忘れたけど)．けっこう断絶が激しい (というか，Prolog の人たちが，フランス語でしか論文を書かなかった…) ので，別な流れがあるのかもしれませんが．そもそも，オブジェクト指向には，AI 研究の流れがあるわけだし．ミンスキーのフレーム論理とか，後の心の社会理論とかは，まんまオブジェクト指向やエージェント指向 (あるいはアクター) の考え方の基礎だし．
個人的には，OSM は，DVD とか付けないで，記事だけで 1000 円とかの方が買いやすいような．もう後の祭ですが．
あともう一冊は，k.inaba さんの本と迷ったのですが，けっきょく k.inaba さんに薦められた 「Exceptional C++」 を買ってしまいました．
感想は… まだ眺めた程度ですが…
う〜ん
あれれ，おかしいなーまったくりかいできないぞ．
一ページ目から，以下のコードのイテレータの使い方の間違いを 4 つ指摘せよ，的なレベル．完全においてけぼりですな．
う〜ん，C++ の莫大な大きさの標準ライブラリどころか，構文すら怪しい初心者の私には，全くもって理解不能 (だいたいはわかりますけど)．
C++ をまともに使うには，このレベルの知識が要求されるのかねぇ．
ということで，私はプログラマに向いてないことがよくわかったので，田舎に帰って米でも作ってほそぼそ生きて行こうと思いました．
こういうハイレベルな本 (C++er には常識なのかもしれませんが) を見てると，Joel とかが良く言う，「自分たちのチーム以外が書いたコードは，率直に言ってゴミなのだ」という言葉が理解できるような気がする．
そりゃあ，ここまで意識に差があったらねぇと．C++ 使いが，いつもいつも Java をオモチャ扱いする気持ちも理解できる気がしますな．
TC++PL か C++ Primer も買わないと駄目なのかね…
まぁ，とりあえず，じっくり読んでみよう．教養として．わからなくなったら，ブログで偉い人達に聞けば良いし w (C++ はいっぱいいるだろう)
いずれにせよ，このレベルの日本語の本が普通に出版されているということ自体が，C++ の一番の強みのような．
他の言語なんて，9 割以上がどうでもいい (つまり，Web 上で間に合う程度の) 入門書なんじゃないかな ? 哲学とか，コンセプトのちょーでぃーぷな部分まで，一般人が一応まとまった書籍の形で読むことができるということ自体が，C++ の普及度と重要性を示唆している気がします．そりゃあ，アカデミックの方が，理論的に綺麗でまとまっていて先を行っているのかもしれないけど．それを追えるのは，たとえ学者でも，ほんのごく一部の専門家のはず．これはちょっと，他の言語では追い付けないと思う．
# いや，洋書はいっぱいあると思いますが… (英語読めない人)
あと，よくブログの自己紹介とかに，「使える言語 : C/C++/Java/Perl/日本語」 みたいなのがあったりしますが w
「使える」のレベルに，とんでもない上下差があるというのも，C/C++ 独自のような．
まぁ，結局は，GC はエライ ! C++ Sucks ! という話になるのかもしれないけどね．C++ とびょるんすぽっすとっ先生の哲学を知らないというのは，非常に損というのは正しいような気がしますな．
(私みたいなへたれが書くべきことではありませんが…)
あー，あと，OSM の付録の Berry Linux は，気軽に xgl とか Unionfs が楽しめるとかいう話アルヨ．
大変素晴らしい感じなので，今度試してみる．というか，ビデオカード買わないとなぁ．
(付録はいらないとか言った舌の根も乾かぬうちに…)
Stalin スゲーと思って，ソースを眺めてみたら．
コンパイラ自身も Scheme で書かれてるみたいなんだけど，これまたヤバイね，わけわからん．エライ密度でコードが詰め込まれている上に，コメントが一切無いんだけど．正気なのかね．Lisper は凄い．
Stalin がマクロをサポートしないってのは，なんか技術的に困難な理由でもあるのだろうか ? 単に効率が落ちるのを嫌っただけ ?
こないだ sumii さんに教えていただいた Scheme->C トランスレータの話の中に出てきた，continuation を使った backtracking の実装，実はわけわかんなくてかなり悩んでいたんだけど，解説が ！ ありがたい．
継続でバックトラック
この頁の作者様は，あの知る人ぞ知る Common Lisp サイト，元「よろずや」さんみたいですな．更新が途絶えていて残念がっていたのですが，密かに (失礼) 再開なされていたようで．素晴らしい．
特にコレはすごい．もう Common Lisp が Ruby にしか見えない．
最高にキモい Lisp コードを書いてみよう with 100 行リーダーマクロ
こういうの見ると，もう Matz Lisp は Common Lisp の ALGOL 風構文 DSL ってことでいいんじゃないかと．Ruby->CL で変換して，ACL とか，CL の最強コンパイラでコンパイルと．
古い Lisp の話も面白い．もうハッカーズを読んだのはだいぶ昔で，当時 (大学入りたて．一番最初に読んだ本がいけなかった…) は右も左もわかってなかったからなぁ．だいぶ記憶があやふや．今もう一度読み返して見たら，またいろいろと得るものが大きいのかもしれない．
Common Lisp は，defun がキモい，という理由だけで使ったことが無いんだよな．でも実は名前空間が分かれている方が，実用上 (処理効率，コンパイラの解析含め) は便利なのかもしれない．あと，アンチ emacs 派なんで elisp も知らないんだけど，やっぱり Lisp 使うなら emacs みたいね．
# もっと見た目がモダンになってくれれば… (軟弱) xyzzy は，もしかしたらちゃんと使い込むとひじょーに素晴らしいのかもしれない．vim 以外のエディタ使えない人なんだけど…
ちょっと前半の寝惚けながら昨日の夜に書いてた部分を読み返してみたら (というか，後半は全然タイトルと関係ない，単なるメモになってますな) フラットな抽象化， とかって曖昧で意味不明なオレ用語だったかも，と．
昔，直接人間が機械語を書いていた時代は，CPU の命令セットを拡張して豊かにしていくことが，それすなわち抽象化であり，高級化であったわけですよ．
しかし，そういうフラットなやり方 (古いやり方，固定観念の延長線上，のっぺりした悪あがきというか，アドホックというか… 言葉足らずですいません) には様々な限界があったので，後に RISC とコンパイラという，より構造化，組織化された抽象化や高級化の枠組が生まれて来たわけで．
そういう意味では，C 言語を直接高級化した C++ ってのは，そのフラットさゆえに柔軟性が低くなってしまうのかなぁと．
Lisp から C へのトランスレータってのは，ある意味では Lisp で仕様記述して，C プログラムを自動生成することにより，C 言語の抽象化力を強化していると見ることもできます．C 自体がけっこうアレなんで，いろいろ難しいところもありますが，これはこれで一定の成功を納めている優れた抽象化だと．
まぁ，計算機自体がフラットでアドホックなローカルオプチマイズの固まり (というか，x86 がか…) なんで，より豊かで体系的なアプローチが必ずしも上手くいくってわけでは無いのですが．
RISC の方が理論的には優れている (CPU とメモリの速度差が思ったよりも広がったとか，いろいろ複雑に要因は絡まっているのですが) とはいえ，現実的には，こんだけ変態的な構造ながらも，普及度と資本の力で Intel の x86 の一人勝ちになってますし． その点では，C++ は非常に実用的な必要悪，という見方もできると思います (夢想なら，誰でもいくらでも言える．現実と真正面から向き合い続けてきたじゃーねすぽすぽ先生は偉いとですよ)．逆に老害とも言えるのですが．
まとまらないな… 眠い．
OSM 2006年 10月号
この号は，以前も異様に執筆陣が豪華だったので，本屋に行った時に目をつけていたのに，なぜか買い忘れていた号 ! 2 重の意味でしまったー と思いつつも 「落ち着け… 素数を数えて落ち着くんだ… 北海道の時間は，本州よりも一週間ぐらい遅い… まだだ ! まだ間に合う ! (かも) いいや，押すね ! バイツァ・ ダスト !!」
と行ってみたら，まんまとふつうにありました．さすが札幌クオリティ．11 月号の発売日が 10/7 なのに気にしない ! そこにシビれる，アコがれるゥウウ !!
# 以前さかいさんの記事がなかなか読めなくて落ち込んだりもしたけど私は元気です．私，この街が好きです．OSM のバックナンバーに，時を越えて会うことができるから ☆
とまぁ，当初は FUSE 記事が目当てだったのですが，なんだかメジャーな匂いがして，ミーハーチックな自分がいやになってきて，なんだか飽きてしまいました．これじゃまるで，OSM で特集されたから飛びついたみたいじゃないか… っ !
(サブカル系マイナ嗜好厨キモすぎ > 小生)
という，(実は普通にメジャーな) インディーズバンドを追っかける田舎の中学生みたいな未熟でどうでもいい感性は置いておいて．
実はまだ Shiro さんの記事しか読んでないのだが，ひじょーーーーーーーーーーに面白かった．
特に
「stalin は，Siskind 氏が本業の傍ら，専ら個人で使うために開発している処理系のため開発ペースが速いとは言えませんが，実行時性能の高さには定評があります (ただし，そのつっこんだ最適化のために，コンパイル時間が数十分に及ぶこともあるのですが)」
の括弧内の部分．あー，やっぱりー と w
C/C++ みたいに，型が付いてて，分割コンパイルを許す言語は，コンパイル時間は短くできるんですけど，そのぶんプログラム全体まるごとのみこんで最適化，みたいなことは，あんまり行わないような気がします．
Linkers & Loaders を読んでいたら，せいぜいリンク時に GC (どこからも参照されていなくて使われてない関数や変数を取り除く) やインライン展開などの最適化を行うのがせいぜい，みたいな．
まぁ，それはそれで，動的リンクや分割コンパイルのメリットを最大限に享受でき，コンパイル時間も現実的になるという良さもあるのですが．私は，ここらへんのフラットさ，柔軟性の乏しさが，長年 C 言語の重大な欠陥というか，嫌なところだと思って来ていたので．
でも，そういう主張は気いたことが無かったので，今回のコレを読んで，「おお，やっぱり，これはアリなんだ ! 」と勇気付けられました．やっぱり動的な言語は，プログラム全てのみこんで，その宇宙の中で型付けしてフロー解析して最適化してくしかないんですよね．逆に言うと，かなり突っ込んだ最適化もできるので，C/C++ とかの，何重ものライブラリ階層を挟んだフラットなコードよりも速いコードを容易に出せる可能性が生まれて来る．
ET 言語ってのは，基本的にはアトム置き換えで実行が進んで行くので，もうひたすら部分評価部分評価で，関連する全ルールを全て取り込んでゴニョゴニョするというやり方で，今私は ET の最適化コンパイラ (C がオブジェクトコードなので，正確にはトランスレータかも) を作っているのですが．
# ちなみに，ET 言語については，ここらへんでもちょこっと書いてた．
これらの最適化は，とにかく時間がかかるので，「う〜ん，いろいろ厳しいと言うか，現実的じゃないのかな… 」と思うこともあったのですが．
逆に考えるんだ，コンパイルに 1 時間かかっちゃってもいいんだ，と考えるんだ !
(今のところは，小さなプログラムしか扱ってないので，せいぜい数十秒ですが．それでもかなり長い気がします．もし，e-lerning system みたいな，非常に巨大なシステムをまるごとコンパイルするときには，いろいろ工夫しないと駄目かも)
まぁ，普段はインタプリタで実行すれば良いわけだし．なにも言語処理系だけでエラーチェックをする必要もないわけだし (あと，ET 言語の場合は，そもそもプログラム自体が中間言語の表現方法に過ぎないので，仕様のレベルで型が付いてれば，そのまま型付きの言語と同じようにコンパイルもできるだろうし．私にはまだそんな技術はありませんが)．
あと，Matz さんの書いた，プログラミング言語の歴史を振り返る記事が，(おこがましいですが) 私が昔書いた記事と切口とかがほとんど同じ (というか，あたりまえか w) だったので，けっこううれしかったです．おー，だいたいはそれっぽいこと書いてたんだな，と．
テキトーな小生の卒論
まぁ，紙面や読者層の都合もあったのでしょうが，Prolog や制約プログラミング方面がごっそり抜けてたのが，ちょっとひどいと思いましたが w
上 (産業界) のほうがやたら細かいのに，下 (アカデミック) の方は，ML → Haskell とか，略しすぎのような w KRC とか Miranda という流れは無視という．
良く知りませんが，ここらへんの構文とか，パタンマッチとかには，けっこう Prolog の影響も大きかったんちゃう ? という気もしますな (もう細かい歴史はほとんど忘れたけど)．けっこう断絶が激しい (というか，Prolog の人たちが，フランス語でしか論文を書かなかった…) ので，別な流れがあるのかもしれませんが．そもそも，オブジェクト指向には，AI 研究の流れがあるわけだし．ミンスキーのフレーム論理とか，後の心の社会理論とかは，まんまオブジェクト指向やエージェント指向 (あるいはアクター) の考え方の基礎だし．
個人的には，OSM は，DVD とか付けないで，記事だけで 1000 円とかの方が買いやすいような．もう後の祭ですが．
あともう一冊は，k.inaba さんの本と迷ったのですが，けっきょく k.inaba さんに薦められた 「Exceptional C++」 を買ってしまいました．
感想は… まだ眺めた程度ですが…
う〜ん
あれれ，おかしいなーまったくりかいできないぞ．
一ページ目から，以下のコードのイテレータの使い方の間違いを 4 つ指摘せよ，的なレベル．完全においてけぼりですな．
う〜ん，C++ の莫大な大きさの標準ライブラリどころか，構文すら怪しい初心者の私には，全くもって理解不能 (だいたいはわかりますけど)．
C++ をまともに使うには，このレベルの知識が要求されるのかねぇ．
ということで，私はプログラマに向いてないことがよくわかったので，田舎に帰って米でも作ってほそぼそ生きて行こうと思いました．
こういうハイレベルな本 (C++er には常識なのかもしれませんが) を見てると，Joel とかが良く言う，「自分たちのチーム以外が書いたコードは，率直に言ってゴミなのだ」という言葉が理解できるような気がする．
そりゃあ，ここまで意識に差があったらねぇと．C++ 使いが，いつもいつも Java をオモチャ扱いする気持ちも理解できる気がしますな．
TC++PL か C++ Primer も買わないと駄目なのかね…
まぁ，とりあえず，じっくり読んでみよう．教養として．わからなくなったら，ブログで偉い人達に聞けば良いし w (C++ はいっぱいいるだろう)
いずれにせよ，このレベルの日本語の本が普通に出版されているということ自体が，C++ の一番の強みのような．
他の言語なんて，9 割以上がどうでもいい (つまり，Web 上で間に合う程度の) 入門書なんじゃないかな ? 哲学とか，コンセプトのちょーでぃーぷな部分まで，一般人が一応まとまった書籍の形で読むことができるということ自体が，C++ の普及度と重要性を示唆している気がします．そりゃあ，アカデミックの方が，理論的に綺麗でまとまっていて先を行っているのかもしれないけど．それを追えるのは，たとえ学者でも，ほんのごく一部の専門家のはず．これはちょっと，他の言語では追い付けないと思う．
# いや，洋書はいっぱいあると思いますが… (英語読めない人)
あと，よくブログの自己紹介とかに，「使える言語 : C/C++/Java/Perl/日本語」 みたいなのがあったりしますが w
「使える」のレベルに，とんでもない上下差があるというのも，C/C++ 独自のような．
まぁ，結局は，GC はエライ ! C++ Sucks ! という話になるのかもしれないけどね．C++ とびょるんすぽっすとっ先生の哲学を知らないというのは，非常に損というのは正しいような気がしますな．
(私みたいなへたれが書くべきことではありませんが…)
あー，あと，OSM の付録の Berry Linux は，気軽に xgl とか Unionfs が楽しめるとかいう話アルヨ．
大変素晴らしい感じなので，今度試してみる．というか，ビデオカード買わないとなぁ．
(付録はいらないとか言った舌の根も乾かぬうちに…)
Stalin スゲーと思って，ソースを眺めてみたら．
コンパイラ自身も Scheme で書かれてるみたいなんだけど，これまたヤバイね，わけわからん．エライ密度でコードが詰め込まれている上に，コメントが一切無いんだけど．正気なのかね．Lisper は凄い．
Stalin がマクロをサポートしないってのは，なんか技術的に困難な理由でもあるのだろうか ? 単に効率が落ちるのを嫌っただけ ?
こないだ sumii さんに教えていただいた Scheme->C トランスレータの話の中に出てきた，continuation を使った backtracking の実装，実はわけわかんなくてかなり悩んでいたんだけど，解説が ！ ありがたい．
継続でバックトラック
この頁の作者様は，あの知る人ぞ知る Common Lisp サイト，元「よろずや」さんみたいですな．更新が途絶えていて残念がっていたのですが，密かに (失礼) 再開なされていたようで．素晴らしい．
特にコレはすごい．もう Common Lisp が Ruby にしか見えない．
最高にキモい Lisp コードを書いてみよう with 100 行リーダーマクロ
こういうの見ると，もう Matz Lisp は Common Lisp の ALGOL 風構文 DSL ってことでいいんじゃないかと．Ruby->CL で変換して，ACL とか，CL の最強コンパイラでコンパイルと．
古い Lisp の話も面白い．もうハッカーズを読んだのはだいぶ昔で，当時 (大学入りたて．一番最初に読んだ本がいけなかった…) は右も左もわかってなかったからなぁ．だいぶ記憶があやふや．今もう一度読み返して見たら，またいろいろと得るものが大きいのかもしれない．
Common Lisp は，defun がキモい，という理由だけで使ったことが無いんだよな．でも実は名前空間が分かれている方が，実用上 (処理効率，コンパイラの解析含め) は便利なのかもしれない．あと，アンチ emacs 派なんで elisp も知らないんだけど，やっぱり Lisp 使うなら emacs みたいね．
# もっと見た目がモダンになってくれれば… (軟弱) xyzzy は，もしかしたらちゃんと使い込むとひじょーに素晴らしいのかもしれない．vim 以外のエディタ使えない人なんだけど…
ちょっと前半の寝惚けながら昨日の夜に書いてた部分を読み返してみたら (というか，後半は全然タイトルと関係ない，単なるメモになってますな) フラットな抽象化， とかって曖昧で意味不明なオレ用語だったかも，と．
昔，直接人間が機械語を書いていた時代は，CPU の命令セットを拡張して豊かにしていくことが，それすなわち抽象化であり，高級化であったわけですよ．
しかし，そういうフラットなやり方 (古いやり方，固定観念の延長線上，のっぺりした悪あがきというか，アドホックというか… 言葉足らずですいません) には様々な限界があったので，後に RISC とコンパイラという，より構造化，組織化された抽象化や高級化の枠組が生まれて来たわけで．
そういう意味では，C 言語を直接高級化した C++ ってのは，そのフラットさゆえに柔軟性が低くなってしまうのかなぁと．
Lisp から C へのトランスレータってのは，ある意味では Lisp で仕様記述して，C プログラムを自動生成することにより，C 言語の抽象化力を強化していると見ることもできます．C 自体がけっこうアレなんで，いろいろ難しいところもありますが，これはこれで一定の成功を納めている優れた抽象化だと．
まぁ，計算機自体がフラットでアドホックなローカルオプチマイズの固まり (というか，x86 がか…) なんで，より豊かで体系的なアプローチが必ずしも上手くいくってわけでは無いのですが．
RISC の方が理論的には優れている (CPU とメモリの速度差が思ったよりも広がったとか，いろいろ複雑に要因は絡まっているのですが) とはいえ，現実的には，こんだけ変態的な構造ながらも，普及度と資本の力で Intel の x86 の一人勝ちになってますし． その点では，C++ は非常に実用的な必要悪，という見方もできると思います (夢想なら，誰でもいくらでも言える．現実と真正面から向き合い続けてきたじゃーねすぽすぽ先生は偉いとですよ)．逆に老害とも言えるのですが．
まとまらないな… 眠い．
