编程语言研究

仍然需要进行编程语言方面的研究吗？本文既涉及编程语言的主题，也涉及研究工作的性质。我最关心的是在学术界中分析这个问题，即在支持STEM学科（科学，技术，工程和数学）研究工作的学术计划和研究资助机构的期望之内。这不是唯一可能的观点，而是我在这里提出的观点。

PL是我的挚爱，我的职业生涯中有相当一部分是在那个领域。作为设计师，设计任何一种语言都从根本上引起人们的兴趣。当人们真正开始使用这些语言来创建非平凡的软件系统时，这将变得更加有趣和令人满足。作为用户，我喜欢使用以前从未使用过的编程语言，即使有问题的语言使我每隔一行就大骂一次。

但是，事实是，自从我完成博士学位以来，在90年代后期，尤其是自从我加入学术界以来，我一直很难说服自己，PL的研究是值得的。不过，我对反对它的理性辩解感到非常难过。因此，这篇文章。也许到我完成它时，我就已经解决了这个难题。

早在50年代，60年代和70年代，编程语言就已成为BigDeal，它投入大量资金，进行前期规划，并在标准化委员会上大放异彩（Ada是该模型的缩影）。在80年代，情况发生了巨大变化。从90年代开始，相当多的新语言最终都非常受欢迎，它们是由孤独的程序员设计的，其中一些是没有研究倾向的孩子，有些是业余爱好，没有任何宏伟的目标，除了使日常工作变得更容易之外或为了简单的黑客乐趣。例子：

PHP，由Rasmus Lerdorf撰写，大约于1994年，“最初用于跟踪对他的在线简历的访问，他将脚本套件命名为“个人主页工具”，更经常被称为“ PHP工具”。” [1] PHP是一个奇迹可怕的语言又如何成为第二批大量应用程序的基础！越差越好。根据一项非正式但有趣的调查，PHP现在是目前排名第四的最受欢迎的编程语言，仅次于C，Java和C ++。

Brendan Eich于1995年写的JavaScript，“另外，我必须在十天内完成，否则会发生比JS更糟糕的事情。” [2]根据同一项调查，JavaScript是最受欢迎的语言排名第五，我怀疑它的排名确实在迅速上升。目前可能排名第一。

Python，由Guido van Rossum撰写，大约在1990年，“我正在寻找一个'业余爱好'编程项目，该项目将使我在圣诞节前后的一周内保持忙碌。” [3] Python排名第六，科学计算社区广泛采用Python。

Ruby，大约在1994年由松本幸宏（Matz）Matsumoto撰写，“我想要一种脚本语言，它比Perl更强大，并且比Python更面向对象。 这就是为什么我决定设计自己的语言的原因。” [4]在该调查中排名第10。 将这种心态与较早的著名编程语言出现的上下文进行比较： Fortran，50年代，最初由IBM开发，作为其计算机业务核心业务的一部分。 科博尔（Cobol），五十年代末，由国防部发起的大型委员会从一开始就设计。 Lisp，五十年代末期，主要项目吸引了麻省理工学院的两名教授和他们的学生，其宏伟目标是为国防工作提供代数列表处理语言，这也是由国防部资助的。 C，70年代初，这是Bell Labs在Unix开发中所做的大量投资的一部分。 Smalltalk，成立于70年代初，是Xerox在“发明计算机的未来”方面所做的一笔巨额投资的一部分。

当时，开发语言处理器确实是一件很重要的事情。计算机很慢，没有很多内存，语言处理器必须用低级汇编语言编写……温和地说，这不是有人会在房间里做的事情。但是，自90年代以来，随着PC以及像C这样的低端语言的出现，开发语言处理器不再是BigDeal。因此，诸如PHP和JavaScript之类的语言。

