为什么我们不使用实际的包/库概念，而是使用集中式函数数据库？我可以看到很多优点。为什么我们不使用函数数据库而不是包/库？
更容易成长（任何人都可以送他的小功能，oposed在必要的工作，以维持一个大
分析的。Statisticals和图论工具可以用来分析和分类数据库。
终极生产力工具假设您有将文件夹中的所有图像转换为黑白的任务，您可以谷歌搜索并安装您的语言的图像处理和os包，然后研究并搜索正确的功能，整个过程可能需要一天，或者你可以在所述全局数据库中搜索“打开文件夹中的图像文件”功能，“将图像转换为黑/白”功能以及“保存图像”功能，整个过程可能需要一分钟。 现在将其推广到任何编程任务，您可以找出为什么我觉得这非常重要。
为什么这个概念不被采用？
这是一个有趣的想法。我认为问题的症结在于：一个设计良好的图书馆（或一组图书馆）是连贯，因为它仔细选择了一小部分功能，数据结构和其他约定。这是让程序员理解，使用和重用它的原因。
一个庞大的函数数据库看起来像是试图使一个不连贯的，无意义的大量函数在同一意义上可重用。但我认为问题的难点在于首先找到相关功能：恐怕这是任意技术选择的纯粹组合式爆炸（即使在适度简单的任务中也是固有的），它将击败大多数直接重用的尝试（而不是像伪代码一样的灵感）。
以“在一个文件夹中打开图像”例如查询您的，并考虑如何可能的目标函数可能：
一些这些可能性可以由程序员可以容易地处理（假设功能被适当地记录）。有些可能是可修补的（例如，通过找到另一个函数来从提供给您可以使用的帧缓冲区格式进行转换）。但其他人有重量级的技术含义。交互式UI文件选择器将需要使用特定的UI框架。一个polyglot图像加载器函数可以引入数十个图像库，并提交给它的内存管理方案。换句话说：“重用设计”一直是软件工程师数十年来的希望箴言，而我们的最大努力仅仅取得了微不足道的成功。然而，长期的经验告诉我们在座右铭中隐含的教训：没有“设计”部分，“重用”就没有机会。
与包管理器有何不同？ – SLaks
不同之处在于，当您需要的只是一个小功能时，您可以添加一个大型软件包的学习方面的开销。 – MaiaVictor
也有很多小功能，你不会在大包装中找到，但是每天都是必不可少的，你最终会让自己变得很重要。例如：需要将字符串转换为混合大小写。你可以花几分钟时间对它进行编程，小时候可以搜索该函数（怀疑你会发现），或者轻松搜索函数数据库。 – MaiaVictor