一些有关Viper、Serpent和HLLs的澄清

叉叉XX   |     |   1315 次阅读

原文:https://www.reddit.com/r/ethereum/comments/5cpplr/a_few_clarifications_on_viper_serpent_and_hlls/
作者:Vitalik Buterin
发布时间:2016.11.13
翻译:许昕&托娅

在昨天有关Viper的发帖之后,我希望能再针对Viper这个语言和这个语言未来在以太坊HLL生态圈里的角色进行一些讲解。

  • 再重申一下,Viper还在Pre-Alhpa阶段。目前请谨慎使用。
  • Viper理论上来说还不是“泛函完备”,它要么是“完备的”要么是“可判定的”。因为它还不能完全没有副作用的处理方程。虽然这么说,我显然可以禁止永久的改变变量或者可能造成常值函数中上述改变的外在呼叫-事实上,在下次的发布中我很有可能会这样做,这样Viper语言至少会更加泛函友好。
  • Viper的目标不是成为所有语言的之中的霸主,不是为了代替Serpent,Solidity,以及LLL。Viper的发布不应当被当成一个我(VB)认为Viper在所有的情况之中都比现存的其它语言优越抑或是认为它解决的问题是现存语言经过修改也无法解决的一个声明。Solidity开发者在从事溢出检查以及其它系统安全方面的开发;这些是我支持的,很棒的工作。重新开始的背后的原因是,这样可以有更多的自由去进行实验不用担心踩到前人的脚,可以提供与现存的语言不用的功能以及取舍,可以增加选择。也参加,这里,Bamboo,是另外一个在开发中的实验性HLL。
  • 为什么我会选择Viper而不是继续研发Serpent? 首先,Viper有意在一某些特定的方面不如Serpent强大,比如说在可判定方面(不像Serpent是完全可判定),因此它不具备动态长短循环。另外一个例子是,Viper只支持128比特整数,地址,bytes32,十进制固定点值,而Serpent支持更大的整数类型。Serpent同时也加入了直接呼叫EVM的功能,Viper则没有。使用Serpent的开发者们也许无法一下适应这些限制。第二,Serpent编译器的C++基本代码对于我以及新开发者来说都是很大的一个挑战。一开始之所以选择用C++来编写编译器是因为我们以为它可以直接在Geth, Mist等等中使用,现在这些考虑已经不存在了,python在开发和阅读上显然容易得多。
  • Serpent未来会怎样?讲真,这完全取决于Serpent社区(Augur,btcrelay,说你们)的意愿。我自己显然没有很多时间去继续开发Serpent,特别是因为在我看来它的基础代码在继续成长方面的局限比较明显的情况下,现在为止我还没有看到Serpent在吸引到社区之中更广泛的参与方面取得很大的成功。虽然说了这些,我还是欢迎Serpent社区积极参与讨论。目前的选项包括(1)尽量保持语言本身的静态,持续进行维护以使Serpent能够持续与EVM兼容(EIP 86,分片等),(2)扩容Viper,提供一条通路是Serpent的(几乎)所有代码可以自动转化成Viper代码的一部分,或者(3)某些团队接手Serpent,实行自主开发。
 
1 人喜欢