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.

Following along

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.

Also, at the moment, the link displayed in the documentations (vyper.tools) is broken. The IDE can be accessed via viper.tools (yea, right?) or vyper.online.

The controversial choices of Vyper

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 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?!

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 crtl+c and 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

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.)

Conclusion

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)

There’s two kinds of programming: functional and dysfunctional.