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.