orange @[email protected]

最近のタイパタイパ言いまくる若者はものすごく嫌がりそうだけど＞＜；
でも、タイパ言うならプログラマなんぞ目指さず既製のアプリを買ってくる方が手っ取り早いわけだしなんだったら既製のAIさんに頼めばいいわけで、設計する気がないなら最初からそうすればいい＞＜

計算機や言語の仕様をいくら学んでも、設計できなければ新たなソフトウェアは作れないわけだし＞＜

「どうやったら作れるのか？」を考えて、問題を解決するのが設計で、設計こそがプログラマのお仕事なんだから、作り方をググってその通りにするんだったら設計はしてないわけで設計のトレーニングにならない＞＜
なので、完成品(コード)で評価するんじゃなく、計画や準備の方で評価すれば、インチキするのが難しくなって、ちゃんと設計のトレーニングになるかもって思った＞＜

例えば「電卓を作る」って自分で決めたとして、電卓の作り方そのものを調べちゃダメで、「どうやったら作れるのか？」「どういう機能が必要でどういう構造であれば計算できるのか？」をレポートとしてまとめる感じ＞＜

ちょっと本題と違うけど、プログラミングの自由課題(？)で、「その物ズバリの作り方は調べずにどうやったら作るか考えてまとめる(実物は作らなくてよいし、誤りが含まれていてもよい)」って課題作ったら、ただググってコピペして終わりとか他人の解答丸写しとかAIに任せてそのままみたいなことが出来なくて、いい感じになりそうだし、
学習指導要領の改善で、義務教育での科学教育とプログラミングの現在のやり方にも近くなりそう＞＜

ぐぬぬ＞＜；

二種類の住所表示体系での検索時間に関する比較実証分析 https://www.jstage.jst.go.jp/article/thagis1993/15/1/15_1_13/_article/-char/ja

"NTSB Presentation: East Palestine Hearing - Investigator in Charge Investigation Summary" を YouTube で見る https://youtu.be/ZvLLlawhDnc

そしてMD-11で失敗して傷をおったマクドネルダグラスをしめしめと吸収合併したのに、その後737MAXでちょっとMD-11みたいな失敗のもっと悪いやつ的な事をやらかした愉快なボーイングさん・・・＞＜

安定性を削って性能を上げて、欠けた安定性は電子制御で補おうとしたけどあんまりうまくいかなかった結果disられまくってるけどオレンジは好きな機体であるMD-11さん・・・＞＜

なるほど！＞＜；

x 使用変更
o 仕様変更
＞＜；

新しいものへの対応とaccountabilityを果たす事は、別に排他的なものではないし、柔軟性というものは約束を破る事では無い＞＜

たとえがよくわからないというか、戦闘機も旅客機も信頼性が必要だし、約束を守らずに使用変更しまくってたら使い物になら無い＞＜