As a Blockchain Developer, you Need to Keep Learning to Stay Ahead of the Game

You probably heard it a thousand times before and you’ll hear it a hundred times more – you need to keep learning if you want to stay relevant! This is true for any field, especially in the world of programming languages.

Learning is the key to our success, and that means constantly branching out from the fields we are comfortable with into new and upcoming fields. It means at least grasping the core concepts in a variety of developmental fields to be as well rounded as possible, because you never know when your company might need X problem solved and you’d be the dream candidate they’ve been searching for (or at least you will be so long as you keep learning).

Stagnation is as dangerous as invalid input validation, so unless you want your career to be open to input manipulation vulnerabilities you’d better take control of your future, set the course you want, and start learning.

History as a Loop

The history of computer programming can effectively be traced back to 1949 with the creation of the Assembly Language. Yes, technically we can go back as far as 1883 with Lovelace and Babbage’s Analytical Engine for computing Bernoulli numbers, but we’d be digging up fossils at that point. So, 1949 was the dawn of modern programming, and since then there have been major advances and major setbacks, the latter of which are much clearer as we look into the past from the present.

Source: dilbert.com

There are major trends that can be observed, and they typically go like this: 

1. Language A is invented for a specific purpose. 
2. After a while, another (better) language, B, is written to replace language A.
3. But, instead, they exist in parallel until language A eventually becomes outdated (from the programmer’s perspective).

So, language A continues to be used even though language B is better. Moreover, language A continues to hold market share simply because it was first to market.

We see this in programming languages (the dreaded VBA/Objective-C), operating systems (1/3rd of companies still running XP), and nearly everything computer related (ATMs running COBOL, for instance). There is a certain mindset held by developers and companies of not letting go with things related to computers, and it tends to stifle progress in the respective field. 

But you, as a developer, don’t care about everything related to computers, you care about your day-to-day tools: programming languages. By investigating the past perhaps we can shine some light on the current state of things, and with any luck, help prevent the same situation from happening in the world of smart contracts and blockchains before it even begins.

Breaking down the Data

We are 70 years in since Assembly Language was first created, and since then we’ve seen so many languages that it’s hard to keep track of them all. Only some of them made it big and are worth noting, and over the next few decades we saw a lot of the major languages introduced (Basic, Pascal, Python, all the C varieties, etc.). A lot of these languages still plague developers today, since the industry refuses to move past them and onto new, better, languages.

Stack Overflow (you may have heard of them) does an annual Developer Survey to get a sense of where the programming community is at. The survey this year had nearly 90,000 respondents ranging from dozens of countries and developer roles. Based on their section labeled “Most Loved, Dreaded, and Wanted Languages” we can see some interesting data straight from the developers. First, the top 10 most dreaded languages are at least a decade old, if not more ancient (VBA, Objective-C, Assembly, etc). The most loved languages are all far, far newer, with one exception.

1. Rust 1.0 - 2015
2. Python 1.0 - 1994
3. TypeScript 1.0 - 2014
4. Kotlin 1.0 - 2016
5. WebAssembly 1.0 - 2019
6. Swift 1.0 - 2014

And it makes sense to have such a ranking. If you were a young developer-to-be about to start your first day of college, would you want to study Visual Basic? Would you seek out courses to learn Objective-C? No, you’d want to learn Rust and Swift, the languages that people want to write in.

But you probably aren’t a student anymore, so you’re out of luck right? Well, that depends on where you see your field going. We are currently experiencing the dawn of a new type of programming with new languages and possibilities: blockchains with an emphasis on smart contracts. This field has only been in existence for half a decade, but things are moving rather fast. There’s a market leader, Solidity, but is it already moving into the realm of antiquity?

Solidity first released in 2014 as THE smart contract language for a variety of reasons: 

1. Back then, there was only one main blockchain to run smart contracts on (Ethereum).
2. There weren’t any competing languages (unless you count Lisp-Like Language as a real competitor).
3. And it had first-to-market advantage. 

Solidity took the smart contract world by storm, but does that mean it will always be the best option for smart contract developers?

Take iOS programming, for instance. Objective-C was the primary language for a long time until Swift entered the scene. When Swift came along programmers flocked to it because it was better, but there was still a struggle since Objective-C had a strong hold on the iOS market because of its first-to-market advantage and the fact that it was a household name. Companies that have apps older than 2014 probably still have apps running on Objective-C, but most newer apps are written in Swift, as it is far superior and more liked.

Source: liberaldictionary.com

Ending the loop

When it comes to traditional programming there isn’t much we can do except beg our employers to let us write in more modern code so that every work day isn’t a dreaded typing experience. But there is hope for us to end this vicious loop before it can even start in the smart contract world, and that is by considering other languages than Solidity now instead of in 10 years. There are two major contenders that may become the Swift to smart contracts’ Objective-C, if you catch my drift.

Vyper is one of the newly developed programming languages being created by Vitalik Buterin and the Ethereum Foundation, though we have no real timeline as to when it will officially go live (it is on v0.1.0-beta.11, last I checked). Vyper is a simple language that is extremely easy to audit, has things like overflow checking, decidability, strong typing, and understandable compiler code. Its strengths come from its simplicity and the fact that the creators purposefully excluded things like recursive calling, class inheritance, inline assembly, and the like.

However, Vyper falls short for a few reasons. First, there is no real timeline for its release or even any clear direction as to what its purpose is. Some sources say that it is to be used alongside Solidity to create more secure contracts, while others think it will completely replace Solidity all together. This confusion is unsettling, and the fact that it has been delayed time and time again isn’t reassuring either. 

On the other hand, Ride built by Waves is a new programming language already up and running in its entirety. It’s running on the Waves blockchain and it’s joining a whole suite of services the team built. Based on the performance of their past creations we can assume Ride will be equally as impactful. Ride has all of the same perks as Vyper, it’s already up and running, and more:

• Intentionally non-turing complete (studies have shown that turing completeness in Solidity smart contracts is only used 7% of the time, the other 93% of occasions just cause security problems).
• Basic, no nonsense scripting functions.
• Functional programming language based on side-effect-free expressions as basic building blocks.
• Built-in smart contract complexity evaluation (to predict the cost of running said contract).
• Waves’ blockchain currently uses LPOS (Leased Proof of Stake), something Ethereum (and Solidity) hopes to shift to in the next few years.

Between the two of them, Ride and Vyper, I’d love to see Vyper shift the Solidity front, but Ride is already doing it. The more developers it can shift away from Solidity the better, and, to be fair, Vyper just became a crutch that keeps Solidity hobbling along. Ride is a standalone product that is more secure, more straightforward, and cheaper to use in a direct contract comparison.

So, my fantastic community of developers, the decision is up to you. Do we want to start the loop all over, this time in the decentralized world? Do we want to make the bane of future programmers’ existence the languages we refused to move away from, or do we want to constantly push forward and adapt to new languages that are actually better. 

Source: xkcd.com

If you’re a decentralized programmer, please consider that the world is larger than Solidity, and if you aren’t a decentralized programmer please realize that expanding your skillset is extremely marketable. We have the power to shape the future of programming, so let’s leave it in better shape than we found it, deal?