一些语言社区（例如Ruby和Python）如何防止碎片化，而其他语言社区（例如Lisp或ML）却不能？

67

术语“ Lisp”（或“类似Lisp”）是许多不同语言（例如Common Lisp，Scheme和Arc）的保护伞。其他语言社区也有类似的碎片，例如ML。

但是，Ruby和Python都设法避免了这种命运，因为创新更多地在实现上发生（例如PyPy或YARV），而不是对语言本身进行更改。

Ruby和Python社区是否做了一些特殊的事情来防止语言碎片化？

programming-languages language-design

— 克里斯·考克
source

10

您说碎片是件坏事。

— 索尼娅2012年

21

@Sonia从市场份额的角度来看，分散通常是一场灾难。

— chrisaycock 2012年

5

语言在竞争吗？

— 巴里·布朗

32

@Sonia可能是一件坏事。例如，为Python编写的库几乎肯定不依赖于实现，而为Lisp编写的库可能无法在Scheme中使用。

— 克里斯·哈珀

2

@Barry Brown：好点！语言之间不应相互竞争。但是语言供应商确实如此，这通常会影响语言设计（不过，我不认为这是Ruby，Python，Lisp，ML的情况）。

— 乔治

77

Ruby和Python 都有仁慈的独裁者。它们是深深植根于务实关注的语言。这些可能是抑制碎片化的最重要因素。另一方面，Lisp和ML更像是出于理论目的在学术界构思的“按委员会设计”语言。

Lisp最初是由约翰·麦卡锡（John McCarthy）设计的，用于计算机程序的实用数学符号。他从未将其实现为实际的编程语言。第一个实现是由史蒂夫·罗素（Steve Russell）开发的，但他不是仁慈的独裁者。随着时间的流逝，出现了许多不同的Lisp实现。Common Lisp试图将它们标准化。

Lisp更像是语言的“家族”。ML也是如此，它遵循与Lisp类似的进化路径。

— 罗伯特·哈维
source

4

嗯，我肯定会看到同类语言社区中的独裁者地位，例如Objective-C（用于iOS应用程序）和Ada（用于国防部合同）。在这些情况下，更高的功率需要遵守，开发人员必须遵循这些准则才能出售自己的warez。但是，从没有像在C＃（。Net组件）中可能被要求的那样，我从来没有被要求使用Python（爱好者项目）进行编码。即，与C相比，我更容易逃离Python。如果没有使用它的威胁，或者您将无法实现销售，独裁者将如何束手无策？不过，这可能是一个单独的问题。

— chrisaycock 2012年

1

所谓“仁慈的独裁者”，是指所有语言的改变都必须经过一个有远见的人来保持语言的纯正。人们出于实用的原因而选择使用Python。他们喜欢这种语言，并且在其中富有成果。但是，并非所有人和他们的兄弟都可以使用它，而仍将其称为Python。

— 罗伯特·哈维

4

正如罗伯特提到的，@ HenrikHansen Haskell是一个标准。因此HUGS编译器必须与GHC兼容，因为两者都称自己为“ Haskell”。相同的基于标准的保护扩展到C和C ++，这就是为什么GCC和Visual Studio必须兼容的原因（假设不使用专有扩展名）。好奇是Lisp所发生的事情，Lisp已经有了一个标准（Common Lisp），但还有许多其他Lisps。在存在标准ML和其他ML的地方，ML也有相同的问题。

— chrisaycock 2012年

4

“ Common Lisp的开发是为了标准化在其之前的Lisp的各种变体” – en.wikipedia.org/wiki/Common_Lisp。换句话说，在制定标准之前已经存在零散的问题。

— 罗伯特·哈维

3

我什至会说ML和Lisp不是像Python和Ruby那样的语言。Lisp和ML更像是由几种不同语言实现的“概念”。

— 本杰明·B

29

一个可能的因素仅仅是年龄。Lisp和ML比Python和Ruby要老很多：

Lisp：1958年
ML：1973
Python：1991年
红宝石：1995年