设计新语言时有很多乐趣，但是这种乐趣并不是拥有博士学位或正在攻读博士学位的研究人员的专有权利。有了这些天有关编程语言的全部知识，任何人都可以做到。而且很多。这是第一个难点：编程语言的成功与以博士或博士后工作的形式出现之间似乎没有关联。作为一个学者，这让我很困扰。看来，科学家所具有的深刻的思想，连贯性，严谨性以及所有其他我们认为不重要的东西对于大规模采用编程语言并不重要。但是话又说回来，我不是第一个说出来的人。只是这种现象很难被消化，如果您真的掌握了它，它将产生巨大的后果。如果人们（潜在用户）不关心概念的一致性，为什么我们要继续努力实现这一目标？

公平地讲，上世纪90年代作为辅助项目而设计的某些语言，随着它们变得越来越重要，最终变得更加严格和一致，并吸引了相当多的学术关注和行业投资。例如，Netscape JavaScript黑客很快就落在Guy Steele的腿上，从而产生了ECMAScript规范。即使Python是圣诞节的嗜好，但它绝不是黑客。 Ruby是一种有趣的语言，从一开始就非常优雅。 PHP…嗯…很有趣，原因可能是错误的。但问题的核心是“正确的事情”不是目标。看来，一种满足重要实际需求的语言的可靠实现是编程语言流行的关键。但是机会主义并不是研究的本意……（或者是吗？）

公平地说，并非所有90年代及以后设计的语言都是作为附带项目开始的。例如，Java是Sun Microsystems的一项相对较大的投资。微软后来的.NET也是如此。

最后，所有这些新语言，即使是作为某人的宠物项目在一周内创建的，也都位于所有以前存在的事物的肩膀上。这引出我第二个痒：在所有现代编程语言（尤其是流行的编程语言）中，一个惊人的共性是它们中几乎没有创新！毫无例外，包括研究小组开发的语言在内，它们都感觉像是1979年编程语言中已经存在的概念的混搭，并以自己的特有语法包装。 （我撒谎：例外发生在90年代的方面和单子上）

因此，一个相关的问题是：既然自1979年以来（即30多年！）似乎没有出现太多变化，那么在编程语言上还有什么可以创新的东西吗？还是我们已经达到了该领域创新的渐近高原？

也许我已经完全离开了；也许生产创新的新软件不是[STEM]研究的目标。在这种方法下，除非有特定的目标是必要的，否则任何软件工作都不会从STEM追求中解脱出来，例如，如果您想研究遥远的星系，并且需要IT基础架构来收集数据并进行仿真（S for Science ）;或者，如果您需要一些粘合代码来将现有系统拼接在一起（对于技术，则为T）；或者，如果您需要提高已经存在的性能（工程E）；或者您正在研究某种数学计算模型，并希望以一种语言（M表示数学）的形式使您的想法变为现实。这是对软件系统的一种极端屈从的观点，这种观点将软件置于STEM的后方，并否认软件本身/由软件本身进行研究的价值存在。如果我们想自己做某事，那就……做技术的实证研究，或者成为生物学家/物理学家/化学家/数学家，或者使现有事物表现更好，或者对已经存在或由他人创造的宇宙做理论/统计模型。对？

我承认我与这个想法有失调的关系。就我个人而言，如果不创建软件，我会很高兴，但是我能够使自己的科学家既扮演一个冷漠的分析家的角色，又有时成为别人的研究项目的专家。对我来说，设计工作已经转移到休假时间，晚上和周末。除了代码本身和一些非正式的描述以外，我不会发布太多内容。但是，我讨厌这种情况。

我讨厌它，因为我很清楚软件系统是非常非常特别的东西。软件以意想不到的方式彻底改变了一切，包括我们尊敬的“硬”科学同事长期和亲近的方法和实践。在过去的60年中，信息技术的发展与我们的同事所认为的相去甚远。这样一遍又一遍，已经创建了不属于任何科学项目的软件系统，并且最终在科学中发挥了核心作用。 “计算机科学家”不应试图模仿我们同事的传统做法，而应该展示通往一种新型科学的道路-也许是这种新型科学，或者是一种或多种其他事物。我敢建议其他东西与其中装有软件的东西的设计有关。它不应该被称为科学。它有点像工程学，但不是因为我们不仅仅处理物理事物。技术也不能削减。它需要一个新名称，该名称表示“其中包含软件的事物的设计”。我会简称为Design，即使该词被滥用以致失去其含义。

