研究不同语言发展的相对成本
有没有人看到最近（也是相当平衡的）研究使用不同语言的软件开发的相对成本？ 我特别想看看Java Vs的相对成本。 C＃Vs. delphi。
由于复杂的variables数量，开发人员对语言的使用经验，语言对目标领域的适用性，开发人员的整体素质的定量比较将是非常难以确定的（有人认为，非主stream语言吸引更高质量的开发者），与产生的产品进行权衡（是一个Ruby或Python应用程序，就像一个写得很好的Delphi或C ++应用程序一样快）等等。
在Code Complete，2nd Ed。 ，Steve McConnell列举了几种语言的expression能力（每种语言的单个语句中可以expression多less等价的C代码）。 有人认为，不pipe语言如何，程序员在代码行中的生产力是相对稳定的; 如果这是真的，那么每种语言的expression能力应该粗略估计每种语言的相对发展成本。 从表4.1，第62页：
语言水平相对于C C 1 C ++ 2.5 Fortran 95 2 Java 2.5 Perl 6 Python 6 Smalltalk 6 Visual Basic 4.5
他列出了这个表的几个来源： 估算软件成本 ， 用Cocomo II进行软件成本估算 ，以及“七种编程语言的经验比较”（Prechelt， IEEE Computer ，2000年10月）。
麦康奈尔引用的数字都是几十年，但据我所知，Cocomo II模型是可笑的详细，所以目前的Cocomo II材料可能提供delphi和C＃目前的数字。
不，但我不是狂热的任何人，作为顾问和用来推荐其中的每一个要求，我有。 所以这里有一些事实可以让你更容易地select使用什么来解决系统开发需求。
常见：
他们都是最好的领域：
- Java是最好的Java开发选项。
- C＃是最好的.NET开发选项。
- Delphi是最好的本地开发选项。
他们都有：
- 提供优质组件和库的全球第三方供应商。
- 世界各地的知名应用程序（例如delphi的应用程序可能更为人所知：Yahoo Go for TV !, Macromedia Captivate，TotalCommander，MediaMonkey，FinalBuilder，InstallAware，WinLicense，MySQL Administrator等）。
他们都是：
- 具有RADfunction的高度可靠的技术。
- 由最好的开发辅助工具（UML等）支持。
- 发布其技术（Java 7，.NET 4.0和Delphi多平台）的主要升级。
区别：
3件事C＃更好：
- 可以编码的开发人员数量（与Java相比）（*）。
- 微软落后了。
- 工资（通常）方面的开发成本更便宜。
3 Java更好的事情：
- 可以编码的开发人员数量（与Delphi相比）（*）。
- 可移植性。
- 太阳落后了。
3delphi更好的事情：
- 速度（时间关键型系统的性能更好）。
- 占用空间小（Delphi编译器生成非常小的二进制文件）。
- 没有明确的依赖关系（更容易分发）。
（*）有一个非常可靠的事实，即有更多的其他语言的开发人员可以使用C＃编写代码而不是其他语言的开发人员，这些开发人员可以使用Java进行编码，这意味着更容易findC＃程序员。 也许这就解释了为什么在许多网站（如这个）和允许多语言问题，重构等的论坛中，通常还有更多C＃的问题和答案（ 84k vs 50k ）。 另外，由于Java工作在全球很多地区都得到了最好的支付 ，所以常识指出Java开发人员的工作时间比C＃更长，这使得比C＃更容易findJava开发人员。 当然，还有其他一些可以讨论的因素，但是我相当确定，find一个C＃程序员比一个Java程序员容易得多。
我不知道正式的学习，但是我听到很多关于公司在Delphi中使用现有应用程序的轶事logging，并且因为某种原因在C＃中重写了它。 他们都以同样的方式结束。
即使所有的业务逻辑和领域知识已经以现有的Delphi代码库的forms出现并呈现出来，用C＃重写程序的时间也是原来用Delphi编写的两倍。 在此期间，他们没有发布更新，因为他们所有的资源都忙于重写，使他们的竞争获得了市场份额。 完成后，这是一个1.0级的产品。 出问题，速度慢，难以使用，往往伴有严重的向后兼容性问题。
之所以有开放的解释，但我认为使得Delphi比C＃（或Java）更有效率的主要因素之一是语言的外观和感觉。
众所周知，在开始维护和debugging现代程序方面，除了最初的工作，花费更多的工作，时间和努力之外，这个原则并没有经常遵循逻辑结论。 如果最需要做的工作是维护程序，那么在编写代码的基础上select一种语言是不成熟的。 如果您使用易于阅读和维护的语言，您可以获得更好的投资回报。 当涉及到代码可读性时，Pascal（Delphi）击败了C系列的传奇。
这不是一个正式的研究，但值得思考。
我从来没有找过这样的研究，但如果有的话我会感到惊讶。 任何旨在以适当的科学方式衡量和比较跨多种语言的实际开发成本的实验将是非常昂贵的。
要做到这一点：
-
您需要在一系列应用程序域中指定一些不重要的项目。
-
您需要组build一个数量庞大的项目团队，每个团队都由具有开发大型应用程序所需的丰富经验的开发人员组成。
-
然后，您需要为每种语言实施每个项目N次…才能获得具有统计意义的结果。
所以你需要开发者的努力，相当于project-size * nos-languages * nos-projects * nos-repetitions 。 假设一个非平凡的项目需要1人年，那么有5个项目，每种语言开发5次（为了给我们一个足够大的样本量在统计上是显着的），即25个有经验的开发者年。 ..说200万美元到500万美元…每语言考试。
这些数字（显然）是从空中撤出的，但是我的观点是，对不同语言的开发成本进行适当的科学比较是非常昂贵的 。
即使如此，研究结果将不会解决：
- 持续维护/维护成本，
- 数字如何扩展到大型项目，
- 团队规模的语言特定效果，
- 各种语言的开发工具的可用性，成本和收益，
- 每个语言组build经验丰富的团队的难易程度，
- 等等。
结果将在3到5年内过时。
Peopleware（Tom DeMarco和Timothy Lister）在第八章中有关于“编码战争游戏”的章节。 从1984年到1986年，已有600多名开发者参加。
在对游戏结果的分析中，他们发现编程语言与性能几乎没有关系。 （只有汇编语言的参与者被所有其他语言组严重留下）
美国空军很感兴趣，发现delphi的编码速度要快得多。每年的C ++竞赛吸引了速度编码团队参加比赛。 delphi的编码器影响这个竞争，几乎总是以所需的代码快得多。
在他担任空军发展主pipe之后，我的前任老板Bill Roetzheim撰写了关于估算软件开发成本的书。 他的select，首先是delphi。 那是3/4版本。 理性使用他的估计模式。 我仍然在使用它，而且我一直在做这些事，没有比这更好的了。
devise的清晰度和代码expression的力量在版本上并没有太大的改变。 大多数时候你正在看视觉变化和增量增量。 20年前的核心最佳实践仍然适用。 这就是使架构成为可能的原因。 我们知道最佳实践是什么样子的，因为在一定的规模下，代码必须符合一定的标准要求，不会有很大差异。 您几乎总是可以使用它，或者使用更less的笨拙接口，但是使业务系统正常工作的数据，安全/过滤和工作stream系统仍然使用GoF Design Patterns手册中的相同devise模式。 而且，如果小设备教会了我们任何东西，那就是强调清晰和简单。 这很重要，你的代码基地是多么容易使用的目的。 所有主要的环境都可以很好地进行域devise。 系统的速度和易于开发使得Delphi和Node.js成为我的两个后端偏好。 但function明智的C＃和Java都很好。 如果我担心开发人员对环境的安全问题，我会在某些情况下使用C＃，因为编码人员很难违反这些规则。 但是当我不需要这些规则时，即大多数时候，我更喜欢一个更加开放的环境。 当我不太在意安全性时，我可能更喜欢Node.js，因为它可以快速完成。 大多数情况下，我觉得Node中很容易出错，而且我最终需要完整的testing代码覆盖。 Delphi是我的第一select。
“开发商的素质”很难衡量。 Java和（在较小程度上）C＃在学校和大学中被用来培养学生的程序devise基础。 其中许多最终会在支持论坛上提出作业问题，并以某种方式算作程序员（和穷人）使用该语言。 实际上，绝大多数人在完成强制性入门课程之后，绝对不会编写一行代码，其余的大部分代码可能不会用这种语言编写。
—关于程序员能力的“比较研究”咆哮—
如前所述，如果不是不可能用一种不同的语言来实现某种成本比较估计，那么这是非常困难的，至less作为所有项目的一般情况来说。 有些东西可以让.NET更好，其他的更适合于Java，而其他的则可能最好在Excelmacros中完成。
而开发成本通常只是系统总体拥有成本的一小部分，特别是在运行在具有数据库的应用程序服务器上的多层应用程序等情况下。如果客户已经有一个以MS SQL Server数据库作为后端运行IIS的serverfarm，使用Oracle后端向他们出售Java EE应用程序正在做他们的损害，即使这是否是应用程序的最合理的select。 开发成本可能会降低，但客户的运行成本会更高。
另一方面，你的angular落杂货店的一个网站，要开始通过networking接受订单交付，不应该在.NET或Java EE中实现。 解决scheme的成本（尤其是托pipe）将远远超过其好处。 基于例如php或rails的一个简单的事情将为这个客户提供更好的服务。 托pipe成本降低，数据库和应用程序服务器不需要支付昂贵的许可证费用，他可能实际上使用由此产生的网站赚钱。
像其他人所说，没有研究…因为没有人感兴趣。 没有可衡量的差异。 几乎所有的项目pipe理书籍，你都不会看到任何语言障碍的例子，不依赖于特定的语言特性。 大部分时间在项目生命周期中消耗任何金钱的问题都不是编码问题，而是架构和组织。
要把事情看得透彻，如果你遇到严重的语言障碍，必须实施一些解决方法 – 你会失去几个小时。 维护人员可能会花更多的时间去理解你在那里做了什么，为什么会失去一两天的工作。 那么，如果你以一种错误的心情工作，你就会失去同一天。 如果您在理解需求方面存在问题，或者与同事和pipe理层沟通，您很容易就会失去数周和数月的时间