Lisp和ML显然已经看到了硬件功能的巨大变化，计算机科学的更多趋势，以及越来越多的博士生正在寻找可以从事的工作。

— 卡列布
source

7

可能，但我不记得Fortran具有这种程度的分叉。（有像Fortran D这样的东西，但是大多数Fortrans都已经通过了标准化。）我想也许合并的年代可能是一个因素。

— chrisaycock'4

2

AFAIK，Fortran具有许多不兼容性，非标准扩展和不同的实现，直到标准委员会逐渐将其淘汰为止，这可能是因为它比Lisp和ML更为广泛。

— erjiang 2012年

@erjian：FORTRAN的不兼容性得到了解决，因为存在以下动机：商业用途。LISP主要用于学术界，从来没有如此奢侈。也就是说，它的使用范围不是广泛，而是用户的富裕程度。

— MSalters 2012年

2

或者，变体不称为FORTRAN。BASIC发行时，肯定看起来像是简化的FORTRAN。

— David Thornley's 2012年

1

@MSalters Common Lisp实际上是（相当成功的IMO）努力，以解决各种maclisp方言的不兼容问题，这些不兼容之处是由业务用途决定的（而且DARPA希望其资助的所有研究实验室能够更轻松地共享代码）。如今，除了方案，clojure和常见的lisp外，还没有实用的通用lisps，并且这三个是足够不同的，它们具有非常不同的社区，具有不同的文化和历史，因此不再将它们视为相同语言的方言，而不是Java和C ++。。

— 帕维尔·佩涅夫

24

它们本质上都是实现定义的语言

当很容易创建与现有代码在很大程度上兼容的语言的新实现时，黑客就是黑客，他们就会继续努力。每个人都在某个时候编写一个Lisp实现。在语言设计中，ML编译器对于研究生几乎是必不可少的-语言毕竟有很好的文献记载。

另一方面，我们有即席和实现定义的语言。或者说语言是如此复杂，以至于阻碍了产生可行的替代实现的重大障碍：

红宝石; 佩尔 python-也是实现定义的所有东西，以产生可行的替代方案
ghc haskell和erlang-定义明确，但是很难做任何与ghc（或erlang）竞争的产品，所以人们通常不会打扰

这看似不利的一面-难以产生可行替代方案的语言具有巨大的上行空间：稀缺的开发人员资源集中在一个真正的实现上。

作为历史记录，Haskell社区中的一些人积极追求合并和开发人员工作的集中，认识到开发人员社区的任何分裂都将意味着我们不会成功。GHC被选中并获得冠军。

— 唐·斯图尔特
source

2

我很想知道更多关于“积极追求的合并和集中”的信息。

— Sam Tobin-Hochstadt

碎片是自然的。如果您不计算未使用的变体（例如ChinesePython）和停滞在较早版本（例如Jython）的变体，则Python和Ruby之类的语言通常都是巧合的。这里还存在生存偏见，因为大多数带有独裁者的语言并不流行，例如Nermerle，Groovy，Beanshell，Boo，实际上可能有成千上万种。

— Vorg van Geir 2012年

1

即使到那时，Haskell仍然可以更实用地达到Python / Ruby的成熟状态。Haskell的cabal工具不是好用的工具，很容易破解：甚至Yesod也承认这一点：yesodweb.com/blog/2012/04/cabal-meta Python和Ruby在软件包管理方面要好得多。

— Ehtesh Choudhury

1

@Shurane Python和Ruby在集成之前不会进行类型检查...

— Don Stewart

2

-1：对于“ ruby； perl； python －太太实现定义了，以至于无法产生可行的替代方案” Jython，IronPython，JRuby，IronRuby，PyPy，Stackless证明您在实现方面是错误的（而这些只是主要的实现）。此外，CPython是参考实现，但不是语言定义，这是

— vartec

12

我要说的一个因素是定义平台。对于Haskell，该平台是Haskell标准和GHC（我可以想象）。对于Ruby而言，是Ruby on Rails“定义”了Ruby开发平台。对于C语言，它是Unix。

