A340(たぶんA330も?)、インテル入ってるだったとは・・・><
かなり強い互換性を持たせてほぼ同じ事してるからコンピューターもA320からA340まではほぼ同じなのかなと思ってたけど、ハードウェアから別物だったのか・・・><(A320のセカンダリとA340のセカンダリだけは近いものなのかも?><)
A340(たぶんA330も?)、インテル入ってるだったとは・・・><
かなり強い互換性を持たせてほぼ同じ事してるからコンピューターもA320からA340まではほぼ同じなのかなと思ってたけど、ハードウェアから別物だったのか・・・><(A320のセカンダリとA340のセカンダリだけは近いものなのかも?><)
ボーイング777
AMD Am29050(Adaで開発)
エアバスA320
68010 + 80186
エアバスA340(330も?><)
80386 + 80186(アセンブリ、PL/M、Pascal、Adaで開発)
エアバスA380
Power PC(の複数の種類のチップで多重化?><)
『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
This account is not set to public on notestock.
https://mstdn.nere9.help/@orange_in_space/101266366644177728
これ、
impl Hoge {
fn hoge1(self) -> Self;
fn hoge2(&self) -> &Self;
fn hoge3(&mut self) -> &mut Self;
fn hoge4(&mut self) -> Self;
// などなど
}
のどれのつもりで言ってるのかわからないんですが (これらが区別できない言語はまず弱い)
そのえっとなんかその辺の全部の反論に対してまとめて聞き返したいけど、そこまでして
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というものが返ってくるのでは?って考えるかも><
This account is not set to public on notestock.
enumと言うか列挙型、Pascal一族でも使われまくりかも>< 部分集合型があるからさらに大活躍かも><
enum 、もっと言えば代数的データ型はもっと積極的に使われてほしいんですよね
try の結果を表明するなら Result 型を使えばいいので特に設計のうえで悩む点はないですね
うん><; オレンジもAda大好き(ほとんど使った事無いけど)ってくらいだしそう考えるし、その前の話的にはboolならって書いたじゃん?><;( https://mstdn.nere9.help/@orange_in_space/101266265618556686 )
その上で、金具さんの案はどうなのって・・・><
「成功したか失敗したか」は bool ではなく「成功したか失敗したか」型で返ってほしい
This account is not set to public on notestock.
その上で、金具さんの案だと、オレンジの例示で言うintが帰ってくるわけだよね?>< hoge.fuga()なprocedureだった物でhogeを返して欲しいって事なんだから><
https://mstdn.nere9.help/@orange_in_space/101266292721323876
これは型で表明されれば何の混乱も起きない話で、たとえば
fn TryIncrement(&mut self) -> Result<&mut Self, IncrementError>
なのか
fn TryIncrement(&self) -> Result<Self, IncrementError>
なのか、型を見れば mutability なんて自明なので
で、intにint int.TryIncrement()みたいなのがあったらとんでもなく混乱するかも><
int x=3;
int y=x.TryIncrement();
ってしたあとにxはどうなってるのかわけわからんってなるかも><(xが文字通りインクリメントされて破壊されて4になった?>< それともyに4が入るだけでxは3?>< ていうかそもそもTryIncrement()が返すのは結果なのか、それとも何らかの勝手な定義による成否の表現?><(例えば0なら成功とか))
あいまいな表現になるけど><;
オレンジ的には、その関数が示しているものをなるべく返して欲しいみたいな感覚があるかも><
例えば変な例示かもしれないけどTryIncrement()って関数があってboolが返ってくるのであれば、(不可能な場合がある状態で)インクリメントしてみて出来たかどうかを返すのかも?><(論理の正負はわからん)って解釈するかも><
戻り値のある function が参照透過性を破壊しないというお約束は、あまり当然ではない気がする
典型的には C++ における const 性なんかはそういう「オブジェクトについて、観測可能な変更が行われるか」みたいな制限された視野を提供している
本来「副作用」という巨視的すぎる視点ではなく、コードの有無が開発者の意図した結果 (特に値) を変更するか、というもっと制限された視野で考えるべき事柄のような気はする
これにはまあ同意するけど、「計算機の状態の全てが、あるオブジェクトから観測可能なわけではない」という観点もあり、つまりたとえばデバッグプリントは確かに副作用を発生させるけど、これが本当にコード上で何らかの観測可能な影響を及ぼすのか
それは慣習に過ぎないのではという感想です (もっと言えば、状態を持つ/持たないは自明ではない (特にキャッシュとかがあると))
なんでそうなるかと言うと、(計算機の)状態が「必ず変化しない」procedureなんて、中の処理が実際には空っぽとかじゃなければありえないだろうし><
例えばfugaってprocedureとint piyo(int x);ってfunctionを持つhogeがあったとする><
int a=hoge.piyo(x);
hoge.fuga();
int b=hoge.piyo(x);
ってした時に、よりaとbという結果が異なる可能性が高くなるよね?><;
より参照透過性(?)が危険にさらされる(?)場面である可能性が高くなると看做せる(?)というか・・・><(状態を持つのであれば保障は出来ないのは当然として><)
変更された結果返ってくる値が元の値のその後であるのか複製であるのか、これは単に (GC 付きの言語であれば) 元の値の参照が生存しているか否かの違い、所有権のその後の話であって、本質的に異なるものだと言えるのだろうか?
少なくともC# で、何らかの関数を実行した結果は、何らかの新たな物(結果なりリソースなり)か何らかの部分集合等であって、その名前の手続きを実行して変化した(=非破壊では無いという意味では破壊された)結果と解釈する事って少なくともオレンジは無いかも><;
関数型とかあんまり好きじゃないけど、「破壊されたその物が返ってくる」ってその逆方向に突っ走りまくりな発想では?><;
Pascal一族も別にfunctionで副作用を起こさないなんて意味は持ってないかも>< そうじゃなく、procedureって必ず・・・副作用?><; なんていうの?><;参照透過性の崩壊?><;
なんかそんな感じの関数型の言語が避けまくるような物を踏んづけてる場所だよって言う意味を結果的に持ってない?><;(そうじゃない場所では踏んで無いということではなく><;)
オレンジの説明が微妙におかしいのかもしれないけど、hogeに何も起きないhogeのprocedureってなに?><;
function と proceduce を使い分けるとき、 function が副作用を含まないという意味なのか何らかの値を返却するという意味なのかは人によって異なる
hoge.fuga();
hoge.piyo();
で、fuga();が本来void fuga();でPascalでprocedureとするものであるのであれば、それはhogeに「何らかの操作をする」であって、hogeを加工した複製(例えば集合であるhogeの部分集合を返す)みたいな意味は持たないよね?><
そういう意味を持つのであればそれはprocedureになるはずは無く必ずfunctionになるんだから><
ていうか、説明正しいかわかんないけど、procedureである事=副作用がある?><そのオブジェクト等の状態が変化する(させる)(可能性がある)と言うことになるんじゃないの・・・?>< そこで無加工の集合を返す(?><)みたいな表現になるのはまずくない?><
This account is not set to public on notestock.
もしかして、
hoge.fuga();
hoge.piyo();
を
hoge.fuga().piyo();
みたいに書きたいってこと?><;
というのも、たとえば
foo.set_bar(bar()).set_baz(baz());
みたいな式を書いたとき、 bar() と baz() の評価順序って定められてない気がするんですが、どうでしたっけ
This account is not set to public on notestock.
This account is not set to public on notestock.
アンダース・ヘルスバーグはDelphiでPascalの仕様どおりfunctionとprocedureをわけたの後悔してC# ではわけるのやめたってどっかで読んだかも><(都市伝説かもしれない><;)
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
Cで言う所のvoid*に相当するDelphi一族(FreePascal含む)にあるPointerって名前の標準の(?)型(型が不明なポインタを扱う時の型)、ISO 7185 :1990斜め読みしたけどそれらしき記述無いっぽいからたぶんPascalの規格上あるものじゃなくボーランド系の方言なのかな?><
Pascalだとどうなってたっけ?><と思ってぐぐったら、Delphi一族(Free Pascalとか)の場合はPointerってそのまんまの名前の標準の型になるらしいけど、Pascalそのものの仕様なのかDelphi一族の方言なのかわからない・・・><
これは差があるという話であって void * が虚無の描いてある紙に喩えられるということではないぞ
void と void* は、「虚無」と「虚無が描いてある紙」くらいの差があるよ
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
Asus T90 Chi 、
・充電ものすごくものすごく不安定
・Unifyingレシーバー差しっぱなしに出来ないしOTGケーブル経由でつなぐの邪魔すぎる(ていうか充電しながらトラボ使えない(分岐ケーブル使うとさらに充電の挙動がめちゃくちゃに))
・高解像度でWindowsデスクトップアプリをタッチパネルで操作するの不可能な上に、ヒンジの位置がおかしくてまともに操作できない
と言う3重苦で、Spotify専用機になっちゃってる><;
GPD MicroPCならそれら全部クリアしてそう><;
USB Type-Aが3口もあるからトラボのUnifyingレシーバー差しっぱなしにも出来るだろうし素晴らしい><
すごく良さそうだけどお金ない・・・><
-- ネットワーク技術者向け超小型PC「GPD MicroPC」 | スラド モバイル https://mobile.srad.jp/story/18/12/18/0655213/
頭固くて堅苦しい環境であれば、Pascalみたいな方式の方が相性がいいのかも?><(Pascalものすごく頭固い言語だと思うし><)
Pascal一族の宣言部に宣言をまとめて書く方式ってある意味やりすぎかもだけど、契約プログラミングな環境で契約がどこにでも書けるやつってそれは逆にあれだしそういう発想で見ると一ヶ所に書かれてるのも・・・あれかも?><(語彙)
ていうかPascalにどっぷり浸かった後に他の言語使うと、しばらくの間どこで宣言されてるのかが書いた人によって違う・・・><ってなってめんどく感じる><
Pascalの場合は逆に、「宣言部を見れば必ず書いてある」って考え方になるからどこに書いてあるか見つけやすい><(当たり前だけど)
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
Windows以外のGUI文化圏(Windows向けでもゲームとか)、キーボードのみで操作できる事をあんまり考えてないの、WindowsでGUIアプリ作りまくってどっぶり思想にはまってる目から見ると結構びっくり><
完全には実現できてないけど、Windowsって一応、CUIでもGUIでも全ての操作が可能で、最悪でもキーボードのみ/マウスのみどちらでもGUIを操作できるようにするって発想で作られていた・・・気がしなくは無いかも><(8以降は特に微妙だけど><;)
PowerShell のことは知らない (インドッズメインで使うことがないので)
インドッズ、なんでも GUI でやるのが無理すぎて無理 (カーネルのことは知らん)
旅客機もエアバスはA320(1984年から開発で1987年初飛行)以降は完全な一貫性を持ってるので好き><
ボーイングはシリーズ毎には互換性保つの頑張ってるし、特に737は涙ぐましい努力が見えるけどその結果今回墜落したし、ていうかシリーズごとにバラバラで一貫性がなかったのが微妙><(今は737以外は777ベースで787で改良したやつを基本に(737以外は)どうにか統一しようとしてるっぽさ?><)
土台がある程度正しくて上に載ってるものへの邪魔さえしなければ、上は自分で作ればいいわけだし><(例えばOSの土台はAPIも含めて正しいけど、シェルは酷いのなら、シェル自作すればおkとか><)
オレンジ的には、土台が正しければ、その上がある程度酷くても我慢して使う><ってポリシーなので、NTは(少なくともUNIXと比べると大幅に)正しいし、Androidもインテントでパイプ処理できる画期的かつ長期的に互換性が保てる一貫性のある思想を持ったGUI環境として気に入ったので使ってるかも><(具体的に言うとこれ読んで使いたくなった>< http://sho.tdiary.net/20100608.html#p01 )
「エンジニアはウンコを食べないといけない。」、何度読んでも感銘を受けるし、名言として語り継いでいきたい日本語
今のGoogleには、すでに総合的な技術力は無い...かもしれない。:村上福之の「ネットとケータイと俺様」:オルタナティブ・ブログ
http://blogs.itmedia.co.jp/fukuyuki/2012/03/google.html
> しかし、あれだけウンコOSでもWindowsは世界標準になった。いま、Androidは17年前のWindows95だ。ウンコでも我々はAndroidを知らないといけない。エンジニアはウンコを食べないといけない。
正しい在り方のものを待つには人間の寿命は短すぎる
理想的にはこれはそれなりの正しさがあるんだけど、実際どうなのかというと、たとえば web でなく Project Xanadu を待つ人がどれだけいたか、 Linux でなく GNU Hurd を待つ人がどれだけいたか、それが答え
今のローリングリリースで最新版以外はまともに使えない状況ってつまり、まともにモジュール化されてないゴミみたいな設計のソフトウェアが世の中に大量にあふれたままとも言えるかも><
https://mstdn.nere9.help/@orange_in_space/101263232768409527
ていうか「部品」とは、ある仕様(結果的な契約とも言えるかも><)に基づく振る舞いを行う事が出来るひとかたまりとも言えるかも><
それが破られる=仕様、振る舞いが違うものは別物だし、その仕様(契約とか規約とも言えるかも><)がころころ変わる境界は、部品としての分割面では無いとも言えるし、分割(モジュール化)されていないとも言えるし、機能毎に適切に分割されていないような設計はゴミかも><
オレンジが最近何回か話題にした、将来の互換性を考えれみたいな話も、
https://mstdn.nere9.help/users/orange_in_space/statuses/101228330322959442
欠陥を改修しても仕様変更せずに済む正しい設計をって話につながるかも><(部品に欠陥があっても、最新の改修済みの部品に完全な互換性があるなら、その部品だけ変えれば済む><)
IT界隈以外では、致命的な欠陥は「なおすもの」かも><
致命的な欠陥があっても改修も回収返金もせずに、「後継の製品ならば」なんて言って済ませるのIT界隈くらいかも><
1990年代頭まで辺りなら、特にPCも発展途上でしかたないとか言えてたけど、それからさらに何十年たって誰でも使う物になってもそのままって甘えでしかない><
不具合の改修と機能の追加の完全な分離も出来ないような、きれいに分割されていない酷い設計が受け入れられたままなのも問題の根っこのひとつかも><
ていうか、ソフトウェアのローリングリリース自体が開発者というか長年続いてるIT界隈の「セキュリティホールはあってもいい」という甘えだと思う><
一億歩譲ってセキュリティアップデートの為に限ってローリングリリースなり自動アップデートさせるのは仕方ないとしても、仕様の変更まで含めてしまうのは完全に開発者の甘えだし結果的にセキュリティ上マイナスだし、その仕組みでアップデートさせる必要があるセキュリティ問題をひとつ作ってしまった毎に、土下座して謝罪すべきかも><
自動車のリコール制度とか見倣うべき><
VSCode Insider使ってるけど、ある日の更新から「ユーザーフォルダに更新するね」って言われてexeが移動した。
ChromeとかVSCodeとか、ユーザーディレクトリにexe置く。勝手に上書きされることに気が付けないやん。