Notices by orange (orange_in_space@mstdn.nere9.help), page 30

たとえばビットパターン混ぜ混ぜする時とかは「PatternA | PatternB」みたいに書きたいけど、条件とかの時は「条件A | 条件B & 条件C」よりも「条件A or 条件B and 条件C」みたいに予約語方式の方が目に入りやすくて見間違えにくいじゃん？＞＜

Windowsのアプリがエラー出てるかどうか判定、.NETの場合はwin32apiのIsWindowEnabled()使ってWS_DISABLED状態であるか調べれば、アプリケーションエラーのダイアログが出てるかわかるっぽい＞＜（言い方を変えると、つまり勝手にWS_DISABLEDにしてるっぽい）もっと低レベルのエラー出してシステムに怒られてる場合（たとえばメモリ保護違反とか）は、それでは検出出来ないっぽい＞＜

状況がよくわかんないけど少なくともWindowsならばプロセスとかウィンドウハンドルとかが生き残ってるか監視すればいいような・・・＞＜

スラストレバーを動かしたらオートスロットル/オートスラストが解除されるのは基本的に今の旅客機すべてそうかも？＞＜；ボーイングの場合にはレバーに何ポンドだかの力が加わると解除なのでその通りで、エアバスの場合はそもそもレバーのポジションでオートスラストのモード指定してるので、例えばレバーを一番奥に倒せば「とにかく出来る限りエンジン出力を最大にするモード」に入る＞＜(ゴーアラウンドとか緊急回避の時に一番奥に倒すだけでいいように＞＜)

これもオレンジが言ってる旅客機のコクピットのモードの問題に近いかも＞＜ユーザーが混乱しないためにモードを持つのはむしろおkで、モードが多すぎてユーザーがかえって混乱したりユーザー認識と機械側のモードの齟齬が発生したりするのは、航空事故調査とかで言われてるように危険かも＞＜

ボタンが多い方が簡単だよ方式のUIって例えばアナログモデリングシンセやハイテク旅客機のコクピット＞＜重要なパラメータは一対一でインジケータ付きスイッチやらツマミやらが用意されてる＞＜

ツマミを掴む事を要求する方式のスライドバーはオレンジも嫌いかも＞＜自分で実装する時はクリックした(というかボタンを押した)場所の値にまずなるようにしてる＞＜

オレンジ+-方式でも結構ストレス感じる＞＜；

それは「75にしたい」であって適切なパラメータを探る場面ではないでしょ？＞＜「75かな？ あ、大きすぎた65くらいか？ 今度は少なすぎた　72辺り？」みたいな無駄な事をするのはオレンジには耐えられない＞＜

例えば単純な場面でも例えば明度の調整を目視で行いたい時に、GUIであればスライダー動かすなりドラッグなりツマミ回すなり好きに実装したやり方でリアルタイムに調整できるけど、テキストベースの方式では調整する度にパラメータを書き換えないと行けないでしょ？＞＜めんどくさすぎてそんな事したくないかも＞＜

例えば画像の加工をリアルタイムにプレビューしながら行ったり、音声を解析して加工したりとかするのはGUIがないととんでもなくめんどいかも＞＜

あとWindowsとUNIXの文化の違いでオレンジ的に未だ納得できていないのが、WindowsであればGUIを持ったシステムモニタソフトウェアでリアルタイムにハードウェアリソースを監視したりネットワークアクセスを監視するのが当たり前に出来るように環境が用意されていて、オレンジも自作して自分で使ってるけど、そういうリアルタイムにシステムを監視する発想が標準ではない所が謎かも＞＜

テキストのソースコードだけでRADで数時間で作れるようなまともなGUIを作ろうとしたらそれだけで数日かかるでしょ＞＜

それってつまり普段CLIとテキストエディタで済むような事しかしてないってだけでしょ？＞＜

で、Linuxデスクトップ環境って標準(というかなんというか)で超高速でそのディストロにあわせたGUIを持った環境に対してネィティブなソフトウェアを高速で作れるRAD環境なんて用意されてないわけで、WindowsやMacと比べるとアプリ作る側と使う側の隔たりがとても大きい環境だと思うかも＞＜ソースコードが配られる文化であっても結局気軽に弄れないんじゃ使う側が作る側に行くのが大変すぎるかも＞＜

IDE無しって事はたぶんWYSIWYGなGUIエディタも避けるってことでしょ？＞＜それだと超短時間でOS標準のソフトウェアやオフィススイート程度の水準のGUIを持つソフトウェアを作るの困難じゃん？＞＜

マジでバイナリで配らずソースコードのみで配る世界になるには、それこそ十分にソフトウェアがコンパクトにならなければ無理かも＞＜(コンパイルするのにアホみたいなハードウェアリソースが必要なソフトウェアが多すぎかも＞＜)

15パズルすごく好きだけどルービックキューブは理解できなかった＞＜(たぶん脳内のデータフォーマットが2次元＞＜)

たぶん、小学校の図工の授業とか自由研究とかそういうのでまず慣れないとあれなのかも＞＜

プログラミングへの向き不向きに生まれつきの性質が強く影響しそうって意見にはすごく同意で、さらにそれだけじゃなく、なんらかのタイミングで適した考え方に変わるような経験も重要そうな気がしてる＞＜作業を設計するような場面に全く遇わずにいきなりプログラミングを学びはじめると、そういう場面への対処とプログラミングに関する知識を同時に学ぶことになって、それこそ一対一で教えてでももらわないと困難な状況に陥るのかも＞＜

半導体製造装置を作るための半導体を作るための以下略 ×数回 のプロセスルールが超荒い半導体の製造装置、 そのまま時代を遡ってIC使わずトランジスタで何とかするって出来ないんだろうか？＞＜；(超高くてデカイ？＞＜；)