然后，假设在博士工作的背景下创建/设计新事物（创新）是可以接受的。现在是真正的难题。

如果任何人（研究人员，工程师，才华横溢的孩子，暑期实习生）可以设计和实现编程语言，那么以编程语言进行的博士研究工作所追求的实际硬目标是什么呢？

首先，让我尝试以语言设计的一些众所周知的目标来回答这些问题：

性能-人们永远可以拥有更多的性能；某些应用程序域比其他应用程序域更需要它。通常，这涉及到必须要设计出有趣的数据结构和算法来实现难以设计的PL。

人类生产力-人们总是想要更多。尝试使开发活动更容易/更快是没有止境的。

还有其他目标，但它们是二阶的。例如，语言可能还需要赶上硬件设计方面的创新-想到多核。这是第二个目标，其背后的真正目标是通过利用潜在更高性能的硬件体系结构来提高性能。

换句话说，想要以编程语言进行博士研究的人应该牢记这些目标中的一个或多个，并且非常重要的是，应该准备展示他/她的想法如何实现这些目标。如果您告诉我您的语言使某些程序运行更快，消耗更少的能量，使某些任务更容易执行或导致程序中的错误更少，那么我本人的科学家就要求您向我展示支持这种说法的数据。

编程语言中的许多研究活动都属于性能目标，即工程方面。我认为我们这个领域的每个人都明白这意味着什么，并且能够在该目标下将好的工作与不好的工作区分开。但是，大量的编程语言研究活动援引了人类生产力的观点。整个子领域的出现都集中在人们认为可以提高人类生产力的语言工程上。因此，我将重点关注人类生产力目标。关于人类生产力的争论触及了吸引我们大多数人创造事物的核心：对他人产生直接的积极影响。自从计算机科学开始以来，它就被粗心地调用了。 （我强烈推荐Stefan Hanenberg撰写的这篇出色的文章，发表在Onward！2010上，其中批评了软件科学对人为因素的忽视）

不幸的是，这种论点是最难辩护的。实际上，我还没有看到第一个令人信服地证明编程语言或编程语言的某些功能使软件开发更具生产力的研究。如果您知道这样的研究，请指出。我已经看到许多观察性研究和对照实验试图做到这一点[其中有5、6、7、8、9、10个]。我认为这些研究确实很重要，应该进行更多的研究，但始终很难做到。不幸的是，它们始终不能给我们任何确定的结论，因为即使正确执行相关性也并不意味着因果关系。因此，专注于同一事物并且似乎得出相反结论的研究之间永无休止的乒乓球，在健康科学领域最为人所知。我们也开始看到软件科学中的乒乓球，例如7 vs9。但是，至少这些研究表明，在特定的实验条件下，它们之间存在某些相关性或缺乏相关性，并且它们开始就应该使用哪种条件进行了健康的讨论。为了获得有意义的结果。

我看到了更多关于编程语言的研究和非正式文章，这些语言声称对人类生产力有好处，却没有提供任何证据，除了作者或社区的直觉之外，这些语言充其量只是基于从未从经验上得出的抽象信念的合理推论。已验证。这是一个令我惊讶的地方，因为我对Haskell的学术健全性表示最高的敬意。这样的语句“ Haskell程序具有更少的错误，因为Haskell是：纯[…]，强类型[…]，高级[…]，内存管理[…]，模块化[…] […]有漏洞的空间！”只是一厢情愿的想法。没有数据支持该主张，该陈述具有欺骗性；虽然可以在旨在向民众传福音的博客文章中非正式地进行制作，但绝对不应在博士工作的背景下进行制作，除非该工作为如此有力的陈述提供了有力的证据。

