排外主義を正当化するための脱中心化…
極論、インスタンスの運用コストがゼロなら「追い出す」と「追い出される」の間に違いはなくない？
個人的にザッとデータを加工するツールとしての便利さと、みんなで共有して作業する基盤、両立するのは難しいんだろうか… 個人的には、Gitみたいに分散型じゃないと、個人的な自由さと協働の両立は無理なんじゃないのかって思っているんだが
チケット管理ツールを正しく使えたことがないというか、分散型チケット管理ツールが欲しいです
自分一人でデータを扱っている時と比べて、他人と協働するときは既定のスキーマに従って作業する必要があるという点で不自由で、スキーマから外れて作業しようとすると途端にネゴシエーションというか、他の作業と干渉しないか怯えないといけなくなってしまう
どういう粒度でデータを管理したいか、みたいなのが個人的にはすごく厳格にルールがあって、でもそれは自分の勝手なルールだから、他人に強いるわけにもいかないし、どうすればいいんだろう、みたいな
実際のシステム開発では、スキーマは数学的に綺麗に構成されておらず、細かい部分の本質的でない不整合（e.g. カラム名）を人力で擦り合わせて変換する必要があり、不毛
「設定より規約」って、規約によって設定を圧縮しているのであって、圧縮するとデータ容量は少なくなるが、加工しづらくなると思うんだけど
Gitが画期的なのは、結局ファイルをスナップショットで管理していて、差分という圧縮されたディスク容量上は効率的だが作業上非効率な形式にいちいち変換しない点じゃん？
opinionの共有のコストをすでに支払った後だったら、それでもいいんだけど、まだこれから擦り合わせないといけない状況だと身動きが取れないのは困る
まあ、整った（スキーマの定まった）データだったら量が増えても機械的に処理できるから問題になりづらいけど、整ってないデータが量産されていたら最悪だし、結局はスキーマの制定≒オピニオンの共有が事前に必要なんだろうか…
「データには構造があって、分解していくとプリミティブな型になる」レベルの話だったらプログラマはわかるけど、例えば代数的データ型レベルになると、個人的にはもはや当たり前の概念だが、平均的なプログラマは知らないと思うんですよ
タグ付きユニオンで表現できるとはいえ、JSONもRDBも直和を持ってないからなー（認知度の低さ）
型システムをあと載せするって考え方をTypeScriptが広めてくれたのはよかった
プログラミングの高度な型って、データじゃなくてプログラムの振る舞いの性質に対して型を付けている部分があり、もはやデータ型ではない…
「社会的弱者に寄り添うデジタル化」が正義だとして、それは社会の提供するサービスを弱者のインターフェースに合わせてマイグレーションをやっていくって話になるわけじゃないですか。そこに対して科学的・工学的にアプローチできるのか、それともただの精神論でやってくことにするのかでは、全然違う話になってきますよね
多様なインターフェースにコンピューターの力で自由に変換する方法が欲しくて、それを実現するための工学が必要なのだが、現実には人間が手作業でしこしこ変換を書いていて、それが福祉だということになっている
「コンパチビリディ」より「マイグレーション」と言った方が問題のより正確な理解ができる気がするし、システム更新とマイグレーションの問題は社会全体に一般化できる。
いや、コンパチビリティとマイグレーションは関連はあっても別個の概念であって、あんまり一緒にしなくても、適宜使い分ければいいかな…
Haskellとかの型クラスみたいに、先に具体的な型があって、事後的にクラスがある仕組みの方が、考え方として自然な気がするんですよね… 一般的なオブジェクト指向の言語って、先に抽象クラスがあって、派生クラスの方が後にできるという順番だから、継承も問題になりがちな気がする
自身で完結した規約は派生を必要としないし、何らかの自由度が必要なのであれば、派生じゃなくてコンポジションを使えば済んでしまう
ツリー型に整理してあった方が分かりやすいって人はいると思うんだけど、ツリー型の整理も結局は恣意的な整理になるんだよな…
まあ概念として、継承とツリーは関係なくて、単一継承の場合はたまたま継承関係がツリーになるってだけですね…
クラスの包含関係って、ツリーというかラティスじゃないの 単一継承でツリーとして表された関係は、真のクラスの包含関係を部分的にしか表現できてない…
みんなツリーしか知らんだろうけど、数学にはセミラティスってハイカラな概念があるんだぜっていうことを言い出すのは、数学的には厳密でなかったとしても、天動説から地動説に移行したインパクトはあるのでは
RDBって、データをリレーション（タプルのセット）に正規化して扱うけど、一般のデータをリレーションに変換する方法が自明じゃないので、辛みがある
継承を使わないプログラムの設計論の話をどこに行ったら読めますか、って話なんでしょ そういうのって、リファレンスサービスに行って聞いてみたらいいんじゃないのかな
「継承はなくても良い」って話をしていて、「継承があったら困る」って話をあんまりしなかったのは悪かったと思う…
https://mstdn.nere9.help/@orange_in_space/107047978275054395 これ言っている意味分かったんだけど、要するにプログラムで仮にUSB1的な機能を提供するクラスがあったとして、新しくUSB2を作るとしたら、USB1を継承してUSB2を作るのが自然なんじゃないの？ そうじゃないとしたらどうやるんですか？ って言ってるのであって、実際のUSB規格とは関係ないんですね
A2がA1に対してバックワードコンパチブルになっているからといって、A2がA1をプログラミングの技法上継承している必要性は全くないし、A2がA1の継承として実現されていたら困るケースはある（A2がA1に依存したら実装がA1とA2に分かれていて、全然集約できてないじゃん）
概念上の抽象/具体の関係と、製品の互換性の関係と、両方とも継承で表現するの、紛らわしいし乱用っぽいな
HTTP2も、最近になって、HTTPセマンティクスが分離定義されたのを参照するようになった。
HTTP/1を継承してHTTP/2を作ることができるか？ できるんだろうけど、HTTP/1はテキストプロトコルでHTTP/2はバイナリプロトコルで割と違うし、それを継承で表現する差分プログラミングは一般的にはアンチパターンとされることが多いんじゃないのかと思います。 今ではHTTPは、今では共通部分をセマンティクスとして分離し、各バージョンはセマンティクスの実装としてリファクタリングされたわけです。そういうふうに設計するのが筋だと思いますし、そういう意味では、差分プログラミングやメソッドのオーバーライドを否定しているのであって、あらゆる意味での継承を全面的に否定するわけではないです。 ↑これは回答になっていますか？ orange@orange_in_space@mstdn.nere9.help