このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
商用トラックドライバーの連続運転時間管理も超厳しかったり、アメリカってこういうところがちゃんとあれでいい感じかも＞＜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
タヌキも昔は普通にいたのに何年も前の大雪か台風かどっちか忘れたけど天候荒れた時以来きっかり全く見かけなくなった・・・・＞＜
アライグマは子アライグマならだっこできそうなレベルに警戒心弱いけど＞＜；
子アライグマが来たときにだっこしなかったのすごく後悔してる＞＜；(駆除されまくってこなくなった＞＜；)
ググったらハクビシンって警戒心強いっぽいけど、タヌキ並み(＝見るのも難しい)に警戒心あるのかな？＞＜；
移動したのか寝たのかわかんないけど、ハクビシン(たぶん)の足音しなくなった＞＜
断続的に音がずっとしてるって事は一匹じゃなく親子で子ハクビシンが遊んでるとかなのかな？＞＜；
ハクビシン、飼っちゃダメで追い出したければ業者呼べで費用は自己負担？＞＜；
ハクビシンはペットとして飼える？飼育の許可・申請、入手方法 | ハクビシン駆除プラス https://hakubishin-kujyo.jp/hakubishin-pet
"埼玉県の場合、ハクビシンを含む狩猟対象の動物をペットにするために捕獲することは禁止されています。"
・・・・・＞＜
天井引っ掻いて怖がらせてコミュニケーション(？)はとれたけど、どうせ住むならペットになってほしさ＞＜；
そもそもハクビシンかどうかもわかんないけど＞＜； でもネズミよりははるかに大きい動物の足音＞＜
(1ヵ月くらい前？からオレンジの家の別の部屋の天井から音がしてて家族の人がハクビシンかも？って言ってた状況＞＜)
・・・＞＜
首都高速道路 一部出入り口廃止へ 地下化工事の本格化に伴い | NHKニュース https://www3.nhk.or.jp/news/html/20210129/k10012838261000.html
2000年辺りにWindows9xマシンでUSB無いやつそんなに残ってたっけって謎＞＜；
(当時のUSBって今ほど安定してなくて、相性で動いたり動かなかったりって問題はあった記憶はあるけど＞＜)
2000年3月20日発売のMSAC-US1っていうソニー純正USB接続メモリースティックリーダライタが希望小売価格7,800円だったらしい・・・＞＜
USB接続のFDDでは使用できませんってわざわざ書くって事は、USBある程度普及してる時期じゃん？＞＜；
素直にUSB接続のアダプタ使う方が当時でも安かったんでは？＞＜；
今考えると意味不明なものってだけじゃなく、時期を考えると当時でもかなり意味不明なものだったんじゃないの？＞＜； って気が・・・＞＜；
アダプタの電池残量も取得してるっぽい＞＜
MVC-FD87:取扱説明書 - 取扱説明書ダウンロード | サポート・お問い合わせ | ソニー https://www.sony.jp/ServiceArea/impdf/manual/30667410MVC-FD87.html
News and Information "MVC-FD87,MVC-FD92,MVC-FD97" https://www.sony.jp/CorporateCruise/Press/200102/01-0209A/
"...また、『MVC-FD87』は別売メモリースティック用フロッピーディスクアダプター『MSAC-FD2MA』を使用することで“メモリースティック”への画像記録が可能です。大容量記録を実現します。"
大容量って事は、アダプタ対応のマビカも厳密なエミュレーションじゃなくアクセスするっぽさ？＞＜
2001年02月09日 ASCII.jp：ソニー、FDに記録するデジカメ『FD Mavica』3機種を発売 https://ascii.jp/elem/000/000/320/320639/
Sony Japan | MSAC-FD2MA/FD2M 取扱説明書 | メモリーカード メモリースティック™ | サポート https://www.sony.co.jp/Products/memorycard/memorystick/adp/FD2/manual.html
説明書読んだ感じだと、厳密にエミュレーションしてるわけじゃなく専用ドライバ経由で送受信してるだけっぽい・・・？＞＜
フロッピーより容量の大きいメディアをフロッピーのフリしてごまかすの、セクタ数とかトラック数を偽ってドライブ側に通知すればいけるものなんだろうか。いやシリコンメディアでもHDDとかと同じか。FDDのインターフェイスがそれに対応できるかどうか。
微妙に関係ないけど、NASA TVで初めてISSからの映像で遅延数十秒程度で関東平野を見れた時に「ほんとに関東平野ってこういう形してたんだ！＞＜」って納得(？)できた＞＜
録画とか写真だと信じないとかではないけど、なんかこう・・・＞＜
ハードドライブのガワが硬いのは触って分かるけど、ディスクが硬いかどうかは実際に分解して見たことが無いので分からない。
英語ネイティブな人にとってはハードディスクって略語の方は違和感がある語感(？)なのかな？＞＜；
ソースネクスト製品お値段がビックリだけど、例えばゲーム用メモリクリーナーって21世紀の今でも一目瞭然に効果がある(ので自分でつくって自分で使ってる)けど、まともなGUIつけたシェアウェアにしたら1000円以上でも買う人それなりにいるのかな？＞＜；(ソースネクスト製品を買いそうな層とゲームやってる人ってなんかイメージ一致しないけど＞＜；)
今もあるのか・・・＞＜；
パソコン高速化ソフト 驚速 for Windows 10｜ソースネクスト https://www.sourcenext.com/product/pc/sok/pc_sok_001230/
PS5のすごいSoC、驚速SSDや3D音響を盛り込みながらコスト削減 | 日経クロステック（xTECH） https://xtech.nikkei.com/atcl/nxt/column/18/01468/012800007/
分数の計算の宿題がやりたくなさすぎて、分数専用計算機アプリを即興で自作したくらい数学苦手＞＜；
オレンジは激怒した。必ず、かの研究不正を正さねばならぬと決意した。オレンジには統計学がわからぬ。オレンジは、数学の落ちこぼれである。PCをいじり、数学の宿題をPC任せにして回避して来た。けれども研究不正に対しては、人一倍に敏感であった。
なんとか細胞問題の時は、世間で大騒ぎになる前に賢い人に教えてもらったけど数学なんもわからんでも理解できる話だったので「なるほど！＞＜」ってなった＞＜(？)
論文読む時、統計の部分は「(なに言ってるんだかなんもわからん＞＜；)」ので読み飛ばして「(査読つきの論文らしいしたぶん不正はないんでしょ知らんけど＞＜；)」なのでこういうの全く気づけないかも＞＜；
1人の人間が論文の不正を暴こうとしたとき何が起こったのか？ - GIGAZINE https://gigazine.net/news/20210129-report-scientific-misconduct/
どちらかと言うと主に主張したかったのは「アカン事態においては容赦なくクラッシュさせろ」ですが、まあ「アカン事態」の伝播を抑制できるようなモジュール化が可能ならそうした方が良いというのは一般論として間違ってはいない
(まあ要所要所の言葉とか概念の共有は全然できてなかった気がするけど……こればかりは言語とかランタイムとかの前提を共通化しないとこれ以上の説明が難しそうではある)
まあとりあえず途中で思っていたほど考えが大きく離れているわけではないようで安心した (さすがに本気でわかりあえない話題かと思った)
まとめると「いざとなったらクラッシュさせることができてその影響が広範囲に及ばないように、処理はきれいに適切に分割して書こうね！＞＜；」
って事かも？＞＜；
Rust で panic するときも諸々のデストラクタは一応実行されるので。
(デストラクタが勝手に実行されるとマズい場合はそれ用の機能があるので型レベルでそれを使う)
いやクラッシュは文脈の中断であって OS レベルでの即座の実行終了を意味してないんですって
でも、スレッドの内部でもダメっぽいとなったら順々に出来る限りの処理ができるように多重な構造になってるし、出来そうな終了処理は必ず試行するように書いてる＞＜
全く待たずにいきなりスレッドごとkillする事はまず無いかも＞＜
そんなんプロセスかスレッドかの違い、ほとんど同じじゃないですか (メモリ空間を共有してるくらいで) (もっとも、共有されたメモリ空間が汚染されていないことを保証してくださいという話にはなるけど)
既存のフレームワークを利用しないで書く太古の(？)GUIも(というか最低限のGUIフレームワーク自作みたいな感じの時も)、わりとそういう風に書くのが普通かも？＞＜(じゃないと操作不能になりやすいし＞＜)
フレームワークがないだけでシステムプログラミングだのベアメタルだのミッションクリティカルだの言われるのは納得いかないけど、とりあえず GUI 環境が特殊であるというのは確かっぽい
GUI フレームワーク内とかいう環境が超特殊で癖があるだけだと思いました
なのでプロセス内でも、スレッドもだけど構造自体適切に分割してって・・・・＞＜；
まるごと破棄可能な単位を用意して独立した文脈で実行するの、実質サブプロセスと同じじゃないですかそんなの。
実際 OS の GUI システムとプロセスがメッセージパッシングなり何なりで「通信」することで動作しているわけで。
結局不整合をまるごと破棄できるプロセスという単位を再度抽象化した存在としてスレッドを利用しているだけに見える
それ「スレッドをクラッシュさせてる」んじゃないんですか……？
ダメもとでもリソース解放する処理を実行するか？とかの話をとりあえず横においておくと、
つまりGUIアプリとそれ以外のアプリ(？)では、よほどの事がない限り実行を続けなければならないとされる部分の内包度？が違うってことになるのかも？＞＜；
そもそも GUI アプリケーションは暗黙に動くレイヤーがあるので前提の共有が面倒すぎる……
うん＞＜；
あと、そもそも少なくともWindowsの場合は実際の処理はよほど軽量で単純なもの以外はGUIスレッドで動かすのはお行儀悪いって事になってるし、(古典的な実装では)場合によっては処理するスレッド作り直しかも＞＜；
それ結局コアのロジックはちゃんと殺してるってことじゃないですか
ファイル読み込んだら問題なく使えたって話も、ちゃんと内部で初期化するように作ってるので(というか一旦破棄して作り直すので)、再起動した時とほぼ変わらず動かせるって事かも＞＜
オレンジのアプリの書き方だとそれが内部で分割されてて、アプリ単位よりも部分ごとに止められるってだけかも＞＜
「その部分(/アプリ)はバグってるんだから実行しない方がいい」って意味なら、アプリ終了(またはクラッシュ)させたあともう一回実行するのも同じでしょ？＞＜
私は「OS によるプロセス実行を即座にやめさせろ」と言っているのではなく「汚染されたおそれのある実行文脈を破棄しろ」と言っているわけで、文脈が破棄されたあとメッセージを表示して終了するくらいの遺言は普通にあるべきだと思います
「ダメだった」と伝えたあとユーザに何も通常の操作を許さず終了するなら、実質クラッシュじゃないですか？
CLI プログラムのクラッシュだって abort 前にメッセージを表示しますよ
いや、無事だって主張してるんじゃなくアプリは終了せずに処理は中止して「ダメだった！＞＜」ってユーザーに伝えてるんだけど・・・＞＜
何が起きたかもわからないのに「俺は無事です」と主張するプログラム、普通に信用できないんですが……
それはよくわからないけど、GUIを持つアプリはGUIが全く操作不能になることだけは絶対に避けなければならない(最悪でもいかなるときにも終了ボタンは機能しなければならない)って発想で作ってた＞＜(GUIアプリをCとかで書くのが辺り前だった頃の古い本ならわりと近いことが書いてあったかも＞＜)
そういえば Win 9x でブルースクリーンから復帰できるやつを思い出した (もちろん復帰してもファイルの保存などはできない)
あれ復帰する意味あるか？？？？？
よくわからないけど、受けとることすら不可能だったら外側で例外が最終的なキャッチ(ポケモンキャッチ？)されて「なんだかよくわからないけどこの機能はダメっぽい＞＜ 出来る限りの終了処理はしてみた＞＜(その状況のデバッグ用データ)」みたいな感じになるかも＞＜
でもアプリは終了させない＞＜(実用的な処理はなにもしてないけど生きていてGUIは使用できる＞＜)
ように作るようにしてる＞＜
https://mstdn.nere9.help/@orange_in_space/105635631053077620
> 関門の向こうから受け取ったものが「ダメっぽい＞＜」となったら
これ「ダメっぽいデータが来ることを想定している」ので「想定」の範疇じゃないですか、想定していない状況の話ではないですよね……
想定していない状況というか、想定していない状況が起きるかもしれないので、関門の向こうから受け取ったものが「ダメっぽい＞＜」となったら「これこういう風にダメっぽい＞＜」ってデバッグ情報話して、「ダメっぽいので出来ない＞＜」ってエラーだす＞＜
でも、アプリは終了させない＞＜
そのために内部データ形式に「これぶっ壊れてるフラグ」をつけたり、壊れてるときにはアクセスしてはいけない部分にアクセスすると例外吐くようにしてる＞＜
で、扱う側はチェックしたり例外受け取って「この処理出来ないっぽい＞＜」ってなる＞＜
でもアプリは終了させない＞＜
想定していない状態が発生したということは、プログラムを書くときに開発者が置いた前提と実世界が食い違っていたということで、それって既に「間違った前提で書いたコードが見掛け上正しく動いてるだけ」ですよ
なんで既に仕様通りに動いていないプログラムを見て「や、でも終了処理とリソース解放だけはちゃんと行われているはずだ！」と信用できるんですか……
発狂してる部分とそこから影響受ける部分の機能は、ちゃんと機能せずに止まるかも＞＜
それと無関係の部分が生きてるだけで＞＜
「正常ですという顔をして裏では発狂していて、ユーザの想定しない悪行を為している」とか絶対許さないマンですよ私は！
いや、でも、終了処理はきちんと行われるし、メモリリークとかリソース解放の失敗とかは基本的に起きないよ？＞＜；
文脈難しいけど、オレンジが書くアプリだとたまになる現象っぽい気がしなくもないかも？＞＜；
アプリ自体はクラッシュしないでエラーメッセージは出るけど、その後、アプリの実用上なにも出来ない状態になったり＞＜；
(アプリの正常終了とか、場合によってはファイルの保存だけ出来たり、逆に保存すら出来ないけど新たなファイルを読み込むと何事もなかったように正常動作するとか＞＜；)
で、「一部の (意味ある) 値の参照が許されなくなったけど続行してね！」というのは通常不可能なので、文脈そのものを破棄するというデフォルトは合理的でもあるわけです。
そうしないオプションが提供されているとしても、デフォルトでは文脈の破棄になるのは妥当。
「文脈を巻き込まず一部のデータだけパージすればええやん」というのはまあ理屈の上では正しいんですが、実用性は微妙だと思うんですよね。
そもそもプログラムが動作するうえで、ふつう参照する値の全てには意味があるので (意味のない参照なら消せよとなる)。
「一部の値は参照すら許されない状態になったけど続行してね！」とかかなり過酷で不自然な状況で、これを正しく実装するのって通常のエラー処理どころではないコストがかかりますよ
必ずしもそれだけの問題ではなく、たとえばポインタと型情報であるとか、配列とインデックスであるとか、そういう「組み合わせてはじめて整合性が定義される」ようなものはよくある (というか整合性はそもそも複数のデータの集合について規定されるのが普通) ので、インデックスの計算でトチって配列を変更しなかったとか、インデックスは正しく算出できたけど配列の作成でトチったとか、そういう状況ではやっぱり「汚染」は伝播している
よくわかんなくなってきたけど、だからこそ副作用をなるべく無くすように書くとかそういう話があれかも？＞＜
で、デフォルトで汚染されていると想定する連鎖が最終的にどこまで広がるかというと実行の文脈全体なので、だからこそ「起きえないことが起きたら文脈を破棄しろ」という話になっている
や、まあ特定のスナップショットについては当然これは可能なんですけど、改変される可能性のあるプログラムについてこのようにブラックリスト形式で汚染を排除していくのはデザインとして正しくないと感じます。
特定の汚染が特定の場所に伝播しないという保証があるなら、安全側に倒してデフォルトで汚染されていると想定するべき。
はい、適切に分割してください。
ただ、その「汚染範囲を小さくする」を誰が行うかの話で、「この変数は、こことここと、この部分に影響してます！」とかいうオプトインな列挙方式でうまく汚染を隔離できると思うなよという思想の話ですね
よくわかんないけど、それでいうところの汚染範囲がなるべく小さくなるようにも同一プロセス内であってもなるべく適切に分割すべきかもかも＞＜
それでも、「起きえないことが起きた」ときプログラムは最善の努力として「自分が悪影響を及ぼした範囲を更地にすることで『うっかり汚染された領域に踏み込む』ことを阻止する」責任があると考えているけど
不整合や仕様外動作に汚染された領域を破棄する手段として通常は文脈の破棄しか用意されていないという話と、仕様外動作を仕様に含んでいるかのように振る舞うことは根本的におかしいというデザインの話が混ざっていたか
ついでに言うと、モノリシックカーネル vs マイクロカーネル論争でも、マイクロカーネルが好き＞＜；(ハイブリッドも可)
信用する範囲がプロセスあるいはアプリケーション全体で一枚岩構造だと、プロセスごとコケさせるかアプリケーションごとコケさせるしかなくなるので、それをモノリシック的って言葉で説明しようとした＞＜；
もちろんプロセスより細かく分割することもできて、その場合何か起きたら Result<_, _> なりで実行時エラーとして通知することになるんですが、それって「信用していない」ということなので、信用していないコードのクラッシュに巻き込まれるべきであるという話はしてないです…… (やっぱり「クラッシュ」という言葉がアカン気がしてきた)
オレンジの説明が下手すぎただけなのか、だんだんやっと意図が通じ始めてる気がする＞＜；
の投稿
prime@mstdn.poyo.me
このアカウントは、notestockで公開設定になっていません。
の投稿
prime@mstdn.poyo.meこのアカウントは、notestockで公開設定になっていません。
だとしたらオレンジがいうようにプロセス単位だけじゃなくさらに適切に分割していってって話とも矛盾しないかも＞＜
「クラッシュ」という言い方が悪かったのかな。「実行文脈の破棄」と正確に表現すべきだったかもしれない (最も自然な選択としてクラッシュではあるけど)
そのオブジェクトの整合性が保たれているという条件が、そのオブジェクトを使う側の整合性条件に含まれていないのならば、そうです。
まあ今の技術上は、整合性の境界としてプロセスを考えるのが自然だからプロセス単位でクラッシュさせてるわけだけど
整合性がオブジェクトで閉じてるなら、オブジェクトレベルでクラッシュして、他のオブジェクトにクラッシュが波及しないみたいな仕組みでもいいわけじゃん？
ファイルの処理で行くと、例えばファイルを開いてる途中に JVM が狂ってしまったとして、コード側ではどこかが狂ったということはわかっても JVM が、というのがわかるとは限らないし、そんな状況だったら finally 節が実行されるかも怪しいですよ
さっきのこれも、つまりファイル開いていようがなんだろうが、とりあえずまるごと止めればいいというのであれば、計算機ごとシャットダウンさせればいいんじゃね？＞＜ 一部のファイルが壊れたりファイルシステムごと壊れたりするかもしれないけど、って言いたい＞＜
https://mstdn.nere9.help/@orange_in_space/105635197508593363
わりとさっぱりわからないけど、オレンジ以外の人はfinally節にファイル閉じたりリソース解放する処理を書かないのかも？＞＜
そんなわけ無いでしょ？＞＜
例えばファイルを扱う処理であれば、言うまでもなく途中で何らかの理由不明な問題が起きたらとりあえずファイルを閉じるだけはする処理は書くかも＞＜
ていうかそれ否定したら例外方式の環境のfinally節は何のためにあるんだよって事になるかも＞＜
その「理由は不明ながら」が既に破綻していて、そんなものを書けること自体がデザインとしておかしくないですか？
想定された種類の例外であればそれに対処する処理を書くべきだし、それ以外の例外であれば「理由は不明ながらもその部分は使用できなかった場合」の処理を書くべきかも＞＜
例外は「想定されたエラー (明示的に throw されるもの)」と「本当に誰も想定していなかったエラー (意図せぬ場所から propagate されてきたもの)」が混ざるので、失敗や不整合の表現としてはあまり優れた手段ではないという感覚がある
例外じゃない方式のシステムではどうなってるのか知れないけど、例外方式のシステムではそのために例外があるんでは？＞＜
で、疑う部分には例外の処理するかも＞＜
処理した上で上に伝えるのであれば更なる例外投げたりかも＞＜ 何もせずに呼び出し元にそのまま例外素通りさせるんじゃなく＞＜
プロセスという概念で誤解を与えた気はしてきた。
orange 氏の言う適切に失敗を表現する境界を与えろというのはその通りで、でもそれって単に「自分ではない他人が狂っていました」をハンドリングする手段でしかないですよね。
私が死ねと言っているのは「私自身が狂っていることが判明しました」の場合です。
そんで、依存先モジュールが「私自身が狂ってました」と自己申告してきたときユーザがその影響から隔離される手段はちゃんと存在していると考えてください
内部の分け方が不適切だからプロセス単位になっちゃってるんでしょ？＞＜ って言ってる＞＜
それをどうにか伝えようとモノリシックって言葉使った＞＜
全行全命令で検知できるようにとは言っていない＞＜
内部を適切に分割していけば、その分割単位ごとにその部分がコケた時の対処ができるでしょ？＞＜ って言いたい＞＜
なんで一ヶ所コケた時にプロセス単位でしか考えないのか？＞＜ って言ってる＞＜
https://mstdn.nere9.help/@orange_in_space/105635250963690795
この「仕様が破られたことが検知できたのでエラーを返す」という仕様は、つまり潜在的に「あらゆる関数は実装ミス由来の挙動まで想定して戻り値型を返せ」という話ですよね。
もっと言えば、いかなる関数も Result<RealReturnType, ImplementationBug> 型を返せという。
で、仕様が破られた事が検知できたんでしょ？＞＜
だったらクラッシュさせずにユーザーへのエラー表示も含めた出来る限りの終了処理をすべきでは？＞＜
アプリケーションは「画像化するモジュールが仕様通り動作する」を仕様としており、画像化するモジュールは「内部のデータ構造が有向非巡回グラフである」を仕様としており、その仕様が破られたなら、アプリケーション全体としても仕様違反じゃないですか？
それで言うと中止すべきなのは画像化する処理(のためのデータを扱う処理)であってアプリケーションそのものでは無いでしょ？＞＜
https://mstdn.nere9.help/@orange_in_space/105635197508593363
これは「不整合の漏出を防げ」案件 (<https://mastodon.cardina1.red/@lo48576/105635171147138318>) で、アプリケーションの内部的な不整合が OS の不整合にならないなら OS はクラッシュする必要がない。
たとえばアプリケーションが画像化しようとしていた有向非巡回グラフだと思っていた構造が実は巡回していた場合、復帰や修正を試みずクラッシュするべき。
でも、その構造が有向非巡回グラフであることは OS にとっての invariant ではないので OS がクラッシュする必要はない。
一方、アプリケーションが利用しようとしていた低レベル機能、たとえばメモリまわりとかドライバまわりの機能の扱いで不整合を発生させてドライバが狂った状態になったとしたら、これ以上ドライバが狂った状態でハードウェアを駆動しないよう OS がドライバを殺すなり OS ごと死ぬなりするべき。
その例で言うと、狂ってるのは42に1を足す処理の部分か計算機そのもののどちらが狂ってるわけであろうから、その部分をスキップさせてエラーを通知して出来る限り穏便に済ませる処理を書くか、計算機をシャットダウンさせる処理を書くべきかも＞＜
単位がアプリケーションというかプロセスって発想ってモノリシック的かも＞＜
「狂っていると判断することに期待する」はたぶん捉え方が逆で、「狂っていないことを期待する場所で何かがおかしかったら全てを諦める」というのが私の考えに近い表現ですね。
let a = 42;
let b = a + 1;
assert!(a == 42);
みたいなのがあったとして、この assert で a が 43 になってたらエラーとして復帰したいですか？
私はそんなのナンセンスだと思うので a == 42 でなかったらさっさとクラッシュしてほしいです
アプリケーションが自らが狂ったと判断するときに、アプリケーションがその旨悲鳴をあげて主張することができて、それを検知したOSが即座に終了処理をせずに計算機をシャットダウンさせる事が可能なシステムで、シャットダウンさせるようにすべき って主張であればオレンジは納得するかも＞＜
そんな環境使いたくないけど＞＜
オレンジ的に言いたいのは、なんで狂人が自分が狂っていると判断することに期待するんだろうって事かも＞＜
狂人かもしれない部分と狂人か判断する部分は別物(別人)であって、その部分が不明な理由で狂っていると判断することが想定可能なのであれば、その狂った部分を回避、例えばできる限り穏便に終了処理を試みるとか、その部分無しに復帰可能であれば復帰させる処理をすべきかも＞＜
信用のないプログラムなんて書けなくて、なぜなら信用しないコードが正しく動いているか検査するコード、その検査は本当に信用できますか……という終わりのない再帰が待ち受けているとか、コンパイラがバグってて不正なコードが吐かれるケースは実際あるけどどう対処するんですかとか、証明や型を付けたとして証明器や型検査が正しく動作しているとどう保証するんですかとか、そういう問題があるから。
そういうところのレイヤーには「ある程度の信用」なしには乗ることができない
「信用を裏切られたときのことを想定してエラーハンドリングを書くべきだ」というのは定義上ナンセンスで、それって「信用」してないだけじゃないですか。
実用的なプログラムは必ずそういう「そこは信用します」というレベルを程度の差こそあれ持っていて、「そこは信用しますレベル」は invariant がどれだけあるか、どれだけ強い条件かで決まってくる。
で、その信用を裏切られたときクラッシュ以外の行為に意味がない、という話です
成功したって事は成功したかも？＞＜；
それで例えば"123"って文字列を投げて整数型の123じゃなく420とかが返ってきちゃったかどうか？ って実行時には検査しないかも＞＜
というか現実的にその整数型にパースするやつが実行時に狂ったかどうか調べるのは現実的じゃないかも＞＜
その「内部を区切ってお互いを信用しない」はモジュール間連携の話で、それは確かに私も同意なんだけど、それをどこまでやるかという話ですよね。
たとえば文字列をパースして整数にする処理が成功した後に「や、ライブラリは『文字列を整数にできた』と報告してきたけど、本当にそれって正しいのか……？」と疑いますかと
ソフトウェアがモノリシック的かどうかって事になるんだと思う＞＜
クラッシュさせるって事はある一部分に問題があった時に全体を信用しないって事になるかも＞＜ なぜかアプリケーション単位(プロセス単位)で＞＜
クラッシュさせない方の考え方は、内部を区切って行ってお互いを疑いまくり期待しないでおいて、頼んだ先がダメだったら出来る限りのこと、例えばファイルを閉じたり色々なリソースを解放したり、可能であればエラーダイアログを出したりエラーログを書き出したりとか、なるべく穏便な終了処理を試みるかも＞＜
たとえばあなたは C++ 標準ライブラリのあらゆるバグを想定して検査をかけますかと。まあ普通はかけない。
何故検査をかけないかというと、ライブラリが仕様通りに動作すると暗黙に信用していて、かつライブラリが狂っているときは自分も狂っていることになるという一連托生状態を受け入れているから。
で、通常は依存ライブラリというのは自分並に信用しているので、依存ライブラリやモジュールが狂っているのは即ち自分が狂っているのと等価に扱うべき
で、狂人に「あなたは狂人ですか？」と尋ねるのは根本的に作りがおかしくて、『わたし』の側で「こいつ狂人じゃん！」と気付くのは常に『わたし』側で実装された処理の責任
> つまり、プログラムが不整合状態になったとき、プログラムは全体として既に想定を満たさない状態で動いている可能性があり、その結果として発生する処理やデータも基本的に無意味である[6]。 その無意味な処理で無意味なデータを解釈して「復帰」しようとする行為も、当然無意味である。
他人が狂人だったらオメーが自衛しろ、自分が狂人かもしれなかったら死ね、と言っています (言葉が悪い)
微妙に納得いかない＞＜；
狂人に「狂っているか？」と聞いてまともな返事が得られると期待すべきでは無いかも＞＜
多重チェック出来るのであればすべきかも＞＜
そこまでの手間をかけられるのであれば、あるセクションが(理由を問わず)実行不可能だった場合を想定するように書く手間を惜しむのは謎かも＞＜
見分けがつかない場合もあるでしょうし、あるいは正しく設計すればそもそもそんなことが起き得ない書き方もできるでしょうね。それは言語の表現力とユーザの設計次第。
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/#additional-topics--still-wondering
端的にはコレです
> * プログラムが完全に掌握しているはずのデータが誤っていれば、 panic せよ
> * プログラムのバグが原因なら、 panic せよ
> * 環境や外部データに問題があるなら Result を返すべし
> * エンドユーザに問題があるなら Result を返すべし
> * ありえないことが起きたなら panic せよ
検出可能かというかファイル内容の不整合と見分けがつくのかが謎かも・・・＞＜
たとえばですが、
「jsonファイルがフィールド a と b を持っている」
という想定があったとして、「a や b がなかったり余計な c があったりするファイルを読んだ」は「想定可能なエラー」なんですよ。この場合クラッシュすべきでない。
で、じゃあどういう場合にクラッシュすべきかというと、
「json ファイルがフィールド a と b を持っていてそれを読んだのに、返すオブジェクトで a の値を設定し忘れた」とかそういう「デシリアライザが仕様違反を犯している場合」です。
この場合「デシリアライザが『こういうデータを読みますよ』と (仕様で暗黙に) 表明したデータ以外を返す」というのは仕様外動作なので、そこから復帰しようとすべきでない。
ファイル等の読み込みの場面は、ファイルが正しいフォーマットである事に期待する事自体が危険だと思うかも・・・＞＜
なんでファイル等の読み込みの場面でオレンジが神経質に考えるかというと、そこが型付けの場面で静的な型に収まっている世界と収まっていない世界の境界になるので、静的に型付けされていない側は徹底的に疑って期待しないかも＞＜
ファイル等の読み込みの場面は、ファイルが正しいフォーマットである事に期待する事自体が危険だと思うかも・・・＞＜
それは単に仕様の問題で、もちろん「実装のバグも仕様として想定されたエラーと見做す」という仕様にしてもいいんですよ、そのコストが本当に得られるものに釣り合うなら。
その処理を中止するのとアプリがクラッシュするのは全然違う事かも＞＜(UNIX文化圏では同じになっちゃうのかもしれないけど)
オレンジ的には不整合を見つけた場合にはユーザーに知らせるべきではある一方でクラッシュするべきでは無いと考えるかも＞＜
たぶんそのアプリの実行してる時間の差で意識が違うんだと思う＞＜
CLI中心の人にとってはUNIX哲学の通りひとつの事しかさせないのでクラッシュ自体を重大とは捉えないかも＞＜
GUI中心の発想や失敗したら人が死ぬ分野の発想では、クラッシュして止まること自体を重大に考えるので、クラッシュさせるのは最後の最後の手段と考えるかも＞＜
(失敗したら人が死ぬ分野の場合は、なんらかの(例えば物理的な)更なるバックアップがない状況ではそもそもクラッシュさせるという選択肢はとらないかも＞＜)
私が言いたいのは
* I/O エラーは想定可能であり、常に復帰や適切なエラーハンドリングを試みるべき
* 逆に内部的な不整合や実装自体の仕様違反を原因とする問題に気付いたら、速やかに明示的なクラッシュをするべき
* バグは「エラー」ではない
* 不注意や人間のキャパを越えたエラー仕様で例外をキャッチし損ねてクラッシュするのは言語仕様が駄目
あたりです
「エラーが値である Rust ではメソッドチェーンや通常の関数でエラーからの復帰を書けるのに対して、例外が戻り値型と別の存在になっている言語では構文レベルで特殊な扱いが必要になる」というエラーハンドリングの言語由来の複雑性の違いを例示したかったやつです
これ <https://mastodon.cardina1.red/@lo48576/105634679893487496> のことを言ってるのなら、これはマジで単なる例で、 <https://mastodon.cardina1.red/@lo48576/105634688953669899> と対比しただけです (I/O エラーを問答無用で無視する実装が正しいかは別の問題)
「ネットワーク越しに不正なデータが来た」は「予期した形式でないことを検出した」に入るべきで (つまり「不正なデータをロード時に検査するべき」を含意する)、その場合クラッシュするのはおかしい
これは単に語法の問題で、
「ローレベル I/O の失敗でクラッシュすべきでない」
「データを読もうとして予期した形式でないことを検出したときクラッシュすべきでない」
「デシリアライザが仕様と食い違うデータを正常だと認識して読んでしまうのはユーザに責任のない実装のバグであり、速やかにクラッシュすべき」
あたりです (全部両立する)
想定外の状況ではクラッシュするけどIO関連のエラーの場合にはサイレントにデフォルト値を読むって奇妙すぎる実装では？＞＜
もし、例えば設定ファイルかなんかでファイルが作られていない状況のみを想定してるとしたら、しっかりあらかじめファイルの存在を確認すべきであるし、手抜きせず『設定ファイルが無い例外』を別に定義してそれを投げるべきでは？＞＜
や、言い方が悪かったかもしれないけど私はクラッシュするべきでないとは最初から主張してないんです、過去こんな記事も書いたように……
Panic を恐れるべからず - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/
それはユーザに責任のないバグで invariant の破壊なのでさっさとクラッシュするべき、むしろその場合は逆に復帰を試みるべきでない
そもそもload_fooが成功しちゃってなおかつ必要なデータがjsonファイルに記述されていなかった場合、または必要な項目が記述されていなかった場合に例外を吐くようにload_fooが書かれていた場合どうするのか謎＞＜
例外握りつぶしまくり書けばよいと言いたいんじゃなく、もっとちゃんと安全優先に書く方がよくね？＞＜
って言いたい＞＜
https://mstdn.nere9.help/@orange_in_space/105634818389694192
jsonにあるデータを読みなおかつデフォルト値があるようなものであれば、ファイルシステムのエラーと、jsonとして読めるか？のエラーと、jsonの中のデータとアプリ側が想定する型等と不整合があるか無いか？ の3つかも？＞＜
その上で、読めなければ握りつぶしてデフォルト値で済ませられる程度のものであれば、例で言う所のjsonのファイル名渡してる関数にデフォルト値を渡したり、先にデフォルト値を書いておいてその関数内で例外全て握りつぶせばよくね？＞＜
いやべつに low-level I/O error と invalid data を区別してもしなくてもいいんですが (それはエラー型の設計次第)、区別したところで catch すべき例外が2種類に増えるだけで話の本質にはあまり影響しないので
なんでIO関連のエラーとファイルの中身が想定外になっている事への対処がまぜこぜっぽい話になってるのか謎・・・＞＜
オレンジが書く場合はまずデフォルト値で初期化してからそこに上書きでファイルから読んだ情報を書いていくようにするかも＞＜
ここで
v = null;
if(auto w = load_foo("foo.json")) {
v = w;
} else {
v = default_foo();
}
みたいなのとか
v = null;
try {
v = load_foo("foo.json");
} catch (IoException e) {
v = Foo.default();
}
みたいな書き方をしないといけないの、そりゃプログラマが雑にエラーを扱おうとするのも致し方なしみたいな感じになってくるし、それって言語側が「正しいことを書きやすく、正しくないことを書きづらく」のデザインに失敗しているというだけの話なのではと
デコードしてしっかり型つけして読み込む(？)って話なのか、読み込み時のIOのエラーの話なのかさっぱりわからない・・・・＞＜
そもそも、実行時に何らかのファイル等のデータをデコードする最中に記述されているデータの不整合を見つけた場面にでは、そのシステム標準の例外のシステム等を頼るべきでは無い気がする派＞＜
期待しないというか、ファイルは壊れてて当たり前的な＞＜
オレンジはデコーダというかパーサというか何らかのフォーマットな文字列でデータを読み書きするやつを作る時には、
既知の項目のはデコードするけど記述が無ければ無いとする(必ずあるとは期待しない)、未知の項目は読み飛ばして例外は出さず、未知のデータがあったという情報のみ残す(単にスルーの場合もある)、
ってしてるので実行時に例外だしてコケる事まず無いかも＞＜
たとえば Rust で「load_foo("foo.json") が失敗したらデフォルトの値とする」とかだと
load_foo("foo.json").unwrap_or(Default::default)
みたいな感じでごく普通のメソッド呼び出しで済むので、例外が伝播されるとか catch すると実行が分岐して代入文が2つに増えるとかそういうのがないんですよね。欲しい挙動を書くだけという……
ほのぼの動物ニュース＞＜(バランス＞＜；)
"食事中に突然フリーズ ムササビくんに何があった？(2021年1月28日)" を YouTube で見る https://youtu.be/wduRsozqj0I
文字列でどうにかするのはアレなので・・・って内容かと思って読んだ＞＜；(英語力ヤバイ＞＜；)
stringly typed, 文字列による型付け的お気持ちです
とりあえず "stringly typed" という概念だけ今日は覚えて帰ってもらいましょ
Stringly Typed
https://wiki.c2.com/?StringlyTyped
これはダサいマジレスなんですが、下を見るとキリがないので下を見て安心するのはやめた方がいいと思う……
まあ †ビジネス† の世界では実行時の誤りの発覚がないことよりも差分の小ささの方が正義なのかもしれないが……それは私の知ったことではないし私の関わりたくない領域の話なので
動的型つけ環境の「変更に強い(変更した結果何が起きるかわからない)」と同じかも？＞＜；
正しくない指標を用いて開発や成果物を改善しようとすると何が起きるかの一例ですね
ところでこれはエアリプだけど、型などでガッチリ仕様を表現せず文字列でデータを表現して持ち回る理由としては、「文字列なら enum variant の追加等と違って型そのものやその利用箇所への影響が少ない (≒コード変更なしでコンパイルが通る) ので、見掛け上の変更と影響範囲を小さくできる」などがあります。
もちろん正しく動くとは言ってない。
こういうの見ると、他人に見せて恥ずかしくないコードの世間一般の基準みたいなのが謎になる＞＜；
(オレンジは「恥ずかしくて出せない＞＜；」ってコードたくさんある＞＜)
ていうかなんで文字列で処理してるんだろ？＞＜；(このコード書いた人だけじゃなくこの周辺を設計した人自体ヤバくね？＞＜；)
自信ついた＞＜；
オレンジは某銀行の(底辺な？)コードよりはましなコード書けるっぽい＞＜；
https://mstdn.nere9.help/@orange_in_space/105634419168779712
すごい機関のコードとか「きっとすごい感じに書いてあるんだろうな＞＜」と思って読むとわりと普通にそこら辺にあるOSSなコードとどっこいどっこいだったりして、なんか自信つく感が＞＜；
なんかまた不穏？＞＜； って思ったけど、そうじゃなくお仕事のコードを全部githubに間違って公開した人が居たって話っぽい？＞＜
これ＞＜
魚ギョッと釣りグミ｜発売日：2020年3月16日｜バンダイ キャンディ公式サイト https://www.bandai.co.jp/candy/products/2020/4549660424024000.html
型抜きで思い出したけど、型抜き的なゲーム性があるお魚のグミ(名前忘れた)、あれも超おいしい＞＜
型抜きむしろ型抜きせずに食べる用ロングスティック版とか出してほしい＞＜；
マジか…
祭りの「型抜き」、消滅の危機 家庭用でなんとかカバー（朝日新聞デジタル） - Yahoo!ニュース
https://news.yahoo.co.jp/articles/296e46270563ffb94ae50d9f137885cbec4f490e
Java版ならちょっと離れればドラウンドもデスポーンするけど、統合版は家の近所の水溜まりにドラウンドがどんどん貯まってってドラウンドの声が轟音のようになったりもする＞＜；
統合版の一番怖い所は、モンスターがデスポーンしにくい仕様で、ドラウンド(水中ゾンビ)が湧きやすくて、しかもよくわからない落とし穴のような深い水溜まり地形が多く生成されるので、その水溜まりに落ちたらドラウンドが10匹くらい居て死亡ってパターンが多いことかも＞＜；
統合版(＝Java版以外の大半)、わりと細かい挙動が違うので、わりとノウハウが違う＞＜
ejocraftの現行のワールド、ずっとログインしてないけどどこに何があってどう道が繋がってるかほとんど覚えてる＞＜
前のワールドもかなり覚えてる＞＜；
