あと、UNIXの思想の「一つのことを行い、 またそれをうまくやるプログラムを書け」＝ソフトウェアが機能の単位に十分に分割されていれば、設定ファイルがプログラミング言語になっている事が必要になる場面なんて無いはず＞＜
そんなものが必要になる時点で十分にそのソフトウェアは誇大化してるのかも＞＜
(オレンジは、UNIXの思想完全には同意できないけど＞＜；)
動的型付けは逆に、あるコードの変更の影響範囲を追うことが困難になる問題があるので、「何が起こるかわからない状態で目先の事だけ考えて変更する」のであれば変更に強い＞＜
静的型付けは、静的型検査を通った段階で多くの事が決定してしまうので、コードを変更した時に、どこまで影響があるか追いやすい＞＜(追える可能性が高い＞＜(特にツリー状の価値の型システムなら理屈の上でほぼ必ず追えるかも＞＜))
コードの変更の影響範囲を把握しやすい構造と、影響範囲を見通せない代わりに個別個別の変更がなされて、見通せない部分に影響が起きてしまう危惧がある構造、どっちが変更に強い？＞＜
orange
さんがブースト
正直自分もどちらかというと正しくプログラムを書くには静的型システムの方が正しいと思っている方なんだけど、ユーザーの自由という観点を知って初めてなるほどと思った。
目の前のプログラムの挙動を自分の好きなように局所的に変更するのって、ようするに設計者の設計を破壊することだと思っていて、それでプログラムが壊れることがってもまあしゃあないという……。
正しく変更するには設計から直すのが正しいんだろうけど(そしてそれは静的型システムの方が圧倒的に有利)、まあ、状況によっては大変だろうし……。
orange
さんがブースト
これは「ソフトウェアの利用者を自由にする」というあまり知られていない動的型付きプログラミング言語の利点なのです……。
もちろん、自由には責任もセットで付いてきますが。
orange
さんがブースト
必然的に設計によって書けるプログラムの範囲を制限する静的型システムと相性が悪くなるので、GNU は Lisp が好きなんじゃないかという……。
orange
さんがブースト
GNU Guile は真の意味でのハッカーのためのツールである。
orange
さんがブースト
私は言語の表現力とか気になるタイプなので、むしろ設定言語がロジックを持てる設計はかなり慎重に導入されるべきだと思っているし、原則としてロジックを書かず静的データであるべしという思想が強め
orange
さんがブースト
設定ファイルからプログラミングする力を奪うの。これもまた一つの支配の形だと思っている。
ASN Aircraft accident Boeing 737-8HG (WL) VT-AXH Kozhikode-Calicut Airport (CCJ) https://aviation-safety.net/database/record.php?id=20200807-0
33 34 35 35 34 34 35
気象庁 | 週間天気予報： 埼玉県 https://www.jma.go.jp/jp/week/317.html
・・・＞＜
老人会＞＜
Windows Chicago (#.3866502) | ✕はなぜUIにおける「閉じる」のシンボルなのか | スラド https://srad.jp/comment/3866502
TOWNS OS 2.xの閉じるボタンは、なんか格子と言うか金網と言うかそんなデザインで左上についてた＞＜(コントロールボックスは右上＞＜(つまりWindows(95～)とは左右逆))
✕はなぜUIにおける「閉じる」のシンボルなのか | スラド IT https://it.srad.jp/story/20/08/06/1542252/
安全の綻びってそういう風に出てくるので、今回のJALのごめんなさいは、安全のための素晴らしいごめんなさいだし、将来起きたかもしれない事故を回避したかもしれないと考えるべきかも＞＜
これで整備の現場にちゃんと事故事例の教育がなされるでしょたぶん？＞＜
完全にスルーしてたら、安全教育不足のまま放置することになってた＞＜
こういうのもヒヤリハット事例＞＜
そして事故の兆候はこういうところから見えてくる＞＜
スペースシャトルが2度目の事故を起こす前、高齢のジョングレンを明らかに政治的理由(要は予算確保)でスペースシャトルにのせると決定したとき、ごく一部の関係者は、これはNASAが再び安全軽視の組織になってしまっている危険な兆候と捉え議論になった＞＜
案の定、その後事故を起こした＞＜
結果的に、アポロ1号とチャレンジャー事故の犠牲者を再び無駄死ににさせてしまった＞＜
ジョングレンを乗せる決定をした時に、組織がおかしくなって安全軽視になっているともっと重大に捉えていれば、そして見直しを行っていたら、コロンビア事故は防げていたかもしれない＞＜(これちゃんと説明しようとすると本一冊になる)
事故を教訓としないのは、事故の犠牲者を無駄死ににさせてるのと同じ＞＜
テネリフェ事故知らんかった管制官事例たぶんこれ＞＜
2008年02月16日 北海道新千歳空港Ｂ滑走路01R上
JA8904-JA8020 ﾎﾞｰｲﾝｸﾞ式747-400D型-ﾀﾞｸﾞﾗｽ式MD-90-30型 株式会社日本航空インターナショナル（両機共）
重大インシデント 使用中滑走路離陸中止
概要 | 航空 | 運輸安全委員会 https://jtsb.mlit.go.jp/jtsb/aircraft/detail.php?id=1938
テネリフェ事故知らずに航空管制やっちゃうのは問題だし、JALの技術者が123便の事故をを頭に入れず作業するのも、安全上ものすごくマズい＞＜
どこぞの管制官がニアミスな重大インシデントを起こして調査官に「テネリフェ事故は知らない」って言った事例と同じ方向の問題＞＜
安全の問題なので・・・＞＜
(悪ふざけで故意ならそれはそれで普通の不祥事だけど、でも、まぁあれかも＞＜(？)
無意識にやったのだとしたら事故の教訓が頭に入ってないってことになるので、安全上の問題になる＞＜)
- ＠orange_in_space
2017年 4月に登録