与Lisp相比，在Lisp上，没有原始的kick-ass平台来定义语言的样子。如果我没记错的话，根据型号和制造商的不同，每台Lisp机器都有细微的差别。Common Lisp由于某种原因未定义。可能是因为竞争激烈，并且不愿意迁移到另一个平台。

当然，这完全是我的猜测。这个想法来自对Harvey的回答的评论。但是，似乎定义平台有很多形状，但是共同的特性似乎是它从中获得了普及。

— 亨里克·汉森
source

我实际上很喜欢这个主意。我可以使用多种形式的Lisp，因为它们都不具有“杀手级框架”，但是如果我想使用Rails，则必须坚持使用规范的Ruby。当然，这不是唯一的答案，但我确实喜欢您的假设。

— chrisaycock'4

我会同意平台部分。如果您只有一个能够运行该语言的翻译器-则不会有太多碎片。

— c69 2012年

由于人们对某些事物（例如卫生宏）有很强的见解，因此常见的Lisp并没有在早期就对单个定义感到满意。

— 罗伯特·哈维

我既同意也不同意。我同意，因为“杀手框架”用有价值的功能修补了核心语言，促进了增长，并允许在标准规范之外进行快速创新。我不同意，因为如果框架维护者不是很谨慎，那么创新的快速增长可能会导致大量膨胀和/或渗漏的抽象，从而使框架变得不稳定。

— Evan Plaice 2012年

1

（续）理想情况下，像jQuery这样的扩展语言核心功能的框架将会消失，因为这些框架所提供的最有价值的贡献已经标准化并整合到了内核中。恕我直言，框架往往死得最快，因为随着代码库的稳定，开发人员通常倾向于减少/消除依赖性。如果语言开发人员希望保持相关性，则他们将通过适应和采用框架功能并鼓励其用户减少对第三方框架的依赖性来简化该过程。

— Evan Plaice 2012年

7

别忘了权衡驱动语言发展的文化

我还要强调一个事实，那就是在公共场所积极进行python / php的开发。您有一组人确定了任何人/所有人都可以免费获得的标准规范。

就像W3C使用HTML / CSS标准一样。您有一小群有上进心的人，他们控制着该语言要完成的工作的细节。在将所有内容发布给公众之前，所有内容都会进入明确定义的规范。

OTOH，LISP之类的语言被教授或其他个人闭门造车，他们真诚地认为他们对语言“最佳使用”的看法是正确的。因为某些实现在某些方面很出色，所以它们可能同时同时是非。虽然没有什么是最好的。

这不一定是一件坏事，因为多样性孕育了创新。像LISP这样的语言一直并且将继续是学习和研究的出色语言，因为它们突破了理解的界限。

但是，为创新创造良好环境的质量不一定对稳定有利。相反，使环境对稳定有利的品质不一定对创造力有利。

当发展基于积极的协作时，有时个人为了更大的整体利益而不得不屈服。对研究不利/对一致性有利。

事实是，我们仍然生活在编程语言开发的狂野西部。设计“理想语言”的问题是如此之大，以至于尽管做出了巨大的努力，但没人能接近解决它。

在研究/学术界，仍有很大的改进和创新空间。在商业领域，实际应用中使用的软件呈指数增长，其驱动力是简单性和一致性。

有些语言专门针对前者，有些专门针对后者。那些试图同时专注于这两个方面的人通常做得都不好而死掉。

两者都是指VB / C＃/ Java之类的整体语言。现在说还为时过早，但我想看看十年后C＃和Python的样子。按照目前的速度，C＃的功能和不一致性正在以越来越快的速度增长。即使拥有出色的文档，也很难记住该语言中包含的所有细微细节和怪癖。这对于单个开发人员来说非常好，但是一旦您招募了更多具有独特风格的开发人员，代码库中的不一致就会增加，质量会受到损害，并且没有人赢。我认为从Perl在生产环境中遇到的困难中可以学到很多东西。

— 埃文·普莱斯
source

阶梯？你是说后者吗？

