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.
There are major trends that can be observed, and they typically go like this:
- Language A is invented for a specific purpose.
- After a while, another (better) language, B, is written to replace language A.
- 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.
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.
- Rust 1.0 – 2015
- Python 1.0 – 1994
- TypeScript 1.0 – 2014
- Kotlin 1.0 – 2016
- WebAssembly 1.0 – 2019
- 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.
Solidity first released in 2014 as THE smart contract language for a variety of reasons:
- Back then, there was only one main blockchain to run smart contracts on (Ethereum).
- There weren’t any competing languages (unless you count Lisp-Like Language as a real competitor).
- 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.
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.
- 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.