所以我们都知道,在平台上学习编程语言是提高生产力的一小部分。学习Java库比学习Java编程语言花费的时间要长得多,C#、JavaScript、Python、Ruby也是如此.等。
作为程序员,我们可以很容易地观察到,在任何编程语言中,for循环或数组都是for循环或数组。一旦你学习了这个概念,你就不需要重新学习它,确定语法是不同的,但是没有花费任何的精力去重新学习这个概念。显然,标准库的情况并非如此,这意味着我们必须重新学习如何执行常见的任务,如文件操作、与数据库对话、在我们使用的每个平台上进行联网,这是低效和痛苦的,必须有更好的出路。
W3C DOM是一个跨语言库的示例,它应该具有相同的函数名和相同的语义,而不管编程语言如何。W3C DOM很难使用,但至少一旦您在一种语言/平台中学习了它,在其他语言/平台中也是一样的。
是否有一组跨语言库定义在任何地方,用于开发人员在2011年左右会关心的最常见任务。
澄清:我对绑定到当前平台(如.NET或JVM )的API不感兴趣,因为这些API与一家公司捆绑在一起,而且在许多情况下,它们都显示了它们的年龄,如果现在重新设计它们,那么它们将更加干净/更好。另外,作为一名主要的Java开发者,看着甲骨文接管Java,苏,谷歌一直是一个真正的恐怖节目。我真的不想让我花在掌握一个平台上的时间被一个单一的实体所控制,而是成为某种开源项目,在那里最好的设计才是赢家。
澄清:我正在寻找的API是相同的,在许多不同的语言,而不是单一的语言。例如,考虑读取文本文件的内容。我得打开文件,看里面的内容,.等等,我将寻找一个API,其中函数在所有不同语言中的名称完全相同,参数相同,顺序相同,返回数据相同,错误处理语义相同。我知道不同的编程范例,所以我不介意API的OO版本,一个函数版本.等。
发布于 2012-10-22 17:02:20
一个有趣的问题..。我认为,使用多种语言绑定开发执行更专门功能的库有更大的机会(您将开始在各种web服务中看到这一点)。不幸的是,尽管开发人员努力使语言绑定尽可能自然,但提供的抽象往往相当简单,而且常常感到“陌生”。或许更好的说法是,它们往往是统一的。例如,低级别的POSIX API实际上代表了标准库的一种最低公分母,但挑战是,不同的语言(can)在追求使它们成为该语言的“自然”时,甚至对这些基本抽象都有非常不同的处理方式。另一个问题(如前几篇文章中所提到的)是,由于标准库本身的性质,必须商定标准库,而这本身就可能是极具挑战性的。不幸的是,这个过程常常导致API真正满足不了任何人。(例如.我们真的需要支持36位单词还是科普特日历?取决于你的观点。API应该是面向对象的、功能性的还是其他类似于流的东西?也取决于你的观点。我只是指出,这可能是一个比人们想象的更复杂的问题。
应该注意的是,已经为标准事物提供了更好(至少更一致)的API。Plan9就是一个例子,它是一个操作系统,在这个操作系统中,所有的东西都是文件。总的来说,评价好坏参半。
发布于 2012-03-08 07:41:08
这是个好问题。对于每个开发人员来说,这样的库都是很好的资产,但是不可能是标准的,因为标准库非常保守,理想的API需要时间才能稳定下来。在向后兼容性方面也存在一个问题,即一旦输入标准库,代码就无法更改。在Python社区中,有一个笑话说,好的模块进入标准库就死了。
这个库可以启动,但不是作为一个库,而是作为一个专注于协作过程的社区/配方站点,因为一个人要说服其他人相信所选的API是最好的并不容易。你真的必须要说服大家。
对于其他语言,我不能说,但是在Python社区中,人们担心将stdlib移出核心,以便它能够更快地发展。有一个标有PEP 413的提案,但它还不够。该计划可以是:
所以,答案是-没有这样的跨语言库。因为各方之间的沟通不足。因为没有直观的平台来做这件事。
发布于 2011-10-04 22:45:21
是的,有几个。Windows,MacOS X,Linux.:)
更严重的是,.Net和Java运行时都支持许多语言,因此如果您停留在它们支持的语言集合中,那么您可以保留库知识。
https://stackoverflow.com/questions/7654826
复制相似问题