I recently dug into Vyper, a new language for the Ethereum Virtual Machine, with a python like syntax.
I presented a brief tutorial of my investigation to about 20 of my colleagues at ConsenSys. I was excited to take a look at the Vyper team’s perspective on contract design, but ultimately struggled to understand many of the design decisions.
This post is meant as a friendly critique of what I found. Realizing that the language is still experimental, I hope it’s helpful that I share my impressions sooner than later.
First, I should say that although Python was my first language, I am much
stronger in JS and Solidity. So there may be ‘pythonic’ design elements
which I misunderstand.
Secondly, I will try to frame my comments with respect to the stated design
goals for the language. They are very laudable goals, which are what
initially attracted me to the language:
Principles and goals
1. Security: It should be possible and natural to build secure smart-contracts in Vyper.
2. Language and compiler simplicity: The language and the compiler implementation should strive to be simple.
3. Auditability: Vyper code should be maximally human-readable. Furthermore, it should be maximally difficult to write misleading code.
I’m particularly interested in the “Auditability” portion. Although the term is not explicitly defined, I believe an auditable language would include:
- explicit over implicit syntax (ie. function visibility must be declared, there is no default)
- low cognitive overhead to differentiate between types, and track state variables
The code and my impressions
The following is a toy contract I wrote, which is mostly a grab bag of functionality to see what I could get to compile. In order to communicate my likes and dislikes, it seemed easiest to just include it as comments in the code itself.
I wrote whatever I was trying to do in square brackets, ie.[Declare a storage variable] followed by my comments on attempting to do that thing. You can also read it on Github if you prefer:
