Published
4 years ago on
September 17, 2019
Table of Contents
- 1. Static vs. Dynamic Typing
- 2. Lazy vs. Strict Evaluation
- 3. Functional vs. OOP
- 4. Turing (TC) vs. Non-Turing Complete (NTC)
- Complexity Evaluation
- What programming language fits these criteria?
- You, the developer…
Blockchain is more than just a media buzzword, and if you’re a developer who takes your career seriously you’ve hopefully at least dabbled in blockchain tech by this point. The industry surrounding blockchains is massive (possible $12.4 billion by 2022), and unlike other developer industries it isn’t saturated.
Going into 2019 there are five key concepts every modern blockchain smart contract developer should have an understanding of, even if they just want to be able to sound smart in a meeting with their boss. So let’s discuss these core concepts and showcase how they’re being used in the top smart contract languages.
1. Static vs. Dynamic Typing
Typing (as in type, not the process of pressing keys) decides both when and how types are checked in code. Static typing variables are known at compile time, while dynamic typing variables are tied to run-time variables. The major benefit of using static typing as opposed to dynamic is that static typing languages tend to catch the majority of errors during compile time, as opposed to during run-time execution.
Source: prateekvjoshi.com
Smart contracts are run using community resources (nodes) instead of local resources (RAM/CPU/SSD), therefore they cost money to compile and execute. By catching errors earlier on in static typing a programmer can not only reduce the overall cost of their contract, but they can ensure that complex run-time errors will not incur unexpected costs after a smart contract has been launched.
More information here.
2. Lazy vs. Strict Evaluation
These opposite evaluation types come into play when a compiler encounters an expression and decides to evaluate it; the difference between the two is WHEN the compiler takes on the task. The purpose of evaluation is to get to the root meaning of a segment of code, and in strict evaluation this process occurs the moment a compiler comes across the code. In strict evaluation, expressions are immediately evaluated and evaluated once again if they come up later in the code. On the contrary, lazy evaluation means that expressions are only evaluated when needed, saving time and energy if that particular expression is never used during a specific instance of the code.
In the case of smart contracts, lazy evaluation reduces total processing power by using memoization to store evaluated expressions for later use. Additionally, lazy evaluation allows for less complex compilers (and lower costs) thanks to built-in “short circuiting” logic.
3. Functional vs. OOP
By definition, functional type emphasizes the evaluation of functions while OOP is based on the concept of objects. Immutable data is used in functional programming while OOP relies on mutable data. Their models are opposite too, because functional type follows a declarative programming model while OOP doesn’t. There are also key differences in how they handle support and execution, since functional allows for parallel programming and can execute statements in any order, while OOP uses sequential programming and has to execute statements in a particular order.
Source: twitter.com/meetingcpp
Three main things make functional programming more useful for smart contracts. Immutability is first; since the lack of mutable variables makes the code more predictable and reduces system errors it increases stability and lowers costs. Second is fault tolerance, since functional programming can continue to function even after a failure event. Parallelization is the last key feature, since it enables highly distributed systems that are key in blockchains.
More information here.
4. Turing (TC) vs. Non-Turing Complete (NTC)
To understand TC vs. NTC, it is easiest to look at what the two types of systems can do. Turing-Complete machines implement computable functions, always include functions that won’t terminate by themselves, and include functions that can theoretically use infinite amounts of memory. Non-Turing-Complete machines don’t support recursion, loops, or any other type of goto variant that tends to need outside termination to come to an end. In essence, TC languages can be applied broadly for many uses, while NTC languages are designed for rather specific purposes.
The main reason why turing completeness is not suitable for smart contracts is that it allows for recursive call exploits, reentrancy attacks, and unpredictable results thanks to the Halting Problem and extensive recursion. For example, in the case of Ethereum (whose programming language, Solidity, is TC), this can lead to infinite loops that completely drain the accounted GAS without a successful output. On the contrary, NTC essentially demands simplified code with specific intent, leaving little room for waste.
More information here.
Complexity Evaluation
Being able to determine how complex a program is BEFORE running it is a valuable tool. And complexity evaluation does just that; it is able to gauge how complex a program is without having to run it to find out. In the regular world of programming this isn’t as important, since we are only using the resources on our computer when we compile – if we run out of memory or error out, who cares, just restart the process.
In the blockchain world, however, time is money, literally. Running smart contracts use node resources that can be costly if done incorrectly, so being able to predict how complex a program is (and therefore how much it will cost to run) ahead of time is crucial.
More information here.
What programming language fits these criteria?
The five concepts above are crucial in the argument about where the future of smart contract languages will end up. These concepts help form the basis for languages and specifically detail how they will handle security and cost in regard to blockchains. Of the five presented concepts, there are better options:
- Static typing bests dynamic
- Lazy is cheaper than strict evaluation
- Expression-oriented feels like it was designed for blockchains
- NTC streamlines safety and functionality while removing the security flaws of TC
- And built-in complexity evaluation is, well, pretty dang handy
Let’s look at how these concepts are presented in three popular smart contract languages. We’ll be looking at Ride because they have an established smart contract blockchain platform, are constantly trying to make developers’ lives easier, and they have been running strong since their 2016 debut. We’ll also cover Solidity because it has first-to-market advantage, is currently a community staple, and it holds most of the smart contracts in the world by percentage. Finally, we’ll look at Vyper because it is being built as a serious standalone competitor in the smart contract world.
Ride has a lot going for it. It is a statically typed and lazy NTC language that is based on functional programming complete with a built-in complexity evaluation asset. It also runs using the Proof of Stake protocol, which is a huge attraction for programmers seeking a more environmentally friendly blockchain to run their smart contracts on. But for all the glitz and glamour, Ride is still in its infancy, so we have yet to see it undergo the true stresses of the smart contract world. Sure, Solidity is riddled with problems, but some may argue that it is “better the devil you know than the devil you don’t.”
You, the developer…
You should, of course, take all of this information with a grain of salt and do your own research. Please visit the links shared after each section in order to get a complete understanding of the topics; because, honestly, you never know when the knowledge may help you in a job interview or while trying to impress your boss during a major meeting. Understanding these five concepts and how they apply to the smart contract world is priceless knowledge, and then using that knowledge to pick your primary smart contract language is the next step.
Source: xkcd.com
Remember, we are in the early game of blockchain smart contract development. The skills and paths you choose here could shape the rest of your career, so study it!
