icon

排外主義を正当化するための脱中心化…

icon

極論、インスタンスの運用コストがゼロなら「追い出す」と「追い出される」の間に違いはなくない?

icon

日本が国連を脱退したのではない、日本以外を追放したのだ…

icon

個人的にザッとデータを加工するツールとしての便利さと、みんなで共有して作業する基盤、両立するのは難しいんだろうか… 個人的には、Gitみたいに分散型じゃないと、個人的な自由さと協働の両立は無理なんじゃないのかって思っているんだが

icon

チケット管理ツールを正しく使えたことがないというか、分散型チケット管理ツールが欲しいです

icon

自分一人でデータを扱っている時と比べて、他人と協働するときは既定のスキーマに従って作業する必要があるという点で不自由で、スキーマから外れて作業しようとすると途端にネゴシエーションというか、他の作業と干渉しないか怯えないといけなくなってしまう

icon

どういう粒度でデータを管理したいか、みたいなのが個人的にはすごく厳格にルールがあって、でもそれは自分の勝手なルールだから、他人に強いるわけにもいかないし、どうすればいいんだろう、みたいな

icon

実際のシステム開発では、スキーマは数学的に綺麗に構成されておらず、細かい部分の本質的でない不整合(e.g. カラム名)を人力で擦り合わせて変換する必要があり、不毛

icon

「設定より規約」って、規約によって設定を圧縮しているのであって、圧縮するとデータ容量は少なくなるが、加工しづらくなると思うんだけど

icon

Gitが画期的なのは、結局ファイルをスナップショットで管理していて、差分という圧縮されたディスク容量上は効率的だが作業上非効率な形式にいちいち変換しない点じゃん?

icon

opinionの共有のコストをすでに支払った後だったら、それでもいいんだけど、まだこれから擦り合わせないといけない状況だと身動きが取れないのは困る

icon

まあ、整った(スキーマの定まった)データだったら量が増えても機械的に処理できるから問題になりづらいけど、整ってないデータが量産されていたら最悪だし、結局はスキーマの制定≒オピニオンの共有が事前に必要なんだろうか…

icon

「データには構造があって、分解していくとプリミティブな型になる」レベルの話だったらプログラマはわかるけど、例えば代数的データ型レベルになると、個人的にはもはや当たり前の概念だが、平均的なプログラマは知らないと思うんですよ

icon

タグ付きユニオンで表現できるとはいえ、JSONもRDBも直和を持ってないからなー(認知度の低さ)

icon

型システムをあと載せするって考え方をTypeScriptが広めてくれたのはよかった

icon

プログラミングの高度な型って、データじゃなくてプログラムの振る舞いの性質に対して型を付けている部分があり、もはやデータ型ではない…

icon

「社会的弱者に寄り添うデジタル化」が正義だとして、それは社会の提供するサービスを弱者のインターフェースに合わせてマイグレーションをやっていくって話になるわけじゃないですか。そこに対して科学的・工学的にアプローチできるのか、それともただの精神論でやってくことにするのかでは、全然違う話になってきますよね

icon

多様なインターフェースにコンピューターの力で自由に変換する方法が欲しくて、それを実現するための工学が必要なのだが、現実には人間が手作業でしこしこ変換を書いていて、それが福祉だということになっている

icon

「コンパチビリディ」より「マイグレーション」と言った方が問題のより正確な理解ができる気がするし、システム更新とマイグレーションの問題は社会全体に一般化できる。

icon

いや、コンパチビリティとマイグレーションは関連はあっても別個の概念であって、あんまり一緒にしなくても、適宜使い分ければいいかな…

icon

継承とサブタイピングは別の話

icon

サブタイピングも、絶対に必要というわけではない…

icon

Haskellとかの型クラスみたいに、先に具体的な型があって、事後的にクラスがある仕組みの方が、考え方として自然な気がするんですよね… 一般的なオブジェクト指向の言語って、先に抽象クラスがあって、派生クラスの方が後にできるという順番だから、継承も問題になりがちな気がする

icon

Scala使えって話か?

icon

Scalaにはsealedクラスがあるので

icon

自身で完結した規約は派生を必要としないし、何らかの自由度が必要なのであれば、派生じゃなくてコンポジションを使えば済んでしまう

icon

ツリー型に整理してあった方が分かりやすいって人はいると思うんだけど、ツリー型の整理も結局は恣意的な整理になるんだよな…

icon

単一継承以外を認める場合の話、ツリーで整理するという話とそぐわないし…

icon

まあ概念として、継承とツリーは関係なくて、単一継承の場合はたまたま継承関係がツリーになるってだけですね…

icon

クラスの包含関係って、ツリーというかラティスじゃないの 単一継承でツリーとして表された関係は、真のクラスの包含関係を部分的にしか表現できてない…

icon

みんなツリーしか知らんだろうけど、数学にはセミラティスってハイカラな概念があるんだぜっていうことを言い出すのは、数学的には厳密でなかったとしても、天動説から地動説に移行したインパクトはあるのでは

icon

RDBって、データをリレーション(タプルのセット)に正規化して扱うけど、一般のデータをリレーションに変換する方法が自明じゃないので、辛みがある