那篇文章不是一个离群值。互联网上充斥着许多文章，声称几乎每种其他语言都提高了软件开发效率。从来没有提供任何证据，论点总是（a）从本应是真实的但从未得到验证的原则中扣除，或者（b）从临时的，高度偏见的，严重歪曲的个人经验中推论得出。

这就是为什么我停止以任何正式身份从事编程语言研究的主要原因。当我还是AOP的主要传教士之一时，我意识到在某些时候我已经越过界限说了些我没有证据的事情。我只是在……传播福音，即说服他人我坚信的想法。在某种程度上，我觉得我需要说些实证。但是，为人类生产力争论提供证据实在是太难了！我的科学家自己无法将博士生带入这个陷阱，我非常了解这个陷阱。

此外，设计和执行导致发现此类证据的实验需要大量的时间和其他技能，而这些技能与实际设计编程语言的时间和技能完全无关。我们需要学习实验心理学家使用的方法。而且，在所有这些工作的最后，如果我们揭示相关性，我们将很幸运，但是我们将无法得出任何明确的结论，这令人沮丧。

但是由于没有任何经验证据，从科学的角度来看，与Haskell或AspectJ有关的未经证实的主张（主要由学者开发和使用，并且已成为许多博士学位论文的主题）与未经证实的主张一样好。例如，PHP（主要由非学术界开发和使用）。当谈到使用该语言的好处时，PHP社区实际上是非常诚实的。例如，这是使用PHP的一套诚实的理由。注意，没有任何关于PHP的声明会导致更少的bug或更高的程序员生产力（好像有人敢说这一点！）；它们只是务实的原因。 （另请注意：我并不是在暗示Haskell / AspectJ / PHP是“可比较的”；它们具有完全不同的目标领域。我只是在比较围绕这些语言的叙述，即社区在其内部讲述的“故事”以及其他）

好的，现在我提出了823个敌人，指出在学术界出现的关于人类生产力的周围语言的主张（因此应该更了解）是没有根据的，加上865敌人，说经验用户研究是无结论性的，令人沮丧。让我尝试扭转我的观点。

高水平的科学证据会杀死编程语言的创新吗？这是导致渐近行为的原因吗？当然，这让我远离了这个话题，但是我只是一粒沙。那些提出有趣的新设计思想而又由于缺乏证据而被同行评审委员会否决的人的工作又如何呢？

因此，我们回到设计创新本身是否是博士工作的可接受的首要目标。现在有一个对应的人提出了这个问题：编程语言的博士工作真的需要提供科学证据吗？

如果我们掌握的不是科学，那么我们应该注意不要盲目采用对科学有效的方法，因为这可能会杀死我们学科的本质。我认为，本质是软件实现的彻底，快节奏的，脱离常规的设计实验。这种仓促与为设计“希望”提供科学证据的需求是完全不相容的。

我将尝试一种平行的方法：药物设计，相当于现代的炼金术。在研究方面，它类似于软件：部分基于严格性，部分基于直觉，现在还基于自动工具，这些工具可以简单地执行大量分子的逻辑组合并确定某些目标函数。在部署方面，无论是谁推动了这项工作，谁都会制定一个计划，以便在实际人员的背景下实际测试理论预期。这种药物真的能按预期做的没有任何有害的副作用吗？我们需要科学证据证明实验药物的价值。我们是否需要科学证据证明实验软件的价值？

关于失败的后果，并行性明显不同。 药物设计实验失败可能导致人们死亡或患病。 如果从一开始就对实验进行了大量投资和/或涉及到对安全至关重要的系统，则软件设计实验的失败仅是一个大问题。 仍然有诸如此类的项目，对于那些项目而言，在部署实验的生产版本之前寻求可靠证据证明其益处是一件好事。 但是，并非所有软件系统都是这样。 因此，科学证据的负担可能太重了。 通常，随着时间的流逝，大量实际使用的测试足以提供各种保证。 Ø ......