A340（たぶんA330も？）、インテル入ってるだったとは・・・＞＜
かなり強い互換性を持たせてほぼ同じ事してるからコンピューターもA320からA340まではほぼ同じなのかなと思ってたけど、ハードウェアから別物だったのか・・・＞＜（A320のセカンダリとA340のセカンダリだけは近いものなのかも？＞＜）

『COMMON-CAUSE FAILURE MITIGATION
PRACTICES AND KNOWLEDGE GAPS』ってタイトルの謎のpdfに書いてある＞＜；（なんかシステムの多重化の話がいっぱい書いてある？＞＜）

エアバスA340のFCS、4システムで冗長化する為に、ハードウェアはプライマリが80386、セカンダリは80186、
ソフトウェアは制御システムは、プライマリがアセンブリでアセンブラ使用？で、セカンダリはハンドアセンブル？＞＜；（コードの生成が自動と手動って意味なのかな？＞＜；）
モニターシステムは、プライマリがPL/Mで書かれてて、セカンダリはPascalで書かれてる？＞＜
で、警報システムはAdaで書かれたらしい？＞＜

A340の（電子計算機と言う意味の方の）コンピューターのひとつ（？ ふたつ？＞＜）、複数のソースで、CPUが80386で、でもCPUカード（？）のアーキテクチャはVAX由来で（！？＞＜；）、その上で（カスタマイズ版？）VMSが動いているって書いてある気がする、そんなバナナみたいな情報が・・・＞＜
（ていうか386で動くVMSなんてあるの？＞＜； 開発用のエミュレータを動かしたのがVAX/VMSって事？＞＜；）
http://www.adahome.com/Ammo/Success/aerofws.html
https://sites.google.com/site/af447a330/resources/dfbw-specifics

やっぱ非破壊っぽいし納得いかない・・・＞＜
C# で55行のコード書いたよ！ブラウザ上で実行できるよ！ https://paiza.io/projects/bRZQbwWGCDjfkuWuKVheUw

https://referencesource.microsoft.com/#System.Core/Microsoft/Scripting/Utils/CollectionExtensions.cs

クエリであって、元々のデータが破壊されたりはしないでしょ？＞＜

このアカウントは、notestockで公開設定になっていません。

わりと意味がわからないけど、
hoge.fuga().piyo();
以上の何物でもないんでは？＞＜

少なくともたぶんLinqはそんな奇妙な事にはなってないよね？＞＜

そのえっとなんかその辺の全部の反論に対してまとめて聞き返したいけど、そこまでして
hoge.fuga();
hoge.piyo();
と言う2つの手続きを
hoge.fuga().piyo();
なんて書き方に出来るようにする必要があるのと言うかそれらの対策をしてもそう書けるの？＞＜

や、だから、金具さんの案ではhoge.fuga()でhogeを返すんだから型はhogeの型でしょ？＞＜；

その文脈上で、hoge.fuga()でfugaがhogeの型と同一の型で何かを返すのであれば、それはhogeは破壊されていないとオレンジは考えるかも＞＜ hogeにfugaと言う状態の変化を与えた物ではなくfugaと言う式を通した結果かもって＞＜
逆にfugaがprocedureであれば、hogeをfugaと言う手続きで何らかの変化をさせる以外の推定のしようが無いかも＞＜

意地悪な例示でTryってくっつけたけど、Tryってつけてなかったらどうなる？＞＜ってなるかも＞＜
手続きのような言葉で関数のように何かが返ってくる時にその何かは推測が難しいかも＞＜
何が返ってくるかをその関数が表していなければ、何が返ってくるのかわからないって当たり前（自己言及的で循環する）な問題があるかも＞＜
hoge.fuga()のfugaと言う4文字ににhogeそのものが返ってくるって情報はどこにあるんだろう？＞＜
fugaというものが返ってくるのでは？って考えるかも＞＜

