我是一家嵌入式软件公司的六人组建和发布团队的一员。我们还支持许多开发人员工具，例如Atlassian的Fisheye，Jira等，Perforce，Bugzilla，AnthillPro以及一些自制工具（比如我的Django发行说明生成器）。
大多数时候，我们的团队只为大型应用程序编写小插件（例如：在Anthill中自定义工作流程），长期实用程序脚本（打包QA版本）或Perforce触发器之类的东西（不要让人们检查特定分支，除非他们的更改说明包含错误号;对Active Directory进行身份验证而不是Perforce的内部密码。这是关于我们问题的规模，尽管我们有时会处理稍微大一些的问题。
我的老板，技术合理，已经要求我们对一种或两种语言进行标准化，以便我们可以更容易地相互替代。由于它们的普遍性和简单性，他主张bash脚本和Perl。我可以看出他的观点 - 我们主要做“胶水”，那么为什么不使用“胶水”语言而不是为更大的项目设计的东西呢？由于我们使用的一些工具是基于Java的，我们确实需要使用有时会说JVM的东西。 （这些项目阻力最小的路径是BeanShell和Groovy。）我对语言倡导感到非常惊讶，但我试图避免说“我们应该使用Python”，因为我喜欢它而且Perl很糟糕。“
相反，我正在努力想出一个很好的方法来定义我们的问题集：我们用脚本解决了什么问题？我们的团队可以从常用功能库中受益，还是我们的大多数项目更加孤立？期望我的同事学习有什么理由？哪种语言最容易开发和易于修改？
你们能否提出一些有用的方法来解决这个问题，既可以用于我自己的思考过程，也可以帮助我在同事之间进行一些头脑风暴？
答案 0 :(得分：6)
两点：
“Eww Perl gross”有点像都市传奇。您可以在Perl中编写非常干净的自我记录代码，并且您可以使用几乎任何语言编写只写代码。它是开发人员的财产，而不是语言。
仅仅因为你正在编写胶水代码，并不意味着代码必须像一些胶水黑客那样糟透了。
在SO上比较Perl与Python的许多线程中，在我看来，Perl的CPAN比Python的存储库更广泛，但我没有使用Python的经验，也无法通过真实的比较来证实。
但是，我知道一件事。 5秒后搜索CPAN has a JIRA module。这对你来说是否是一个好因素，这取决于你。
答案 1 :(得分：4)
在我加入公司之前，Google已经在Python上标准化了这些任务（以及更多）;据我所知，巨大的优势，如Python在JVM和.NET上的优秀实现甚至没有在决策中发挥作用 - 这完全取决于可读性。当时（在某种程度上，甚至现在），Google的理论是，每个工程师都必须能够根据需要调整代码库的每个部分 - 当然包括构建脚本，蜘蛛（在Python中使用Python）时间），等等。要求已经精通C ++和Java的工程师学习更多“脚本”语言（Python，Perl，Bash，Awk，Sed等等）是不可理解的：一个必须被选中。鉴于这种约束，Python是明智的选择（在其他限制下，Perl可能也是 - 但我看不出Bash，Awk和Sed不可避免的混合在这样的基础上竞争！_） - 这就是我的方式最后在那里工作了一会儿; - ）。
鉴于Python与Ruby vs Perl vs PHP与Bash + Awk + Sed vs ...的总体潜力大致相等，选择一个显然是赢家 - 和< / strong> Python具有干净的可读性，JVM和.NET上的强大实现具有很大的活力。说真的，我只能想到Javascript（对于客户端工作来说是不可避免的，现在很富有强大的实现，比如V8）作为一个可能的“竞争对手”（不幸的是，JS不可避免地为了向后兼容性而承担很多责任 - 除非你能做到使用类似use strict;的约束来帮助解决这个问题，它必定是一个重要的缺点。）
答案 2 :(得分：1)
答案 3 :(得分：-1)
首先，重要的是要注意很难说服别人他们错了。
他主张bash脚本和Perl， 由于它们的普遍性和 简单
Bash脚本并不简单。 bash编程模型非常复杂且不友好。 if陈述和表达尤其令人恐惧。
Perl可能简单也可能不简单。
Bash是普遍的。然而，Perl与Python一样普遍。 Python几乎在所有Linux发行版中都预先安装。所以这个论点似是而非。
bash，Perl和python的“普遍性”完全相同。然而，“简单”并不相同。一旦他们宣布Perl变得简单，你就不会轻易“证明”或“说服”任何人。
情况。
如果老板提倡Perl，并且Perl不是答案，你会发现很难说服别人他们错了，这几乎是不可能的。
如果老板只是在抛出想法，那么这很难。
快速黑客。
您可以做的一件容易的事情是尝试与一些随机选择的作业进行Python和Perl的头对头比较。然后，您可以使用代码演练来演示Perl的相对不透明度与Python的相对清晰度。
即使这也充满了可怕的危险。
有些人认为代码高尔夫很重要。 Python失去了代码高尔夫。 Perl获胜。没有什么比“与Perl Bias的愤怒的同事”更糟糕的了，他们会用代码高尔夫解决方案杀死你 - 因为它们更小 - 可能会让管理层误以为他们在任意规模上更清晰或“更好”
有些人真的认为明确是“罗嗦”而且不好。 Python经常丢失，因为假设被描述为实际参数值。有些人可以（并且确实）抱怨不得不实际写下来。阅读所有Python问题的Stack Overflow，有人想让try:块在一系列假设中消失。
如果您选择随机问题，您可能 - 意外地 - 选择了可以下载和安装现有Perl或Python的东西。语言可以通过抽签事故赢得胜利。而不是更深入地比较语言特征。
最佳投注
您可以做的最好的事情如下。
确定人们的价值观。您可以将这些称为“非功能性”要求。这些是质量因素。什么是基本的核心原则？开放，无障碍，可转移的技能，简洁，清洁，诚实，正直，节俭，敬畏，耐心，努力工作，透视感，在风中超过20 kn的礁石，等等。这很难。这里没有同情。
确定技术用例。这些是“功能”要求。有哪些胶水和集成？这也很难。当你这样做时，要求从木制品中爆发出来。此外，当团队中有一个Perl bigot时，许多非功能性需求将涌入此区域。您的经理 - 提出Perl - 可能是Perl bigot，并且在Perl bigot存在的情况下可能难以收集用例。
确定（a）Perl + Bash与（b）Python与（c）Java如何适应这些核心价值和功能要求。请注意，使用Python意味着您不需要使用Bash。我的偏好，BTW，是将Bash降低到最低限度。
这是一项艰巨而艰巨的工作。这很难捷径。如果你发现Perl不是答案而且你需要说服的Perl bigot是首先提出Perl的经理，你可能会发现说服某人他们错了是非常困难的。
编辑。我知道我被禁止使用字符串“Perl Bigot”来描述经理对Perl的潜在偏见。但是，我坚持使用“Perl Bigot”来描述提出Perl的经理。该问题没有提供有关更改此信息的信息。最糟糕的情况是（a）经理是Perl Bigot和（b）Perl不是答案。