Pythonも主要なユーザーが変わったよな。
例えばDjangoとかはrailsなどに対してオールインワンで持つことで一貫性を維持してたしユーティリティなどを自前で持ちpypiに挙げられるパッケージはnpmのそれに比べて粒度が大きかった。
また2.xのときはLTS的なものが長かった。
LTS的なものが長かったりすることで移行が進まなくなってしまうことの反省からわりと切り捨てて頻繁にアップデートされるようになった。
これは結局のところ壊れてどうにもならなくなるまで移行が行われないという気付きによるものだと思う（分かりやすい例として個人的にはnode-gypを挙げる）
時代が変わり機械学習がメインになれば最適化とGPU対応が入ってくるし当然下層のアーキテクチャを気にするものになるから壊れやすくなる。
利用者が研究者のプロトタイプに依存することはかつてjsでデザイナーが書いたjquery何某に依存することの類似なので壊れやすくもなる。
またFastAPIみたいなラッパー的なフレームワークを利用することが増え便利になった一方で腐敗しやすくもなった。
利用者も初学者を多く取り込んだことでとりあえず利便性に振り切るみたいな使われ方が多くされる様になった。
壊れにくさという意味ではの仕様が固定され全部自前実装みたいなタイプの方が頑健性が高いみたいなのはそうでCommon Lispとかで全部自前実装とかが強いみたいな話になるんだろうか？
依存しつつも壊れにくいという意味ではhttp://setup.pyでの拡張ライブラリや何やらのインストール時の自由度をpyproject.tomlに変えて制限するみたいな対応は効果が薄い。
壊れたときに追随しやすいメリットはある。デフォルトの対応にユースケースが載ることはあってだいたい変更が必要そう
公開したインターフェイスを壊さないみたいな話をするのだとしたらWindowsのwin32みたいに無限に互換性を気にしたメンテナンスをする必要があるけれどこれはリソースの潤沢な企業だからできることでボランティアベースの組織だと厳しそう
依存しつつも壊れにくい仕様や機能を作る事はできはして、例えばその一つが動的なものに対する静的なものや自由なものに対して制約付きなものなわけだけれど、はじめから導入されていれば変更無しでいけるものの後に加えられた導入であればその対応自体が変更を増やすものになる。
https://x.com/podhmo/status/1836710646223904859…
大規模に更新して互換性をずっと維持するという方針は止めて頻繁に小さく更新しその分互換性を維持する期間も短くするようにしたということ（ズルズルと延長するのを止めて明示的にしたという方が近いかも）,> LTL的なものが長かったりすることで移行が進まなくなってしまうことの反省からわりと切り捨てて頻繁にアップデートされるようになった。
これは結局のところ壊れてどうにもならなくなるまで移行が行われないという気付きによるものだと思う（分かりやすい例として個人的にはnode-gypを挙げる）
スクリプトを書くときも標準ライブラリだけならおそらく放置してと腐敗しにくそうではある。
一方でtyperとかを使ったら便利だけれどメンテが必要になる。
そういう意味では概念的なbattery includedを満たすためには設定ファイルでyamlも使わないほうが良いのかも（tomlはイケるようになった）。
Rustの試みというのはgoなどの標準ライブラリだけで書くというオールインワンの試みに対して依存しつつも壊れにくいを目指すみたいな試みっぽい。
そういう意味では一度アップロードされたパッケージは決して消されないとかも必須の要素ではある（消えるdockerイメージにやられるとかある）。
https://x.com/podhmo/status/1836710644122578999 のつぶやきのスレッドに対してChatGPTに章のタイトルだけを補ってもらった（スレッドそのままコピペすると段落が飛びつつ途切れ途切れの文章が連続して目が滑るということが確認されている）
もうすこしいい感じのタイトルになってきもしたけれどまぁ実用的には十分かも？