Timeline for it list by senooken, page 90

徹底的行動主義になってない説明の方が技術を伝達しやすいという意味では機能的というのはそうだと思うんだけど……。やっぱそこ重要なところだと思うし、報酬とかご褒美とかいうのよくないと思う……。

子供の教育とかでは非随伴性強化法(NCR)が強力な場合が多いので紹介したいんだけど、検索して見つかる記事ってどうも説明が徹底的行動主義してないんで困る。問題行動の正の強化子を行動に随伴させずに、提示することで問題行動を減らすテクニックで赤ちゃんの夜泣きの問題とかはこっちで解消するのが良いと思う(産業図書の『行動分析学入門』は消去で夜泣きの対応する例を紹介してるんだけど、あれは駄目だと思う……。普通に赤ちゃんが可哀そうで受け入れられないでしょ。そもそも素人が消去バーストに耐えられるとは思えんし)。

非随伴性強化(NCR)を適用するにも何が正の強化子になっているのかを見極めることが大切なんで、安易に「ご褒美」だとか「報酬」とかいう表現を使うとどつぼに嵌りかねない。行動分析学の手法を使うときはあなたの思う「ご褒美」や「報酬が」、対象にとっても同様かは分からないということを常に念頭に置いておく必要がある。自分にとってもそうで本当にそれが「正の強化子」として機能しているかは「ご褒美」であるかとか「報酬」であるかとかで判断はできない。実験によって明らかになることであり思い込んではならない。

行動の前後に何が起きているのかを広く見渡して、行動がどう機能しているのかを見ないといけない。

行動の機能が問題なのではなくて、形態が問題なのであれば別の形態で同じ機能を持つ行動を強化することで解決する場合もある。機能への注目を忘れると、同一の機能を持った行動は強化されたままであることを忘れてしまい、問題行動を行動分析学の手法で減らしたと思ったら別の問題行動が生じるようになったということになりかねない。問題行動を減らすときそれと近い機能を持つ問題と見做されないような行動を強化する視点を忘れてはならない。

酒やタバコに関する行動の機能が人によって異なる以上、どうやって対処すれば良いかは人によって異なるわけで、やはり行動分析学家は人員不足だといえる。こういった問題についても個々のケースで機能分析できないと根本問題は解消不能なために一般に良いといえる手段を提供できない。

この前、酒、タバコを「やめたいのにやめられない」のを止める手段について言及したときに、重要な観点を見落していたことに気づいた。

ただ、やめるだけじゃなくてそれをやめた時間に何をするのかもまた重要だ。代替行動も(自身や周囲の他者にとって)問題と見做されるのであれば結局のところ意味がない。

え、また五輪やろうとしてたのか。もう五輪とか前時代的にもほどがあると思うんだよな。まあ、私がスポーツに一切関心がないだけなんかもしれんが。

複数の h1 はありかどうか問題、これ SEO 以外ではどうでもいいという感じだと思うんでもう複数 h1 を使うスタイルに変えちゃっていいかな……。Google が h1 は複数でも良いよっていっても、DuckDuckGo がどう思ってるかは知らんしなという気持ちがあるんだよな。

しかし、私の個人ブログは広告はないしアクセスのカウントすらしてないし、SEO で優位に立つ必要はないと判断し自分の好きなようにやろうと思う。RSS だけは残そう……。

最初の記事に下記のように記載しているわけだし、もっと雑に更新すべき。そのために更新時の障壁を最小にするために楽に書けるようにしたい。

> ブログを始めてみました。有益なことを書く予定はありません。https://www.tojo.tokyo/hello-world.html

記事を全部 org-mode に変えたくなるとはサイトを開設した当時は思いもよらなかったことだし仕方がない。org-mode から Emacs で html を生成すると色々と融通が聞いて楽なんだよな。pandoc とかで他の形式に変換しようとするとどうも微妙に求めていることができなかったりしてつらい。

なんで初期の頃は sxml で記事を書いてたんだろう……。記事の文書をダブルクォートで囲むの面倒すぎるでしょ。正気の沙汰とは思えない。

@tacumi 最初のきっかけは高校時代になんか手に職を付けた方がいいかなーみたいな感じでプログミングを学んだところ、いつのまにかにプログラミング自体が面白くなってしまったためにプログラムを書いていた感じですね。

当時はなんかやりたいことを勝手に思いついてやってた気がするんですが、今はもう何も思いつかないという状況です。

とりあえず、個人 Web サイトが org-mode から生成されていないことによる不満は多いのでそれだけ正月中にやろうと思ってる。

いま、趣味開発意欲(仮説的構成概念)がない問題について考えていて、そもそも自分が普段どのようなソフトウェアを使っているのか、また今パソコンで何かしたいことがあるのかが問われている。

sxml で書いた記事を commonmark に変換してる。Web サイトを全部 org-mode から生成するように移行して、org-mode への移行後も変更履歴の追跡できるように comonmark に変換して git に残す方法を採用するため(拡張子が変わると、git の log でそれまでの変更履歴が追えなくなってしまうため、中間表現として Markdown を使用する目論見、sxml 書いた記事のいままでの変更履歴については大した量がないため目を瞑る)。今後、org-mode をやめても中間表現として Markdown を利用することをやめない限り、変更履歴の追跡は可能なままとなる。

pandoc で sxml から Haunt によって生成された HTML を commonmark に変換するのが楽だと分かった。

前者と後者が逆だと思ったんだけど、もう一回読み直したら逆じゃなかった……。

円滑に SICP を進めるための準備をするための SRFI も既に Finalized になってる。https://srfi.schemers.org/srfi-216/srfi-216.html

SRFI-203 に SICP の図形言語の仕様が Finalized されててびっくりした。これから SICP の図形言語を実装するときはこのインターフェースに従った方がよさそうだな。https://srfi.schemers.org/srfi-203/srfi-203.html

SRFI-180 が既に Finalize されてて、これによると object を alist にする方式が採用されたっぽいな。

https://srfi.schemers.org/srfi-180/srfi-180.html

R7RS-large、私が生きている間に完成するのかな……。

個人的に SRFI 41 の命名規則と SRFI 121 の命名規則は、前者は長くなっても理解しやすいことを優先し、後者は利用頻度の高いものに関しては名前は短かくて読みやすくするのを優先するという点で命名の仕方の思想に決定的な違いがあると思う。これには一長一短あると思うんでどちらが良いとは言えないんだけど、R7RS-large という一つの言語仕様に両方が入るのはなんというかやばいのではないかという気持ちがちょっとある。でも、片方の命名の仕方を否定してしまうのもどうかという感じがあり、そのまま受け入れざるを得ないというのも分かる……。

私がこんな風に思うくらいなんだから、たぶんもうずっと前に R7RS-large 関連のメーリングリストで既に議論がなされた後なんだろうな。