#言語(仕様)の安定性、ってのはCL界隈ではかなり重視されてて、確かに発掘してきた20年前のコードがそのまま動かせるってのはとても良いことではあるし、実際運用に投入すると5年10年はあっという間に経ってしまうのでその間に言語のメジャーバージョンアップで非互換が導入されたせいで古いバージョンと並行運用するか修正を迫られるかってのは大層面倒である。
#だが殊に最近のプログラムは一つのソースツリー(+言語・OSのデフォルトの実行環境)で完結するということはほとんど無く、むしろ膨大なライブラリを利用して足りない所だけちょいと埋めるという感覚である。ということは言語がいくら安定しててもライブラリが錆びていってしまっては(新しいバージョンのライブラリで日互換性が導入されては)元の木阿弥だ。
#異なるバージョンのライブラリの並行運用、ということになると、やはりJava界隈とかのプロジェクトファイルで依存バージョンをpinしてしまって、ライブラリ提供元は全バージョンを提供しといて、必要なのをビルド時に引っ張ってこれるっていうのが現実的には最良なんだろな。ライブラリの旧バージョンが(セキュリティパッチ等で)サポートされなくなる、という件は別に考えないとならないけど。
#Clojureなど言語コアそのものもプロジェクト毎にバージョンをpinできるわけで、そうなると仕様が安定していて欲しいのは言語よりもパッケージ・ビルド管理システムってことになりそうだ。
#スクリプト言語の場合、実行時にソースを読まないとならないので、ライブラリが異なる言語バージョンを要求したらどうするか、という話はある。単に文法レベルならリーダモードで何とかできるけど、ランタイムが非互換だと困るな。
#ああ、それはJavaエコシステムでも同じか＞ランタイムの互換性
#(あれ、twitterブリッジが落ちてたかな)
Gauche > Archives > 2015/12/29