icon

継承を使わないプログラムの設計論の話をどこに行ったら読めますか、って話なんでしょ そういうのって、リファレンスサービスに行って聞いてみたらいいんじゃないのかな

icon

「継承はなくても良い」って話をしていて、「継承があったら困る」って話をあんまりしなかったのは悪かったと思う…

icon

https://mstdn.nere9.help/@orange_in_space/107047978275054395 これ言っている意味分かったんだけど、要するにプログラムで仮にUSB1的な機能を提供するクラスがあったとして、新しくUSB2を作るとしたら、USB1を継承してUSB2を作るのが自然なんじゃないの? そうじゃないとしたらどうやるんですか? って言ってるのであって、実際のUSB規格とは関係ないんですね

Web site image
orange (@orange_in_space@mstdn.nere9.help)
icon

A2がA1に対してバックワードコンパチブルになっているからといって、A2がA1をプログラミングの技法上継承している必要性は全くないし、A2がA1の継承として実現されていたら困るケースはある(A2がA1に依存したら実装がA1とA2に分かれていて、全然集約できてないじゃん)

icon

概念上の抽象/具体の関係と、製品の互換性の関係と、両方とも継承で表現するの、紛らわしいし乱用っぽいな

icon

HTTP2も、最近になって、HTTPセマンティクスが分離定義されたのを参照するようになった。

icon

HTTP/1を継承してHTTP/2を作ることができるか? できるんだろうけど、HTTP/1はテキストプロトコルでHTTP/2はバイナリプロトコルで割と違うし、それを継承で表現する差分プログラミングは一般的にはアンチパターンとされることが多いんじゃないのかと思います。 今ではHTTPは、今では共通部分をセマンティクスとして分離し、各バージョンはセマンティクスの実装としてリファクタリングされたわけです。そういうふうに設計するのが筋だと思いますし、そういう意味では、差分プログラミングやメソッドのオーバーライドを否定しているのであって、あらゆる意味での継承を全面的に否定するわけではないです。 ↑これは回答になっていますか? orange@orange_in_space@mstdn.nere9.help

icon

https://twitter.com/olchy5/status/1445698924551962636?t=CKZEszSpCUwf79zgtnfpbQ&s=19

米国籍の真鍋氏のノーベル賞受賞よりも 化学賞受賞したBenjamin List教授が北大に在籍されていることの方が日本の科学力という意味では重要だと思う

icon

これは失礼な話なんですが、日本で活動している研究者がノーベル賞取ると頭脳流出論者が困ってしまうって思ってしまった

icon

病的なコミュ障…

icon

俺も青かったときは病的だったので冥福に文句言ってたときがある

https://mandel59.hateblo.jp/entry/20080319/1205921955

icon

マナー講師をけしかけて、冥福を失礼だってことにすれば…(邪悪)

icon

https://twitter.com/hiroko_TB/status/1446064177479520271 せいてきかたづけってのは、セックスの後の清掃のことです

icon

人間どうしのコミュニケーションはどうやったって遅いが、人間と機械のコミュニケーションは加速しやすい

という性質が原理にあって、人間どうしを直接結合せず、間に機械を挟むようにすることが業務を加速する第一歩だと思うが

人間どうしがコミュニケーションとった方が早いって思ってる人に対してどうやって説得したらいいのか (人間と機械のコミュニケーションは加速しやすいだけであって、何もしなければ人間どうしが直接コミュニケーションするより遅いってのは当然あるよ)

icon

その、対機械の業務が加速できる、というのは、最低限のプログラミングができる人間の話であって、プログラミングができなければいつまでも業務は加速できない

icon

今の日本人はほとんどがプログラミングできないから、業務を加速するという体験もない… コンピューターをプログラムできないから、習熟という、自分の脳のプログラミング機能に効率化を頼ってしまっている

icon

@lo48576 道路が舗装されて、オートマ車があるから、今は免許取れば誰でも自動車に乗れるみたいな感じになっているが、プログラミングは自動車というより鉄道で、レールが敷かれていない場所は未開拓の原野を切り開く感じだからなのかな… (最低限文字列を加工できればなんでもできるが…)

icon

運転は田舎ぐらしに必要だが、プログラミングは必要になってないから、できない

icon

プログラミングするには、最低限環境が整えられている必要があるが、誰がその環境を整備するのか。 企業は、道路を舗装するという発想がないまま、鉄道を敷設しようとする

icon

色々なSaaSを採用してみたところで、プログラミングができなければ、それは単なる電子化であって、OAでさえないと思うんですが(まあ文書の全文検索ができるだけでもマシなのか…)

icon

RPAとかDXとか色々言葉が出てきて散漫になってるが、まずOAという言葉が単なる電子化を指している状況を反省するべきなんじゃないのか

icon

歴史的には、OA化という言葉の後にIT化という言葉があるらしいが、なんというか、それを実現しないうちに次の言葉を使い潰しているだけに見える

icon

みんな、言葉が謳う理想より圧倒的につまらない段階までしか達成できないから、他よりウチはすごいぞって言うために新しい言葉コインし続けている