How I learned to stop worrying and love Vyper — Part 2
So, after a near month-long sabbatical at a Rainbow Family gathering, and getting all my t’s crossed after coming back, I’m back at writing this tutorial / introduction series to Vyper, the new, still-in-development smart contract language for Ethereum.
On a sidenote, apparently, Viper was quietly renamed Vyper recently. From what I gather, the motivation was that source files could have the .vy extension, which rhymes nicely with .py… Sweet.
In the last article, I explained why I think Vyper is a great idea to begin with, and the issues I have with Solidity as the de facto industry standard in the Ethereum space. Now we’ll start looking at Vyper itself, and go through a demo project from inception to deployment on Ethereum.
I decided on a tutorial project I’ll follow through in this series. I published an article yesterday that I’ve had lying around, about a fun little coin I designed. I have some OpenZeppelin-based Solidity code for it already written, but I decided it will be an ideal demo project for Vyper. It’s complex enough to show the real world usability of the language, and non-critical enough so that the big “alpha” tag isn’t bothering me. :)
So throughout this series, I’m going to follow through the creation of the trickster cryptocurrency “Tribillium” as described in the article linked above, solely in Vyper.
The latest documentation for Vyper can be found at readthedocs.io. Note how it’s still spelled “viper” there. :) This name change is probably going to haunt link urls for some time. The source code for the compiler, and also the docs, live on Github at ethereum/vyper.
Vyper also has an on-line IDE, similar to Remix for Solidity. Unlike Remix though, it doesn’t support debugging (or anything beyond compiling) at the moment. Still, it’s a lot better than nothing.
The controversial choices of Vyper
The Github readme pretty much sums up the core driving motivations behind Vyper. Its aim was to avoid all the pitfalls Solidity fell into (or rather, dug for developers to fall into).
Vyper is a highly security-focused language. It prioritizes auditability above every other conceivable thing. Coming from an off-chain developer background, it might look downright preposterous, but believe me, on the chain, it all makes absolutely perfect sense.
Flat files ought to be enough for everybody
Vyper can be defined in terms of what it doesn’t have. And the most important thing it doesn’t have is the “2i’s”: includes and inheritance. You can also read that as “code composition”.
Vyper consciously and religiously forbids any form of code composition you’ve probably taken for granted since the beginning of your life as a developer. Chances are, your first ever computer program started with
#include or some idiomatic equivalent. So your panic is understandable and expected.
However, before you storm out the door in indignation, or raise an issue on Vyper’s Github, you need to understand that the constraints an Ethereum smart contract must operate under are close to those of a punchcard computer from the 70s.
Code composition in Solidity gives you the illusion that you’re developing for a modern machine, with modern constraints, ie. “if it’s polynomial, it’s okay”. Not on the blockchain it isn’t. In fact, it’s surprisingly easy to write a contract whose installation cost exceeds the block gas limit. Using code composition makes it even easier.
“If it’s polynomial, it’s okay”? Not on the blockchain it isn’t.
So due to the limited resources, a smart contract should be as simple as possible. If you can shuttle logic off the chain while maintaining Integrity and Non-Repudiation (in my view the whole point of using blockchain at all), then do so by all means.
If you can split your on-chain logic into multiple smaller contracts, then it’s in everybody’s interest that you do. Say, if you’re running an ICO — but please don’t run an ICO unless you’re a crook — , it’s better to have your ERC20 / ERC827 token in one contract, your crowdsale in another, your timelocked vestings in a third, etc…
As a rule of thumb, if your smart contract is so long and complex that a single flat file feels uncomfortable, you’re doing something wrong (and it probably won’t even fit on Ethereum in the first place.)
Another reason for shunning code composition in smart contracts is the nature of smart contracts. While a smart contract is not actually a contract in a legal sense, on public Ethereum, a smart contract is a social contract between the owner and the users, and inbetween individual users. For it to be a social contract, it needs to be readable and understandable by those interested and doing their due diligence.
Flat files make that easier, too.
So what about code reuse?!
Software engineers are, by nature, extremely lazy people. In fact, I have a pet theory that the less lazy a software engineer is, the shittier they are as an engineer / developer. A lazy person will notice early if they are doing something repetitive and pointless, and look for a better solution. A non-lazy one will soldier through, cementing in the bad initial decision that made the code complicated in the first place, and pollute the codebase with avoidable workarounds.
So since we’re lazy, we hate writing the same thing over and over. This is why we came up with includes, libraries, polymorphism, operator overload, generics, and all that stuff that makes up modern languages in the first place. So how does that figure with Vyper and smart contracts?
When I thought of not being able to just include ERC20Token.sol, I felt this gut-wrenching cognitive dissonance sort of thing. Yea I want security and auditability, but shit, I’ll actually have to press
ctrl+v… “God, I think I’m gonna wretch!”
Well, what helped me, and might help you, is to start viewing smart contracts as an entirely different thing. They aren’t computer programs the way a webshop or
notepad.exe is a computer program. They are self-documented, self-executing business workflows running on a distributed notarization system.
When you are writing smart contract code, you are not simply coding. You are also documenting.
The merits of templating
Just look at how a lawyer works. They are faced with the same issues, of having to churn out many extremely similar contracts, say for real estate purchases, employments, mortgages, corporate mergers, etc. One real estate sale is very similar to another. A lawyer who does real estate will have a real estate sale template that they can use to build a real estate sale contract for a client.
Instead of composition, say hello to templating. Manual templating at first — as I said, if manual is too much work, it’s probably flawed anyway — , but in the future I imagine we might see automated templating, too. Maybe with parallel documentation in human language.
Also, templating simplifies things that would be complex in composition. Most bugs in OOP come from function overrides. When you want “this, but not quite this”. With a template, you just go in and edit it. (And I already see someone saying that in OOP you often want multiple slightly different versions of the same, but as I pointed out, you don’t have the capacity on the blockchain for something so complex anyway.)
Vyper creators made some extremely brave decisions. Not brave like “removing the headphone jack from a mobile phone”, more like “removing the steering wheel from a self-driving car”. It’s a demonstration of clear product focus, and a better definition and understanding of what it is we are even trying to accomplish.
The Ethereum ecosystem needs Vyper and the vision it embodies like Apple needed Steve Jobs back in the 90s. In the follow-ups in this series, I’ll demonstrate that despite its alpha status, it’s already a much nicer language to work in than Solidity.
(update: click here for Part 3)