自己説明的実行可能ドキュメント(認知症のための「杖」:その後)
自己説明的実行可能ドキュメント(認知症のための「杖」:その後)
Katsunobu IMAI, Hiroshima Univ.
Feb. 3, 2020 @ CiNet
Feb. 3, 2020 @ CiNet
「記憶のないものは、ここへ入ってくることができない、
蛇たちは通さない、といっています。」はてしない物語
蛇たちは通さない、といっています。」はてしない物語
Sorry, these slides are written in Japanese.
Sorry, these slides are written in Japanese.
It is essential for this talk.
The machine translated English version of these slides:
The machine translated English version of these slides:
TranslateNotebook[nb_]:=NotebookPutNotebookGet[nb]/.GraphicsBox[g__]GraphicsBox[g], o_StringIfLanguageIdentify[o]===,TextTranslation[o,"Japanese""English"],o,nbTranslateThisNotebook[]:=TranslateNotebook[InputNotebook[]](* TranslateThisNotebook[]; *)
昨年は3か所でこの発表をしてみたにもかかわらず
昨年は3か所でこの発表をしてみたにもかかわらず
いると信じている「導師」を探す手がかりすら得られなかった
いると信じている「導師」を探す手がかりすら得られなかった
「君の言うようなシステムは不可能だ!」
「君の言うようなシステムは不可能だ!」
聴き手の主な反応は以下の三種類:
1
.認知症患者の支援者の支援しか想定していない
「不可能だ!」「認知症患者に判断力なんてない」
2
.可能だとは考えていなかったが必要性は認識していた
「それこそ介護の現場で必要なことです、実現できるのでしょうか」
3
.(多分)考えていなかったが、やれば可能なのは当然だと思う
「そりゃ、できるでしょうね」
「そりゃ可能でしょう」と答えた人たちの中に「わたしもそういう問題を考えた」という人がいて思わず「導師!」と叫びそうになったが、実はその人は「考えて」いなかったか、少なくとも私の考えている問題とは違った。「忘れた状態を認識する」のが人にとってとても難しいことが少しずつわたしにもわかってきたが、実は、分かっている状態もまた認識するのが難しいのかもしれない。
本質的なことは何か?
本質的なことは何か?
一人称視点の欠如
「実現できるのでしょうか」「そりゃ、できるでしょうね」
やる(実装する)気はあっても一人称視点を持てるとは限らない
やる(実装する)気はあっても一人称視点を持てるとは限らない
本質的なことは何か?
本質的なことは何か?
「他人のことはさておく」こと
「他人のことはさておく」こと
他人のことはさておき、わたしにとって「ドキュメント」と付随する「スクリプト」を認知能力の低下があっても持続的に取り扱えることは本質的である。
自己説明的実行可能ドキュメント
今 x歳なら90-x年後にもドキュメントが理解可能かつ実行可能(生きているドキュメント)
今、当然であることと90-x年後に当然であることは異なる
今当然であることは持続しない
今当然であることは持続しない
学生時代の卒論・修論に関連するファイル類で今でも理解可能かつ実行可能なものは...
Microsoft Excel、Adobe Postscriptファイルと適切にコメントと実行事例とをちりばめたいくつかのCommon Lispファイルのみである
種々のアプリケーションの独自ファイルは全滅した(開けない)
データ類は関連テキストファイルも含め全滅した(適切なドキュメンテーションがなく何のどういう設定のデータかわからず、それを回復するための作業量が得られる利得に引き合わない)
将来を想定したメモを残すことの困難さ
「一件書類」の重要性
処理されるべきデータとスクリプトの関係性
しかし一件書類を的確に仕上げる統合能力が真っ先に失われていく
今当然であることは持続しない
今当然であることは持続しない
「見当識障害」などはあらゆる(ミクロ、マクロな)レベルで起きうる
e.g. 簡単に対処できていたバグをなかなかfixできなくなる
バグの起きるレベルとは?
認知レベルの差によって利用しやすいツールが変化する
データ記述量を適度に短く隠ぺいできる Mathematica で表計算処理は可能だったにもかかわらず、 同じデータを扱う1ページの Excel ファイルの中で「迷子」になってしまった (見当識を保てない)
(Excelはむしろ「データオリエンテッドすぎ」てスクリプトが視野から隠蔽され、双方を同時に 把握し続けるだけの短期記憶があてにできなくなるときつい。
cf. 解像度や着目点の異なる地図、 案内図とそのレイヤー表現)
今まで理解できていたことが理解できなくなるとは?
もはやわたしは1ページが何なのかすらわからない
もはやわたしは1ページが何なのかすらわからない
ドキュメントが理解可能とは?
ドキュメントが理解可能とは?
そもそもわたしたちはどういう状態を理解、実行可能と称しているのか?
自己説明的実行可能ドキュメントが理解可能
自己説明的実行可能ドキュメントが実行可能
自己説明的実行可能ドキュメントが作成可能
わたしにとって“ideal”な自己説明的実行可能性とはどういうことか?
わたしがドキュメントを理解し実行することができる
∃他者にドキュメントを示し理解、実行の手助けを依頼できる
∀他者がわたしとは独立にドキュメントを理解、実行できる
e.g. すべてのソースとその実行系を含むシステムは ∀x, self-contained for x だが、もちろん ∀x,self-describing for x ではない。
自己説明的実行可能ドキュメントを何で支えるか?
自己説明的実行可能ドキュメントを何で支えるか?
(記憶と外部資料の双方、またはどちらかに頼ることができるだけの短期記憶を失う時点を想定すると)言語仕様がそのドキュメンテーションと実行環境の仕様を包含していることは必要条件だろうか?
Xerox Smalltalk (VisualWorks) 1972-
(DEC-10)/Prolog 1972-
Xerox Star Development Environment/Mesa(, Interlisp) 1976-1981
UNIX/C 1977-
Emacs/Emacs Lisp (EINE and ZWEI/Lisp Machine Lisp)1978-
(Literate programming 1984)
FrameMaker+SGML/MML 1981-
Interleaf/Interleaf Lisp (QuickSilver) 1981-
Symbolics Genera/Zeta Lisp (Symbolics Document Examiner) 1983-2005
Adobe PostScript (& PDF) 1984-
ICOT PSI/ESP, KL1 1985-1992
Microsoft Excel/VisualBasic 1985-
NTT ELIS/TAO 1986-1993
Canon Cat/Forth 1987-1987
Apple HyperCard/HyperTalk 1987-2004
Mathematica Notebook/Wolfram Language 1988-
Macromind Director/Lingo 1989-2017
Fujitsu TownsGear/GearBASIC 1990-1997
Apple Soup/NewtonScript 1993-1998
WWW HTML+CSS/Javascript 1995-
Google Drive/Google Apps Script 2009-
Jupiter notebook/Julia, Python and R 2015-
...
自己説明的実行可能ドキュメントを何で支えるか?
自己説明的実行可能ドキュメントを何で支えるか?
言語仕様がそのドキュメンテーションと実行環境の仕様を包含していることは必要条件だろうか?
Xerox Star Development Environment/Mesa(, Interlisp) 1976-1981 終わりました
UNIX/C 1977- UNIX全体を融合したドキュメントとその実行ベースと認識でき、かつ認知症発症後もシステム全体を掌握して使える自信のある人なら...
(Literate programming 1984)
Interleaf/Interleaf Lisp (QuickSilver) 1981- 高いしどこにもない
Adobe PostScript (& PDF) 1984- scriptとしての汎用度が高ければ...それはダメですね。望まれているものではないです。PDFに望まれていることは100年後にも開いて読めることで、むしろ「生きた化石」としての存在です。
Microsoft Excel/VisualBasic 1985- ネ申Excel fileを鑑みれば...
...
“Procrastination” and Larry Tesler
“Procrastination” and Larry Tesler
Tesler worked at Xerox PARC, where some of his main projects were the Gypsy word processor and Smalltalk. Copy and paste was first implemented in 1973-1976 by Tesler and Tim Mott.
http://www.nomodes.com/Larry_Tesler_Consulting/Articles.html
https://guidebookgallery.org/articles/designingthestaruserinterface
https://guidebookgallery.org/articles/designingthestaruserinterface
Tesler worked with Niklaus Wirth on adding object-oriented language extensions to the Pascal programming language, calling the new language Object Pascal. He was also involved in the development of the MacApp.
Tesler led the efforts of developing the Apple Newton.
(Wikipedia)
※認知的ハンディキャップに関する知識をも前提にした開発者が開発している計算機言語システムは今ありますか?
「一件書類」概念の重要性
「一件書類」概念の重要性
UNIX/C 1977- UNIX全体を融合したドキュメントとその実行ベースと認識でき、かつ認知症発症後もシステム全体を掌握して使える自信のある人なら...
認知機能低下時に利用する場合の最大の問題点:
個別のファイルシステム全域に環境依存
「一件書類」概念が欠如
多分、望まれているものは自分の認知変動(環境)に合わせて必要な「解像度」が変化する多重解像度の自己説明的実行可能 一件書類を作ることを心がけ、それが作成されていない場合でも自らの作業履歴データベースから生成、提示すること
たとえ、本体のデータがハイパーテキスト化していても、一件書類として提示する(ハイパーテキストではないようにふるまう)という意味で、従来のハイパーテキスト概念とは対極
言語仕様がそのドキュメンテーションと実行環境の仕様を包含しているシステムがLispばかりなのはなぜだろうか?
言語仕様がそのドキュメンテーションと実行環境の仕様を包含しているシステムがLispばかりなのはなぜだろうか?
「ずっと Lisp 使ってますから。でも素の Lisp 使うのにも耐えられなくなって、 Mathematica ばかり使うようになってますけど。」
「Mathematica って Lisp なんですか?」
「そうです(キッパリ」
「でもLispだって書いてありませんよね。」
「そりゃそうですよ、今時 Lisp って書いても、売り上げが落ちることはあっても上がることはありませんから」
「Mathematica って Lisp なんですか?」
「そうです(キッパリ」
「でもLispだって書いてありませんよね。」
「そりゃそうですよ、今時 Lisp って書いても、売り上げが落ちることはあっても上がることはありませんから」
Lisperは「よく知らない人間の直観」というものを あまり信用していない気がします。
https://practical-scheme.net/wiliki/wiliki.cgi?Lisp%3AS式の理由
言語仕様がそのドキュメンテーションと実行環境の仕様を包含しているシステムがLispばかりなのはなぜだろうか?
言語仕様がそのドキュメンテーションと実行環境の仕様を包含しているシステムがLispばかりなのはなぜだろうか?
「Mathematica って Lisp なんですか?」
「そうです(キッパリ」
「でもS-式じゃないですよね。 Lisp はすべてがS-式でなければ」
「S-式とはちょっと違うけど、 Mathematica はすべてがSu-式ですよ」
「そうです(キッパリ」
「でもS-式じゃないですよね。 Lisp はすべてがS-式でなければ」
「S-式とはちょっと違うけど、 Mathematica はすべてがSu-式ですよ」
このノートブックももちろん数式であり、SelectedNotebook[] + 1 って書いても怒られないし、実際この演算に機能を定義できる。
Mathematica の問題点
Mathematica の問題点
バグが多い
Notebookの構造が複雑なのに、読み込みが文法エラーに脆弱
(cf. エラーまみれのHTMLをとにかく読み込む汎用webブラウザ)
セキュリティに関してほぼ何も考えられてない
ファイルや名前空間のセキュリティだけでなく、その単一実行環境がセキュリティ的に厳しい。しかもカーネルが落ちるとすべてが落ちる。
(Mathematica におけるセキュリティは計算の正しさを保証するために必要なそれ (もちろんとても重要) を指し、いわゆる「セキュリティ」ではない。シンボル空間をコンテキストで分離は可能だが (Protect 宣言以上の) 保護はできない。同じ Lisp 環境でも、 マルチユーザマルチプロセス下におけるシンボル空間と セル空間の保護機構は既に NTT ELIS にもあった。)
Notebookでの日本語の扱いに難がある(その一端はこのスライドを見れば明らか)
(FrameMaker や PDF などと比較しての話。そもそも文字コードの扱い方すら仕様で統一されていない他の言語環境などは論外)。
言語仕様自体が今となっては古風
※ 数式処理システムとしてみた場合の問題点もそれはそれでまた別問題として多々ある
それでも現状では Mathematica notebook 以上の選択肢がない
それでも現状では Mathematica notebook 以上の選択肢がない
言語仕様がそのドキュメンテーションの仕様と実行環境のそれを確かに包含している
30年間を「生きた化石」化せずに存在し続けている数少ない「高級言語」のひとつ
(同じ “Lisp” でも Common Lisp は「高級言語」化にむけた民主主義的な仕様策定の 「成功」によって 「生きた化石化」した。 Cは「高級言語」化を拒み続けることによって 「生きた化石化」の回避に今のところ成功している。 Python は 30年後どうなっているだろうか。)
他者との関係における言語とその記述の積の複雑さ
1. わたしがファイルを理解し実行することができる
2. 他者にドキュメントを示し理解、実行の手助けを依頼できる
3. 他者がわたしとは独立にドキュメントを理解、実行できる
それでも現状では Mathematica notebook 以上の選択肢がない
それでも現状では Mathematica notebook 以上の選択肢がない
いつの日か日本語をそのまま実行可能スクリプトとみなすシステムができるはずであり、それは抽象化された数学的記述も含めて実行できる可能性が高い
その日に備えて素性の良い(機械意味解釈可能な)文章を書くトレーニングが有効かも
しれないが、それは実行可能ドキュメントと関係なく今でも重要な素養である
しれないが、それは実行可能ドキュメントと関係なく今でも重要な素養である
普遍的数学的記述に頼って、ドキュメントが自己説明的に振る舞うことで、十数年後、認知能力が低下した自分が理解できる文書とすることと、他者の支援を得る道を探りたい。
「90-x年後」に Fortran は失われていても、数式で記述された数学の基本的な体系は 失われないのでは? とすれば、 可能な限りはブートストラップで より抽象度を高めた 数学的記述に 変換していくべきだろうし、 現状でそれが Mathematica ならそれを使うべき ではなかろうか?
「Mathematicaが詰むならMapleを使えばいいじゃない?」
認知症フレンドリーな計算機言語とは?
認知症フレンドリーな計算機言語とは?
少なくとも当初から「こんなハンディキャップを背負っているのだと絶望」するような言語は却下
本来、ネイティブな言語(日本語)でダイレクトに書くことを目指すべきである
英語ベースの計算機言語環境はすべてのオブジェクトをダブルポインタ参照しているようなもの。
本来「貧乏性」なプログラマはダブルポインタ参照コストを気にすることが多いのに、英語というダブルポインタ参照コストをなぜ気にしないのだろうか?
認知症フレンドリーな計算機言語とは?
認知症フレンドリーな計算機言語とは?
わたしにとっての距離感:
日本語 < 数式 < Lisp(Mathematica, CommonLisp) < 英語, C
誤解を承知で単純化したたとえを挙げれば... subtract two from six...という英文が「読めなくなる」時点のほうが 数式“6 - 2”の意味がわからなくなるより早い予感がある(個人の感想です)。
Lispはどうか?
S-式の各アトムの近傍の結合をどれだけ認識し続けられるか?
わたしにとって機械翻訳後の文章の認識可能性が英語の原著を上回る時点はいつか?(すでに上回りつつあるが...)
翻訳前後の文章を対比して提示すると現時点では可読性性が上がる場合が多い。しかし認知能力の低下で、対比された文章の配置が遠すぎて相互に突き合わせて理解することができなくなる可能性がある。
実行可能化のための糊(glue)としてのMathematica
実行可能化のための糊(glue)としてのMathematica
原則は日本語と数式を用いて記述する
まずは出発点↓から
とにかく選択を下さねばならない
とにかく選択を下さねばならない
(ここまで消去法的、消極的な理由しか挙げてこなかった)
Mathematicaを選択する「積極」的な理由はあるか?
システムは次の二点を満たしていなければならない
システムの設計者が一人称視点で設計している
その設計者の目的がわたしの目的とできる限り近い
MathematicaはStephenの知識欲をみたすために彼の一人称視点でデザインされ、機能が追加されつづけていている。
とにかく選択を下さねばならない
とにかく選択を下さねばならない
その設計者の目的がわたしの目的とできる限り近い
どうやら Mathematica Notebook は自分の作業過程を記録したい人がデザインしたらしい (Theodore Gray or Stephen Wolfram himself?)
Mathematicaからの「脱出」
Mathematicaからの「脱出」
過去に何度もデータを失ってきた経験からこれは重要なポイント
まずは最低限の非常口を確認しておかねばならない
Wolfram Research に貢ぐことが経済的にできなくなった場合でもファイルの再生実行だけは無償でできる。
ノートブックの利用を停止する必要がある場合:
フォルダのノートブックを根こそぎPDFに変換するには:
自己説明性の高さをできる限り保証しやすい実行可能ドキュメントを意識していられる 限りはExportされたデータにそれなりの意味は見いだせるだろう。(※ 90-x問題)
さて、この「共通実行可能ドキュメント基盤」上で、「わたしとその近傍」に来るべき 認知低下にまつわる「備え」の可否を議論していこう。
あらゆる手がかりをタグ付して残したい
あらゆる手がかりをタグ付して残したい
タグ付けが半自動化されるならなお良い
かつてのStallmanのように777で暮せるだろうか?
かつてのStallmanのように777で暮せるだろうか?
認知症対策、見当識障害対策として、不要な暗号化を避けることができるなら避けた方が良いのは明らか
(今どきのプライバシー遵守の風潮はあらゆるシーンで認知症フレンドリーではない)
適切に部分的に暗号化されたドキュメントでハードディスク全体の暗号化を避けることはできるだろうか?
セキュリティー対策、改竄対策のために電子署名やブロックチェーンによる保護は必要だろうが、可能な限り平文で保持したい。
もちろん現実に立ち向かうには複雑な状況を考慮する必要がある: 参考PDF参照
ファイル全体が秘匿されねばならないわけではない
ファイル全体が秘匿されねばならないわけではない
ましてファイルシステム全体が丸ごと暗号化される必然性もないはず
とはいえ秘匿されるべき部分は外部に露出する場合は自動的に秘匿されるべきであろう
とはいえ秘匿されるべき部分は外部に露出する場合は自動的に秘匿されるべきであろう
既に現時点の認知能力でも、現況のファイル管理ではデータセキュリティを支えきれない
既に現時点の認知能力でも、現況のファイル管理ではデータセキュリティを支えきれない
認知能力の変動を考慮した多重レベルのセキュリティ管理が必須
一件書類としてのスマートコントラクト
一件書類としてのスマートコントラクト
スマートコントラクト Szabo 1977
∃他者にドキュメントを示し理解、実行の手助けを依頼できる
鍵交換をしておこう!
鍵交換をしておこう!
マスタ鍵をどうやって保管するか?
90-x 年後まで使える生体認証鍵とその実装はどこに?
増井さんがbitに書いていた忘却に対して冗長なパスワード
現状では、自ら自己説明的実行可能ドキュメントとして準備するしかなさそう
システム未利用者に対するデータの暗号化
システム未利用者に対するデータの暗号化
あるいは遺言の遺し方
IDベース暗号では、認証局がそのマスタ秘密鍵を各自のIDをベースに各自の秘密鍵を発行できることをあてにして、まだシステムを利用していない(鍵を発行してもらっていない)人に対してもそのIDを使って暗号化データを作成しておくことができる。しかし、(任意の個人を認証してしてくれる)認証局が存在しない場合に、まだシステムを利用していない人に対して暗号化したデータを残す場合にはどういう手立てを講じる必要があるか?
1
.秘密共有したい人とのみ共有していると考えられる質問とその答えにより上述の冗長パスワード保護を用いる(本当に復号できるかどうかを保証できないリスクがある)
2
.複数のシステム利用者による秘密分散共有をあてにする(完全に秘匿されつづけることを保証するのが難しい)。
本来「情報銀行」の役割はマイカード番号にせよ、住基コードにせよ、IDに基づいて個人を認証する認証局としての役割が重要なのだと思うが、例によって今ないものを当てにして始めることはできないので、1,2の合わせ技が現実解だろうか(これから10年の間に状況が変われば臨機応変に修正すればよい)
3
.何人かのシステム利用者が認証した「推薦状」と1の当事者が確実に知っているであろう質問の答えとを組み合わせて、復号の可否を決定する。そのときのセキュリティポリシーをあらかじめ決めておく。
「推薦状」発行者がそのノートブックに推薦状を「添付」すると推薦者のIDは残り、匿名で推薦することができず、かつ、推薦状の必要枚数がセキュリティポリシーで確定していれば漏洩リスクを多少は低減できるだろう。
多重解像度の自己説明的実行可能ドキュメント
多重解像度の自己説明的実行可能ドキュメント
既に現時点の認知能力でも、現況のファイル管理ではデータセキュリティを支えきれない
認知能力の変動を考慮した多重レベルのセキュリティ管理が必須
認知変動を吸収できる自己説明的ドキュメント
セキュリティレベルだけでなく認知変動に合わせたハイパーテキストやバックエンドのデーターベースからの必要な関連データの一件書類化作業の(半)自動化
多重解像度の実行可能ドキュメントとは?
認知変動レベルに応じた遅延評価ベースのスケジューリングを行う
他者の支援を必要とする部分を(半)自動的にアウトソースできる
他者は、支援者に限らず、認知変動で認知能力回復時の自分も包含する
展望
展望
非力なハードウエアで驚異的な速度で動作する HyperCard, ダムターミナルしかない現状からは想像できない「生きたターミナル」が OS 標準だった Genera, ... の存在はもはやオーパーツレベルである。
「Mathematica が詰むなら Maple を使えばいいじゃない?」が可能であるためにはMathematica のような数式処理実行環境の進化を切望する科学者、数学者、趣味人 (とても重要) の要求が強固かつ普遍的であること、が必要である。それを仮定し依存することは妥当だろうか?
もし、この仮定が偽であるか、真であってもその強さが経済的、その他の理由をのりこえるには不十分で当該実行環境とその他選択肢が失われたとする。そういう社会の「短期記憶の喪失に社会の「長期記憶」としての「数学知識」から、その「短期記憶」の一時的喪失を回復できるのだろうか? その回復過程を早めるすべはあるだろうか?
アシモフのファウンデーションですなぁ。
さすがに、この問題をさらに深堀して心配する (Mathematica からの脱出口を確保する以上の) 必要性は多分わたしにはないと信じたい。
さすがに、この問題をさらに深堀して心配する (Mathematica からの脱出口を確保する以上の) 必要性は多分わたしにはないと信じたい。
「それはまた別の話」でしょうね。
メモ
メモ
Logの過去履歴の中に平文(または低いプライバシーレベルの暗号化)で書かれていることを秘匿すべきだと判断した場合、そのセクションを暗号化(レベルを変更)する、すなわちプライバシーレベルが変更可能でなければならない。
Logの履歴に開示してはいけないデータが平文で存在していることと判断した本人、家族知人等関係者、他人がそれを暗号化して保護する事案の場合分けとそれぞれの方策。また、本人の状態と本人のプライバシーポリシーもその方策を実行する関数の引数になっているはず。
プライバシーレベルを上げることは下げるより一般にたやすい。しかし、念のために暗号化するというようなプライバシーレベルを上げることが、たとえば公開されている宣伝をライバルが非公開に設定して営業妨害するような事案を誘発しても困る。さらに本人の認知能力が落ちている場合、秘匿すべきことを他者が秘匿してくれた行為を本人が正しいと認識できるとは限らない。
将来的にはバイオメトリクス認証の進歩で、脳の信号から本人の意思にまつわる状態も含めて認証のとその必要性とを判定して鍵として利用できるようになるかもしれないが、とりあえず現状では増井さんが昔bitに書いていた「超安全パスワード」ようなものをでっちあげて、自分の世代ごとの質問と答えの組をある閾値以上正解するとマスターキーなどがとりだせるドキュメントを準備しておく必要はあるだろう。
プライバシーポリシー自体も開示されている部分と暗号化されている部分があってもよいはず。あるパートに関しては開示が必須なものもあるだろうが、項目によっては記述されているか否か自体を秘匿しないといけない場合もあるだろう。そういう多様な設定項目に関するポリシー実行をゼロ知識証明的な枠組みで実装する必要があるだろう。