为什么我们不使用集中式函数数据库而不是实际的包/库概念？我可以看到很多优点。
更容易成长（任何人都可以发送他的小功能，因为选择维持大的必要工作
可分析。统计和图论工具可用于分析和分类数据库。
终极生产力工具。假设您的任务是将文件夹中的所有图像转换为黑白图像。您可以谷歌搜索和安装您的语言的图像处理和操作包，然后研究然后搜索正确的功能。整个过程可能需要一天时间。或者您可以在所述全局数据库中搜索“在文件夹中打开图像文件”功能，“将图像转换为黑/白”功能以及“保存图像”功能，整个过程可能需要一分钟。 现在将其概括为任何编程任务，你可以弄清楚为什么我觉得这很重要。
为什么不采用这个概念？
答案 0 :(得分：4)
这是一个有趣的想法。我认为问题的关键在于：一个设计良好的库（或一组库）是 coherent ，因为它会仔细选择一小组函数，数据结构和其他约定。这是程序员理解，使用和重用它的原因。
一个庞大的函数数据库似乎试图在同样的意义上使一个不连贯的，不需要的函数可重用。但我认为问题的难点在于首先找到相关的功能：我担心这是任意技术选择（即使在中等简单的任务中固有的）的纯粹组合爆炸，这将破坏大多数直接重用的尝试（与伪代码般的灵感相反）。
获取“文件夹中的打开图像”示例查询，并考虑可能的目标函数如何：
程序员可以很容易地处理其中一些可能性（假设功能已正确记录）。一些可能是可修补的（例如，通过找到另一个函数来从提供给你可以使用的帧缓冲格式转换）。但其他人则具有重要的技术含义。交互式UI文件选择器将需要使用特定的UI框架。多语言图像加载器功能可以引入数十个图像库，并将其提交到其内存管理方案。
换句话说：“重复使用设计”几十年来一直是软件工程师的有希望的座右铭，我们的最大努力只获得了适度的成功。然而，长期的经验教会了我们在座右铭中隐含的教训：没有“设计”部分，“重用”就没有机会。