実際のパッケージ/ライブラリの概念の代わりに、一元化された機能データベースを使用しないのはなぜですか？私は多くの利点を見ることができます。
成長しやすい（大きなものを維持するために必要な作業とは対照的に、誰でも彼の小さな機能を送ることができます
分析可能。統計およびグラフ理論ツールを使用して、データベースを分析および分類できます。
究極の生産性ツール。フォルダ内のすべての画像を白黒に変換するタスクがあるとします。グーグルであなたの言語の画像操作とOSパッケージを検索してインストールし、それから勉強して適切な機能を検索することができます。プロセス全体に1日かかる場合があります。または、上記のグローバルデータベースで「フォルダ内の画像ファイルを開く」機能、「画像を白黒に変換する」機能、「画像を保存する」機能を検索すると、プロセス全体に1分かかる場合があります。これをプログラミングタスクに一般化すると、なぜこれが非常に重要であるかがわかります。
この概念が採用されないのはなぜですか？
面白いアイデアです。問題の核心はこれだと思います。適切に設計されたライブラリ（またはライブラリのセット）は、関数、データ構造、およびその他の規則の小さなセットを慎重に選択するという点で一貫性があります。これは、プログラマーがそれを理解し、使用し、再利用できるようにするものです。
大規模な関数データベースは、同じ意味で、一貫性のない、設計されていない関数の塊を再利用できるようにする試みのようです。しかし、問題の難しい部分は、そもそも関連する機能を見つけることではないと思います。直接再利用のほとんどの試みを打ち負かすのは、任意の技術的選択（適度に単純なタスクでも固有）の完全な組み合わせ爆発であると思います。 （擬似コードのようなインスピレーションとは対照的に）。
「フォルダ内の画像を開く」サンプルクエリを使用して、可能なターゲット関数がどのようになるかを検討します。
これらの可能性のいくつかは、プログラマーが簡単に処理できます（関数が適切に文書化されていると仮定します）。一部はパッチ可能である可能性があります（たとえば、提供されているフレームバッファ形式から使用可能な形式に変換する別の関数を見つけることによって）。しかし、他の人は技術的に大きな意味を持っています。インタラクティブなUIファイルチューザーでは、特定のUIフレームワークを使用する必要があります。ポリグロットイメージローダー関数は、数十のイメージライブラリを取得し、そのメモリ管理スキームにコミットできます。
別の言い方をすれば、「再利用のための設計」は何十年にもわたってソフトウェアエンジニアの希望に満ちたモットーであり、私たちの最善の努力はわずかな成功しか収めていません。しかし、長い経験から、モットーに内在する教訓が得られました。「デザイン」の部分がなければ、「再利用」はチャンスになりません。