我们为什么没有必要为智能合约开发一个新的编程语言
本文的主要目的是解释与智能合约新开发的编程语言的 相关不确定性。许多新项目为开发智能合约提供了自己的编程语言，但实际上，我们应将这种为伪需求改造出来的新编程语言视为是不好的甚至是有害的功能。
对于智能合约平台使用自己的编程语言，可以应该要对以下缺点加以注意：
- 1.为了开发而进行的开发：严格来讲，我们不需要进行这种开发，因为现在已经有许多现有的编程语言可以解决这些新语言想要解决的所有问题。
- 2.开发资源的浪费：开发新的编程语言是对开发资源的浪费。另外，这必须要引入且建立新的工具链（包括编译器、IDE、测试环境、语法分析器），但是这种工具链的作用和已经存在的工具链对已经存在的语言所做的事情是完全相同的。
- 3.主要的安全漏洞：较新的编程语言缺少编码和安全标准。
- 4.对开发人员的不尊重态度：引入新的编程语言会迫使每个想要在平台上启动 DAPP 的开发人员都要花时间学习新语言，但是必须这样做的优势在哪里呢？
1. 新的编程语言不会比现有的语言带来任何优势
智能合约并没有比其他程序要求更多。像 C ++ 或 Java 这种强大的编程语言可以解决几乎所有可以用代码实现的任务。同时，这也适用于智能合约。
无需为智能合约开发新的语言，因为现有的语言其广泛采用程度已经完全可以满足智能合约的开发了。
如果有人说新的编程语言是必要的，因为它在某些方面会更好，或者引入了其他智能合约开发平台所没有的优势，那这听起来更像是一种营销术语。从技术上讲，智能合约开发平台当前的局限性与编程语言类型无关，与其所遇瓶颈密切相关的是整个基础平台架构及其功能。
开发新的编程语言是一项高度专业化的任务，与智能合约开 发平台的开发以及该平台如何执行合约的方法无关。
没有与智能合约开发相关的任务是不适合用在我们已经广泛采用的编程语言中。这可以看出，我们真的不需要开发新的编程语言，因为所有需要解决的都可以用那些已经经过时间检验的解决方案来解决。
2.浪费开发资源和工具链的维护
应该注意的是，自定义编程语言要求开发适当的自定义工具链，但是该工具链将与现有工具对现有编程语言所做的工作是完全相同的。
开发新的编译器是一项非常专业的任务，需要在这一领域具有丰富经验的高素质团队。与现有的 GCC 或 LLVM 相比，所有自定义编译器的性能都要差几个数量级。而我们应该知道的是，GCC 已经开发了 32 年，而 LLVM 的开发历史也已经有 17 年了。如果有人决定将自定义编程语言用于智能合约并为其开发新的编译器，那么在我们合理的预期之下，假设该团队有丰富的经验，那这些高度专业的专家大约需要 15 年的时间才能将该工具追上如今 LLVM 的性能水平。
还有值得注意的是，如果开发人员决定开发一种新的编程语言，那么编译器并不是他们将要面对的唯一任务。从字面上看，他们将被迫从头开始重新实现各种各样的工具，并解决很多只用通过使用现有编程语言和兼容工具链就可以避免的任务。
一个很好的例子是比较以太坊（Solidity 是为以太坊合约开发的自定义编程语言，Solc 是自定义编译器）和EOS（C ++ 是被广泛采用的编程语言）。以太坊的合约无法循环使用。尝试执行简单的数学运算（例如在 100 次迭代中进行乘法运算）会将以太坊推至极限，并使其无法执行（超出了 gas 的极限）。在 EOS 中，可以执行 200000 次迭代，每个迭代包含三个数字乘法调用。我们从这个例子就可以看出非常明显的区别，一个是经过多年开发的工具，一个是近年才从头开始构建的工具。
3.安全性和可维护性的观点
理解编程语言的选择不仅仅是偏好问题，这一点非常重要——这是关于安全语法和编码标准的问题。
编程语言具有以下特征：
- 可读性：读取代码和理解底层逻辑是一件容易的事情。这是最重要的特征，因为这决定了维护人员从事项目的能力以及安全审核员识别攻击媒介和其他安全缺陷的能力。
- 紧凑性：良好的编程语言必须使程序尽可能地紧凑。每个逻辑表达式的字符数应尽可能地少，因为它会极大地影响代码审阅者专注于程序逻辑的能力。审核员的注意力应集中在程序的功能上，而不是程序的编写方式上。
- 可采用性：这包括已经熟悉编程语言的专家人数，以及可以帮助新手学习和避免常见错误的准则的存在。要是缺少经过时间检验的准则和已知的实践经验，错误容易重复产生，直到通过反复试验找出最常见的错误（如果使用智能合约，这将转化为“黑客、盗窃和抢劫的投资者”）。这里并不是建议将所有可能的编程都进行实践。例如，在 C ++ 中可能会过度使用模板，但不建议您这样做，因为这会对程序的可读性产生负面影响。
新创建的编程语言的采用水平始终很低，因为没有建设性的实践建议，并且熟悉该语言的专家不多。
在大型项目中，编码标准是严格固定的和强制性的。否则将很难理解，试想想我们现在修改或调试那些几十年前就不再从事项目的人员编写的代码。再想想要是多个程序员坚持自己的编码风格，他人就不可 能正确地协调和合并他们的工作。对于第三方审阅者而言，这让第三方难于审阅且难以识别安全漏洞。
GNU 是一个经过多年开发周期的大型项目的好例子。GNU 编码标准描述了适当的编码样式和属性、编程语言首选项以及认真的软件开发项目必须考虑的其他方面的必要性。
3.1有关形式验证和面向安全的编程语言的特别说明
形式验证不是一个自给自足的安全保证方法，而是一种减少软件测试人员开销的帮助方法。形式验证本身是不可靠的，因为使用形式验证无法防止业务模型的缺陷，每个逻辑缺陷或间接攻击媒介正是利用形式验证的缺陷。
编程语言可以提高安全性的最佳方法是经过时间测试并且易于阅读。
为了进行正式验证而牺牲了可读性和可采用率，这是一个极大的安全问题。
如果将智能合约开发平台设计为提供安全的智能合约，那么引入多层的“安全性增强”功能会比尝试使其中一个（编程语言）完美无缺更有效率。没有人可以办证实现十全十美的安全（系统安全工程的一般例子），唯一有效的安全增强策略是增加安全层的多样性。
4.新创建的编程语言限制了 DAPP 开发人员
新创建的编程语言迫使开发人员花时间学习。成为一名程序员意味着总是需要学习新东西，但这也意味着如何正确分配时间非常重要，为了节省时间我们为什么不选择使用现成的工具？加密行业和智能合约开发平台正在快速发展。当智能合约开发平台具有其自己的编程语言时，出现的 第一个问题是“为什么我应该花时间学习这种新语言，如果它在明年或几年内被更好的平台所取代或者被弃用，那么除了在该平台上确切地写合约之外，我学这个东西还可以有什么用处？”
这个问题的答案很可能是：“仅仅是因为平台的开发人员决定创建自己的语言，或者认为他们可以在几个月内超越其他程序社区数十年的工作成果。”
尝试放弃编程社区其余工作的结果，并尝试从头开始构建所有内容，似乎是一个非常容易犯的初级错误。但是，对于任何愿意使用已开发平台的人，这样的错误会带来很多问题。
作为安全审核组织的负责人，我可以总结，这将会迫使我们所有的安全审核员学习新的语言，这是与现有语言相比没有任何优势的额外开销。在大多数情况下，更新的语言具有较差的可读性和不常见的语法表达，这进一步增加了执行代码审阅的复杂性。
结论
通用的编程语言完全适合于智能合约的开发，创建新的编程语言是不必要的，并且没有任何优势。
用于智能合约开发的新创建的编程语言在安全性、性能和采用方面差了几个数量级的距离。
如果要为新创建的语言开发自定义工具链，则需要数十年的时间才能将它们带到如今通用语言工具链的水平。在某些情况下，可以将新创建的编程语言与现有工具集成在一起，但这仍然是一项艰巨且耗费资源的任务，只需使用通用编程语言就可以避免。
新建的编程语言为 DAPP 开发人员引入了进入障碍，这导致缺乏专业的开发人员，缺乏经过时间考验的精心设计的编码标准，并增加了愿意雇用开发人员或安全审核员的雇主的费用。
结构良好的智能合约开发平台不会用自己的编程语言来开发智能合约。