このアカウントは、notestockで公開設定になっていません。

enumと言うか列挙型、Pascal一族でも使われまくりかも＞＜ 部分集合型があるからさらに大活躍かも＞＜

うん＞＜； オレンジもAda大好き（ほとんど使った事無いけど）ってくらいだしそう考えるし、その前の話的にはboolならって書いたじゃん？＞＜；( https://mstdn.nere9.help/@orange_in_space/101266265618556686 )
その上で、金具さんの案はどうなのって・・・＞＜

このアカウントは、notestockで公開設定になっていません。

その上で、金具さんの案だと、オレンジの例示で言うintが帰ってくるわけだよね？＞＜ hoge.fuga()なprocedureだった物でhogeを返して欲しいって事なんだから＞＜

で、intにint int.TryIncrement()みたいなのがあったらとんでもなく混乱するかも＞＜
int x=3;
int y=x.TryIncrement();
ってしたあとにxはどうなってるのかわけわからんってなるかも＞＜（xが文字通りインクリメントされて破壊されて4になった？＞＜ それともyに4が入るだけでxは3？＞＜ ていうかそもそもTryIncrement()が返すのは結果なのか、それとも何らかの勝手な定義による成否の表現？＞＜（例えば0なら成功とか））

あいまいな表現になるけど＞＜；
オレンジ的には、その関数が示しているものをなるべく返して欲しいみたいな感覚があるかも＞＜
例えば変な例示かもしれないけどTryIncrement()って関数があってboolが返ってくるのであれば、（不可能な場合がある状態で）インクリメントしてみて出来たかどうかを返すのかも？＞＜（論理の正負はわからん）って解釈するかも＞＜

なんでそうなるかと言うと、（計算機の）状態が「必ず変化しない」procedureなんて、中の処理が実際には空っぽとかじゃなければありえないだろうし＞＜

例えばfugaってprocedureとint piyo(int x);ってfunctionを持つhogeがあったとする＞＜
int a=hoge.piyo(x);
hoge.fuga();
int b=hoge.piyo(x);
ってした時に、よりaとbという結果が異なる可能性が高くなるよね？＞＜；
より参照透過性（？）が危険にさらされる（？）場面である可能性が高くなると看做せる（？）というか・・・＞＜（状態を持つのであれば保障は出来ないのは当然として＞＜）

少なくともC# で、何らかの関数を実行した結果は、何らかの新たな物（結果なりリソースなり）か何らかの部分集合等であって、その名前の手続きを実行して変化した（＝非破壊では無いという意味では破壊された）結果と解釈する事って少なくともオレンジは無いかも＞＜；
関数型とかあんまり好きじゃないけど、「破壊されたその物が返ってくる」ってその逆方向に突っ走りまくりな発想では？＞＜；

で、Linqでそんな変な場面ってあるの？＞＜；

Pascal一族も別にfunctionで副作用を起こさないなんて意味は持ってないかも＞＜ そうじゃなく、procedureって必ず・・・副作用？＞＜； なんていうの？＞＜；参照透過性の崩壊？＞＜；
なんかそんな感じの関数型の言語が避けまくるような物を踏んづけてる場所だよって言う意味を結果的に持ってない？＞＜；（そうじゃない場所では踏んで無いということではなく＞＜；）

オレンジの説明が微妙におかしいのかもしれないけど、hogeに何も起きないhogeのprocedureってなに？＞＜；

hoge.fuga();
hoge.piyo();
で、fuga();が本来void fuga();でPascalでprocedureとするものであるのであれば、それはhogeに「何らかの操作をする」であって、hogeを加工した複製（例えば集合であるhogeの部分集合を返す）みたいな意味は持たないよね？＞＜
そういう意味を持つのであればそれはprocedureになるはずは無く必ずfunctionになるんだから＞＜

ていうか、説明正しいかわかんないけど、procedureである事＝副作用がある？＞＜そのオブジェクト等の状態が変化する（させる）（可能性がある）と言うことになるんじゃないの・・・？＞＜ そこで無加工の集合を返す（？＞＜）みたいな表現になるのはまずくない？＞＜

Linqほとんどわからんだけど、Linqに手続きに相当するキーワード（？）ってあるの・・・？＞＜

？＞＜；

このアカウントは、notestockで公開設定になっていません。

もしかして、
hoge.fuga();
hoge.piyo();
を
hoge.fuga().piyo();
みたいに書きたいってこと？＞＜；

C# / Delphi人的にはそんな事して何がうれしいのかさっぱりわからない・・・＞＜

このアカウントは、notestockで公開設定になっていません。

Pascalがわりと『そのまんま書く』って文化なのも影響してそう？＞＜

このアカウントは、notestockで公開設定になっていません。

アンダース・ヘルスバーグはDelphiでPascalの仕様どおりfunctionとprocedureをわけたの後悔してC# ではわけるのやめたってどっかで読んだかも＞＜（都市伝説かもしれない＞＜；）

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Cで言う所のvoid*に相当するDelphi一族（FreePascal含む）にあるPointerって名前の標準の（？）型（型が不明なポインタを扱う時の型）、ISO 7185 :1990斜め読みしたけどそれらしき記述無いっぽいからたぶんPascalの規格上あるものじゃなくボーランド系の方言なのかな？＞＜

Pascalだとどうなってたっけ？＞＜と思ってぐぐったら、Delphi一族（Free Pascalとか）の場合はPointerってそのまんまの名前の標準の型になるらしいけど、Pascalそのものの仕様なのかDelphi一族の方言なのかわからない・・・＞＜

void*って番地かも？＞＜（？）

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Asus T90 Chi 、
・充電ものすごくものすごく不安定
・Unifyingレシーバー差しっぱなしに出来ないしOTGケーブル経由でつなぐの邪魔すぎる（ていうか充電しながらトラボ使えない（分岐ケーブル使うとさらに充電の挙動がめちゃくちゃに））
・高解像度でWindowsデスクトップアプリをタッチパネルで操作するの不可能な上に、ヒンジの位置がおかしくてまともに操作できない
と言う3重苦で、Spotify専用機になっちゃってる＞＜；
GPD MicroPCならそれら全部クリアしてそう＞＜；

USB Type-Aが3口もあるからトラボのUnifyingレシーバー差しっぱなしにも出来るだろうし素晴らしい＞＜

ストレージ128GBもあるから、どこでもプログラミング用にも良さそう＞＜

すごく良さそうだけどお金ない・・・＞＜
-- ネットワーク技術者向け超小型PC「GPD MicroPC」 | スラド モバイル https://mobile.srad.jp/story/18/12/18/0655213/

頭固くて堅苦しい環境であれば、Pascalみたいな方式の方が相性がいいのかも？＞＜（Pascalものすごく頭固い言語だと思うし＞＜）

Pascal一族の宣言部に宣言をまとめて書く方式ってある意味やりすぎかもだけど、契約プログラミングな環境で契約がどこにでも書けるやつってそれは逆にあれだしそういう発想で見ると一ヶ所に書かれてるのも・・・あれかも？＞＜（語彙）

ていうかPascalにどっぷり浸かった後に他の言語使うと、しばらくの間どこで宣言されてるのかが書いた人によって違う・・・＞＜ってなってめんどく感じる＞＜

Pascalの場合は逆に、「宣言部を見れば必ず書いてある」って考え方になるからどこに書いてあるか見つけやすい＞＜（当たり前だけど）

PascalとかPascalとかPascalのことかな？＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Windows以外のGUI文化圏（Windows向けでもゲームとか）、キーボードのみで操作できる事をあんまり考えてないの、WindowsでGUIアプリ作りまくってどっぶり思想にはまってる目から見ると結構びっくり＞＜

完全には実現できてないけど、Windowsって一応、CUIでもGUIでも全ての操作が可能で、最悪でもキーボードのみ/マウスのみどちらでもGUIを操作できるようにするって発想で作られていた・・・気がしなくは無いかも＞＜（8以降は特に微妙だけど＞＜；）

旅客機もエアバスはA320（1984年から開発で1987年初飛行）以降は完全な一貫性を持ってるので好き＞＜
ボーイングはシリーズ毎には互換性保つの頑張ってるし、特に737は涙ぐましい努力が見えるけどその結果今回墜落したし、ていうかシリーズごとにバラバラで一貫性がなかったのが微妙＞＜（今は737以外は777ベースで787で改良したやつを基本に(737以外は)どうにか統一しようとしてるっぽさ？＞＜）

土台がある程度正しくて上に載ってるものへの邪魔さえしなければ、上は自分で作ればいいわけだし＞＜（例えばOSの土台はAPIも含めて正しいけど、シェルは酷いのなら、シェル自作すればおｋとか＞＜）

オレンジ的には、土台が正しければ、その上がある程度酷くても我慢して使う＞＜ってポリシーなので、NTは（少なくともUNIXと比べると大幅に）正しいし、Androidもインテントでパイプ処理できる画期的かつ長期的に互換性が保てる一貫性のある思想を持ったGUI環境として気に入ったので使ってるかも＞＜（具体的に言うとこれ読んで使いたくなった＞＜ http://sho.tdiary.net/20100608.html#p01 ）

今のローリングリリースで最新版以外はまともに使えない状況ってつまり、まともにモジュール化されてないゴミみたいな設計のソフトウェアが世の中に大量にあふれたままとも言えるかも＞＜
https://mstdn.nere9.help/@orange_in_space/101263232768409527

ていうか「部品」とは、ある仕様（結果的な契約とも言えるかも＞＜）に基づく振る舞いを行う事が出来るひとかたまりとも言えるかも＞＜
それが破られる＝仕様、振る舞いが違うものは別物だし、その仕様（契約とか規約とも言えるかも＞＜）がころころ変わる境界は、部品としての分割面では無いとも言えるし、分割（モジュール化）されていないとも言えるし、機能毎に適切に分割されていないような設計はゴミかも＞＜

オレンジが最近何回か話題にした、将来の互換性を考えれみたいな話も、
https://mstdn.nere9.help/users/orange_in_space/statuses/101228330322959442
欠陥を改修しても仕様変更せずに済む正しい設計をって話につながるかも＞＜（部品に欠陥があっても、最新の改修済みの部品に完全な互換性があるなら、その部品だけ変えれば済む＞＜）

IT界隈以外では、致命的な欠陥は「なおすもの」かも＞＜
致命的な欠陥があっても改修も回収返金もせずに、「後継の製品ならば」なんて言って済ませるのIT界隈くらいかも＞＜
1990年代頭まで辺りなら、特にPCも発展途上でしかたないとか言えてたけど、それからさらに何十年たって誰でも使う物になってもそのままって甘えでしかない＞＜
不具合の改修と機能の追加の完全な分離も出来ないような、きれいに分割されていない酷い設計が受け入れられたままなのも問題の根っこのひとつかも＞＜

ていうか、ソフトウェアのローリングリリース自体が開発者というか長年続いてるIT界隈の「セキュリティホールはあってもいい」という甘えだと思う＞＜

一億歩譲ってセキュリティアップデートの為に限ってローリングリリースなり自動アップデートさせるのは仕方ないとしても、仕様の変更まで含めてしまうのは完全に開発者の甘えだし結果的にセキュリティ上マイナスだし、その仕組みでアップデートさせる必要があるセキュリティ問題をひとつ作ってしまった毎に、土下座して謝罪すべきかも＞＜
自動車のリコール制度とか見倣うべき＞＜