最近のプログラミング言語1は標準ライブラリが充実していますが、標準ライブラリが使いにくいために、別のサードパーティが普及している事も多いです。私は先日あるプロジェクトであえてfaradayを避けnet/httpを使うことを選びました。私は以下のような理由から、サードパーティ・ライブラリは避けるべき(時もある)と思っています。昔話:Pythonをシェルスクリプトで書き直した「シェルスクリプトをPythonで」ではありません。若い頃あるプログラムを任された私は「RHELなら標準でPythonがインストールされている。動かさないんだから、Pythonで書いてもいいだろう。PythonはBashより可読性も高いし、クールだ!」と考え、Pythonで書いた結果、先輩にゲンコツ(の絵文字)を食らいました。いうのも、任されたプログラムが、商用パッケージのアップデート用スクリプトだったからです。複数のバージョンで動くスクリプトを書くのは注意が必要です(2.4にはwith文が無い!)。気を付けて書いたとしても、そのスクリプトが将来のバージョンでも動く保証はありません(2.5ではwithという変数名は使えない!)。シェルスクリプトはどのRHELでも同じように動作することが期待できます(少なくともPythonよりは確実性が高い)。サードパーティはコントロールできないさて、サードパーティ・ライブラリの話です。サードパーティ・ライブラリはあなたの所有物ではありません。ゆえに、ライブラリに大きな変更が加わったり、開発終了になることを止めることはできません。これが如実に現れたのが、2016年のleft-pad問題でした2。left-padというライブラリが公開停止されたことで、それを(間接的に)利用するReactやBabelなどの有名ライブラリも動作しなくなったのです。「left-padは極端な例だろう」「有名ライブラリが公開停止されることはない」と思われるでしょう。有名ライブラリもメジャーバージョンアップで後方互換性が無くなることは珍しくはありません。旧バージョンの利用者から見ると、実質的には開発終了と同じです。自分のコードを新バージョン向けに修正する(もちろん、テスト等の工数もかかる)もはやメンテされない旧バージョンを使い続ける(場合によってはフォーク版を作る)という選択に迫られます。こんなリスクを追うぐらいなら、多少不便でも標準ライブラリで書いた方が良いのではないですか?そのサードパーティ、そんなに重要?さて結局、サードパーティ・ライブラリを使うかどうかは、バージョンアップ時の書き換えにかかるコスト得られる利便性この2つを天秤にかけることになります。あなたが書いているのが「長期間使うが滅多に変更はしないコード」の場合は、「最後に触ったのが3年前だから勘所が思い出せない」「開発環境構築から始めないといけない」「保守フェーズなので工数が取れない」といったことが起きがちなので、最初に標準ライブラリと多少格闘した方が、後々のコストは安いでしょう。書き捨てスクリプトや、頻繁に手を加えるコード0なら、書き換えのコストはゼロあるいは低くなります。いったライブラリは不可欠でしょう(明らかに利便性がコストに勝ります)。導入するというなら、それはちょっと考え直した方がいいかもしれません。売りのPythonは1991年登場なので「最近」という表現はちょっと変ですが。requestStockLike6おもと@tonluqclmlエムスリーでソフトウェアエンジニアしています。仕事ではRubyもScalaもPythonもBashもなんでもやる雑食系。upLoginユーザーは見つかりませんでした。