— Giorgio'5

@Giorgio是的，当我拼写错误时，我会讨厌它。

— 伊万·普赖斯

2

我认为说Python和Ruby之类的语言没有零碎是不正确的。我们已经开始看到一些碎片效应。例如，Python 3并不完全与Python 2向后兼容，因此两个版本都需要维护，许多现有代码仅适用于Python2。还有一些Python衍生产品，包括PyPy。

另一个因素是语言的年龄。受到最多支离破碎的语言是较旧的语言，因此要承受发展和修订的压力。Lisp是几十年前发明的，因此有足够的时间来采纳它的一些思想并将其纳入新的语言中。C是片段化语言的另一个示例。尽管C对该语言本身只有一个真正的重大修订（从K＆R到ANSI），但有许多衍生产品，包括C ++，Not Quite C和所有其他共享类似C语法的语法。

Ruby本身是以前语言的“碎片”（如果您愿意）。由于它融合了C，Smalltalk和Perl（以及其他）的思想，因此它是目前进行碎片处理的语言。我不明白为什么我们将来可能看不到Ruby与其他语言的进一步融合。

— 巴里·布朗
source

6

-1是因为：（1）Python 3.x不是碎片。这只是语言发展的下一步。几年后，Python 2.x将被完全删除。（2）其他99％兼容的语言实现（1％是实现细节，并且大多比较晦涩），并积极拒绝参与定义语言，这并不是零碎的。（3）完全不同的语言具有某些共同点并且在某种程度上是兼容的（C ++到C），这几乎是零碎的。（4）接受来自现有语言的想法不是零散的，这是设计一种语言的唯一方法。

2

@delnan：几年后，Python 2.x将完全被删除吗？当COBOL和Fortran还在的时候，这有点愚蠢！

— 梅森惠勒

3

@MasonWheeler我在谈论发展。VCS仍将存档旧代码，非正式的二进制下载可能会持续数十年，并且有些商店可能会避免移植。但是我希望在不太遥远的一天，绝大多数Python编程都在Python 3中进行。毕竟，2.x功能的开发在不久前就停止了（除非您洗脑python-dev，否则它不会继续进行），错误修复/安全性更新不会永远持续下去，并且很大一部分库已移植到Python 3，而大多数其他库则期望（例如Djano）或无法维护。

1

@MasonWheeler哦，对于Fortran和COBOL：Fortran在2008年获得了新的标准修订版，而COBOL在2002年获得了新的标准修订版，此后又发布了一些技术报告。

@MasonWheeler您知道现代的COBOL允许进行面向对象的编程吗？

2

Lisp支离破碎，因为它是如此强大的模型，这是有史以来最令人惊奇的语言。如今，大多数语言都借用了最初在Lisp中实现的功能，因此可以说，每种语言都是这种特定碎片的一部分。例如，Smalltalk受Lisp的极大启发，而Ruby受Smalltalk的极大启发。JavaScript是Java形式的Lisp，以此类推。.它们都是相互联系的，每种语言的发明者都会从其他语言中选择自己喜欢的作品。

另一个因素是Lisp可能是最容易实现的编程概念-这就是为什么它一次又一次地完成的原因。

— 托比昂
source

1

类似Lisp的语言过于基础和理论性，无法进行重大更改。语法上的更改（我并不意味着仅更改命令的名称）就不适合它们背后的功能编程理论。

但是，存在像 lisp 这样的语言这一事实表明，无论如何，已经对lisp进行了“更改”。换句话说，有些语言是受Lisp或其背后的理论启发而创作的，并创造了一种类似的新语言。

还有许多受Python启发的语言。例如，Julia，CoffeeScript等将形成自己的对空格敏感的面向对象语言家族。

我认为，像Python这样的语言的基础知识永远不会真正改变。Python是面向对象的，因此与C ++和Java有相似之处，但它是动态的，因此也与许多脚本语言相似。

那么谁真正在乎语言呢？重要的是目的：法语与拉丁语相似，但懂法语的女孩更热;）

— 施威德
source