November 16, 2018
Code & Design
I want to contribute code to one of these projects — how can I get started?
Is there any one language used specifically for blockchains?
I don’t know how to program — can I jump straight into blockchain programming?
A few months ago, I had the pleasure of moderating a panel of four active NEO programmers at the San Francisco NEO Dev Conference. The topic of the panel was general blockchain programming, however, an additional caveat made this particular panel of participants very interesting: all four programmers wielded a different language of choice for working on the NEO project.
One favored the old-school C # language, another produced Python scripts, a third evangelized the ever-popular Javascript implementation & the fourth participant excitedly discussed an upcoming domain-specific NEO language.
Two thoughts stuck with me post-panel:
This article aims to address point number 2. Maximizing the effectiveness of this guide requires curtailing the expected audience to a narrow niche: new & junior programmers looking to break specifically into the blockchain space. For veteran developers, programmers, & software engineers perusing — the following section may provide some benefit, however, you’ll likely find them elementary. Senior engineers can maximize their time by skipping to Part II in order to get to the sauce of it all (the language landscape).
So you think you’d like to break into blockchain programming eh? Let’s start by further defining exactly what blockchain programming entails.
In general, topics that personally interest you & align with your values are easier to learn than rote memorize-ing something without a clear buy-in; I highly stress that this principle applies increasingly more in an innately-complex, rapidly-evolving field such as blockchain programming. Before we begin, let’s check out some of the challenges that a blockchain developer faces in the burgeoning industry.
First & foremost is the continual, public discrepancy between what exactly a “blockchain” does or does not entail. Spend some time in crypto-twitter & it’ll become clear just how tribal crypto -communities, & by a stretch, their development communities have become. Unchecked tribalism naturally leads to biased conversations on what ought-to-be objective content, adding another layer of obfuscation for incoming developers.
Next, with the majority of projects in their testnet phase & with live projects continuously updating, forking, & falling victim to hacks, it’s unsurprising to see incomplete documentation & unfinished tutorials. The lay of the land is rapidly evolving which requires consistent iteration — no easy task for any team.
Last is the true stigma that blockchain programming is flat-out complicated & made up of multiple intersecting fields that require at least a rudimentary understanding of the following: economics, cryptography, currency, data structures, financial policy & physics. Learning even just the parts of these fields relevant to blockchain programming takes ample time to understand — no shortcuts here.
Tribalism, haphazard documentation & complicated fundamentals. All warning signs of a steep climb up ahead. In order to adequately motivate oneself through these barriers to entry, it helps to dig through some clarity on what exactly blockchain programming means in the first place. Additionally, it might help to uncover…
Why do you want to learn blockchain programming? What project do you want specifically work on? What problem(s) are you trying to solve?
If you already know what project you feverishly want to work on, kudos — I suggest heading over to the organizations GitHub repository or ctrl-Fing the language of choice here to read ahead. The following section will most benefit those that can’t quite pinpoint exactly what project & required skillset/language suits them best as a jump-off point for the potential learning roadmaps ahead.
Generally, blockchain programming can mean three different things:
Strongly consider the three options described above as they each offer an array of different languages & learning curves. Additionally, they should help get you one step closer to clarifying your exact preference. Further segmentation for language criteria is right around the corner; however, don’t forget that personal preference trumps all for motivating yourself through learning a new skill.
Assuming a day-one software engineer is equally interested in learning about all three types of blockchain programming — what other criteria can they turn to in order to shine on a light on the friendliest path forward?
By overviewing these three criteria we’ll finally have a solid frame of context from which we’ll apply to our list of languages.
Categorizing tools across qualitative qualities is rarely clear-cut — programming languages are no different. Here, we’ll split all possible blockchain programming languages to two different categories: domain-specific languages & general-purpose languages.
Typically, a domain-specific language (DSL) is a computer language designed & specifically suited for a particular application. A general-purpose language (GPL), as the name aptly-describes, is a language that is broadly applicable across many programming domains.
General-Purpose Language
General-purpose languages are the languages you’ve likely heard of such as Java, Javascript, Ruby, C++, & Python. Among the general-purpose languages, one can find infinite ways to further categorize them by qualitative & quantitative differences & similarities such as readability, compiling, strictly-typed, frontend/backend, etc… A good rule of thumb on first-time friendliness is as follows:
Javascript, Python, & Ruby are generally easier for newcomers as they have less of a learning curve while C++ & Java usually take more time to learn out of the box.
Note, the editor is refraining from commenting on second & third-level consequences of a newcomer starting off with one group of languages or the other. There are multiple debates across further features of these languages, such as forcing newcomers to understand variable types first through a strictly-typed language that we’re circumventing to maximize usage here for a new developer approaching strictly the blockchain space.
The biggest pro for newcomers picking up a general-purpose is the immediate ability to apply that language in a vast number of fields outside of blockchain programming. Unfortunately, the flipside of that same coin creates a con for those newcomers looking to join the job market as you’ll likely compete directly against senior & veteran software engineers from other domains with years of experience wielding said general-purpose language.
Domain-Specific Language
To provide context, let’s step back from blockchain programming. While it’s a fairly new programming field, the concept of a new programming field itself is not that new — you don’t have to look too far past the twin-recent-buzzword machine learning to see this. A few, additional programming field that has also witnessed a natural evolution of one or more domain-specific languages are: statistics (R, MatLab), database querying (SQL), Web UI (HTML, CSS).
Domain-specific language blockchain programmers are in very high demand with very little supply: these young languages, whose only purpose is one or more of the three blockchain programming options listed above, undoubtedly offer the clearest path to landing career-industry placement.
Since these languages were designed from the ground up with blockchain & smart contract engineering in mind, experienced developers may struggle to readjust previous frames of references from other languages.
While newcomers, with a fresh slate programming habits, lean-out all that’s necessary to begin deploying code in current or future projects.
Again, by circumventing the very-real programming fundamentals found in general-purpose language, one may find him or herself at a significant disadvantage down the line if the domain-specific language of his or her choice is somehow deprecated.
The follow diagram breaks down the pool of possible blockchain programming entry-points from a DSL/GDL segmentation; transparent/distant languages are languages not covered at length:
Different programming languages offer different levels of readability based on how simple or complex their syntax is. Syntax refers to the designated spelling & grammar rules of a programming language. Usually, syntax readability correlates with the steepness of the learning curve; hard to read code makes for hard to learn code. Again, there are certainly exceptions to this rule however, for our purpose this linear relationship holds true.
We will use two key, yet common, programming language syntax features to create a readability understanding specifically for new developers & blockchain programming languages. The most common of these concepts is loose vs. strict variable typing.
Loose vs Strict Typing
All programming extensively uses variables; however, there isn’t simply a single, regular variable type — there are many, each with unique properties. You’ve probably heard a few of these variable types such as strings, integers, & booleans. Every programming language leverages these natural types in their syntax; however, each language layers these variable types with their own variable-referencing logic. Some languages, such as Python & Javascript, allow developers to simply use a single “var” variable: var example = “coincentral.” This flexibility allows developers to circumvent the tedious process of making sure each variable type is appropriately set in every line. Languages that hide low-level variable assigning are known as loosely-typed languages.
The latter category, strictly-typed languages, consists of a more verbose, albeit more descriptive syntax. Declaring variables in strictly-typed languages consists of specifically declaring the original variable type the developer intends to use: string example = “coincentral.” If you compare this to the previous variable declaration, pay close attention to the bolded “string.” This strict-typing of a variable is the key difference in syntax between loosely-typed language & strictly-typed language. The difference in syntax is not at all narrowed down to just declaring variables, it’s a key language design feature that’s pervasive across the entirety of each language.
Both loosely-typed & strictly-typed languages offer heaps of pros & cons tradeoffs. One of the most important trade-offs to consider for newcomers is the learning curve associated with both types. In general, loosely-typed languages offer a friendlier-syntax for newcomers & therefore a lower barrier to entry; however, the biggest immediate drawback to consider is a serious gap of fundamental software engineering knowledge when it comes to interacting with variable types.
Leverage this information however you see fit. As we’ve now seen, “what programming language should I start with?” underlies many different starting points. Now armed with knowledge from this article, it’s time to survey the language landscape as it lies in the 2018 blockchain space. Read on with Part II in this series!
sources
Mastering Bitcoin: Programming the Open Blockchain
