船名も事故の内容も酷い＞＜；
-- 2018年05月03日 不明（京都府宮津市栗田湾）プレジャーボートのーてんき乗組員及び同乗者死亡
- 概要 | 船舶 | 運輸安全委員会 https://jtsb.mlit.go.jp/jtsb/ship/detail.php?id=11025
今月分の報告書きてた＞＜
-- 運輸安全委員会 http://www.mlit.go.jp/jtsb/
これすごく好き＞＜＞＜
orange
さんがブースト
ガンジー２／映画予告編パロディ https://youtu.be/9_RhCoRzqQ4
ﾃﾞｹﾃﾞｹﾃﾞﾝｯ!ｶﾞﾝﾃﾞｨｰﾄｩｰ… がしぬほどすきなのでみなさんもみてください
電話やボイチャは非同期に通信出来ないから(緊急性がある時に限って欲しい)って話はわかるけど、それはそれとしてメールとかSMSとかLINEとか物理的郵便を送る時には予め連絡しなくていいんだろうか？＞＜(皮肉)
結果的に非互換になったのであれば、過去のバージョンは誤りであったって考えるべきでしょ？＞＜と言いたい＞＜
発端のPythonの話で言うならPython2と3に非互換があるということはPython2には誤りがあったって事になるでしょ？＞＜
Python2の仕様を考えた人は土下座しないといけないね！＞＜
さて、互換性を重視出来なかったコミュニティがうみだしたPython3の仕様を考えた人の土下座は何年後だろう？＞＜
orange
さんがブースト
そもそも(設計時点での知識で)将来に渡って使えることを考えていないはずがないのではという気持ちがある (そうでない設計は最初から持続を意図していないか、純粋にクソであるかのどちらか)
改善の余地があった＝正しくない点があった＝土下座して反省すべきだ といいたい＞＜(「次になにかをデザインする時はこんな失敗はしないぞ」とこころに言い聞かせながら＞＜)
orange
さんがブースト
まずデザインは「改善」されるものだという前提で物を話しているので (改悪されたら言語そのものがクソだということで廃れればいいと思う)
土下座要求というか、自分が仕様変更する時にはそのつもりで、もっと重要な事としては、何らかの仕様やデザイン等を決定する時には「将来もそれを使えるか？」をしっかりと考えるべきって言いたい・・・＞＜；
デザイン！＞＜＃ (＞＜；)を新しい古いでは無く、正しいか正しくないかで考えろって言うのもそういう事で、正しいかどうかで考えずに新しいかどうかで考えたら、すぐに破る約束を気軽にしまくるのと同じ事になるよって言いたい＞＜
オレンジ的には逆に古いコードが動かない環境の方が重大な問題があるって考えるけど＞＜；
毎年/毎週/毎日仕様が変わったら毎年/毎週/毎日全てのコードを更新するの？＞＜；
仕様/デザイン/挙動/そしてブランド、それらはユーザーとしてしまった約束なんだよ？＞＜
非互換を作るということは、過去に自分がしてしまった約束を反故にし、過去の自分が誤りであったと認め、そしてユーザーに土下座で謝らないといけない事態なんだよ？＞＜
orange
さんがブースト
orange
さんがブースト
非互換な変更の数だけ処理系をインストールしなきゃならないのは、ユーザの方なんですよ
orange
さんがブースト
そのそれなりの理由のある非互換な変更をガン無視してレガシーなコードでエコシステムやユーザ環境を汚染していく人が沢山いるわけで、ほんまさっさと切り捨てられてほしい
ふと思ったけど、こういう風に新バージョンで言語の互換性がなくなる時、古いバージョンのコードを新しいバージョンのコードにするコンパイラ(？ トランスレータ)も同時に開発すればいいんでは感＞＜
(出来ない(または極端にパフォーマンスが落ちる)としたら、新しい言語仕様は正しく無いとも言えそう＞＜(同一の挙動をする処理を実用的に記述する事が不可能＝汎用性に欠ける言語仕様と言えるから＞＜))
orange
さんがブースト
言語処理系がずっとアプリケーションと共に残り続ける必要があるの、実質言語処理系をバンドルしているようなものではみたいな気持ちになるし、勘弁してほしさを感じてしまう
orange
さんがブースト
コンパイラならビルドした後に削除することだってできますからね
orange
さんがブースト
だいたいそんな感じ、「処理系が無限にユーザに付き纏うのがクソ」という感じ
- ＠orange_in_space
2017年 4月に登録
