跨语言标准库？

Question

所以我们都知道，学习编程语言只是在平台上提高工作效率的一小部分。学习Java库所需的时间比学习Java编程语言要长得多，C＃，JavaScript，Python，Ruby等也是如此。

作为程序员，我们可以轻松地观察到for循环或数组是for循环或任何编程语言中的数组。一旦你学会了这个概念，你就不需要重新学习它，确保语法不同，但是花费很少的努力来重新学习这个概念。显然，标准库不是这种情况，这意味着我们必须重新学习如何执行常见任务，例如文件操作，与数据库交谈，在我们使用的每个平台上进行网络连接，这是低效且痛苦的，必须有更好的方式。

W3C DOM是一个跨语言库的示例，无论编程语言如何，它都应该具有相同的函数名和相同的语义。 W3C DOM很难使用，但至少一旦你在一种语言/平台上学习它就会在其他语言/平台上学到它。

是否有一组交叉语言库可以定义为大约2011年开发人员关心的最常见任务。

1. 文件IO操作
2. 网络
3. 流程管理
4. 数据库访问
5. 收藏集和数据结构
6. 密码学，数字签名，密码哈希
7. 其他任何有用且不涉及UI代码的内容
澄清：我对绑定到当前平台（如.NET或JVM）的API不感兴趣，因为这些API与单个公司绑定，并且在许多情况下，它们显示了它们的年龄，如果它们今天被重新设计，那么更清洁/更好。另外主要是Java开发人员看着Oracle接管Java起诉Google一直是一个真正的恐怖节目。我真的不希望我投入的时间掌握一个平台被一个实体控制，而是某种开源项目，最佳设计获胜。

澄清：我正在寻找与许多不同语言无关的API。例如，考虑读取文本文件的内容。我必须打开文件，阅读内容，...等我将寻找一个API，其中函数在所有各种语言中具有完全相同的名称，相同的参数，以相同的顺序，具有相同的返回数据，相同的错误处理语义。我知道不同的编程范例，所以我可以使用API​​的OO版本，功能版本......等等。

Answer 1

一个有趣的问题......我认为使用多种语言绑定开发执行更专业功能的库有更大的机会（并且您开始在各种Web服务中看到这一点）。不幸的是，尽管开发人员努力使语言绑定尽可能自然，但提供的抽象往往相当简单，并且常常感到“异类”。或许更好的说法是，它们往往是单一的。例如，低级别的POSIX API实际上代表了标准库的一种最低标准，但挑战在于，不同的语言（可以）在寻求使它们“自然”的过程中对这些基本抽象的处理方式大不相同对那种语言。另一个问题（在以前的帖子中提到）是，就其本质而言，必须就标准库达成一致，这本身就是极具挑战性的。不幸的是，这个过程通常会导致API真正满足任何人。 （例如......我们真的必须支持36位字或科普特日历吗？取决于你的观点.API应该是面向对象的，功能性的还是类似流的东西？还取决于你的观点。指出这可能是一个比人们想象的更复杂的问题。

应该注意的是，已经努力为标准事物提供更好的（至少更一致的）API。一个例子是Plan9，一个操作系统，其中EVERYTHING是一个文件。总体而言，评论情况参差不齐。

Answer 2

这是一个很好的问题。这样的库对于每个开发人员来说都是一个很好的资产，但它不能是标准的，因为标准库非常保守，理想的API需要时间才能解决。向后兼容性也存在问题，一旦代码进入标准库，就无法改变。在Python社区中有一个笑话，好的模块进入标准库就死了。

这个图书馆可以开始，而不是作为一个图书馆，但作为一个社区/食谱网站，将专注于协作过程，因为一个人说服所有其他人并不容易API是最好的。你真的必须convince everybody。

我不能说其他语言，但在Python社区中，人们担心将stdlib移出核心以便它可以更快地发展。有一个proposal labelled PEP 413，但这还不够。该计划可能是：

1. 定义名称空间（Python中的模块）
2. 收集实际功能使用的统计信息（静态分析+公共存储库蜘蛛）
3. 充分利用所有语言
4. 分析，辩论和投票（或者只是使用你喜欢的） - 这需要用户故事数据库，这些数据库包含常见问题，解决问题的方法以及包含摘要（CHM中的Python Cookbook曾经非常这种摘要的好例子）。数据库还有一个非常重要的功能 - 检测冲突的用例。
5. 同意许可（或者只接受公共域是唯一的复制/粘贴兼容方式）

所以，答案是 - 没有这样的跨语言库。因为各方之间的沟通不足。因为没有直观的平台来做到这一点。

Answer 3

是的，有一些。 Windows，MacOS X，Linux ...... :)

更严重的是，.Net和Java运行时都支持多种语言，所以如果你保持在他们支持的语言集中，那么你就可以保持你的图书馆知识。

Answer 4

以下事情让人想到：

• Microsoft .NET - 与Microsoft生态系统紧密相连（但记住Mono），绑定到许多语言，设计有点受Java启发。你列出的大部分内容都是。

• Qt - 在C ++中非常坚定，与其他语言绑定，不像.NET那样重量级，但在* nix和MacOS上感觉不那么陌生。数据库支持非常原始，不存在加密支持。

Answer 5

我想明显的用例是让开发人员过渡到新语言和移植代码。

OpenGL代码在某些语言中看起来非常相似，但不是全部。 DOM就是一个很好的例子。非常小的JSON解析/字符串化接口可能是最广泛移植和明确的库！

但你真正想要的是一套完整的标准跨语言API，我还没有看到。

正如马丁正确指出的那样，这种努力的范围存在问题。必须满足最低公分母意味着丢失我们所需频谱中所有语言中没有的任何语言功能。这可能意味着

• 没有第一顺序功能
• no generics / templates / polymorphism
• 需要释放（）未使用的内存
• 静态类型，强制传递引用
• 无封闭的可操作性
• 错综复杂的事件监听器
• 能够在多线程和单线程环境中运行（返回与回调）。

虽然丢失我们为其选择语言的功能可能会令人沮丧，但这样的项目仍然会带来好处。较窄的范围可能会提供更好的结果。

考虑到这样一个项目的人可能会对Haxe语言感兴趣。它已经有一个最小的标准库（和Stax），可以导出到许多不同的语言，包括C ++，Flash，PHP，Neko，Javascript以及最近的C＃和Java。 （我不知道所有语言的最终结果是否相同。）

虽然CommonJS和Narwhal是特定于语言的（Javascript），但它们可能会作为创建标准库界面的尝试而着名。

Processing已移植到几种语言，因此可能会有一些有用的库。

必须有大量特定示例，例如JSON。例如，可以从C，Python，Java和更多语言访问Fuse虚拟文件系统接口。如果有人没有尝试为Javascript语言创建2d Canvas API的实现，我会感到惊讶。

Apache已经发布了许多不同语言的同域软件，可能会产生一些类似的库。

Answer 6

有一个库可以完全按照您的说法完成。它叫做turboCommons，你可以在GitHub上找到它：

https://github.com/edertone/TurboCommons