Clarx
A programming language focusing on simplicity targeting the Clarity VM
Preface
Clarity is one of the fundamental blocks of the Stacks blockchain. Designed with Smart Contracts in mind, it is a Lisp-family programming language used by every Smart Contract deployed to the Stacks blockchain, where the Clarity VM runs them. Clarity is predictable and secure, and the code you deploy and run on the blockchain is human-readable and easily verifiable. With Clarity, the Stacks chain has been growing steadily in terms of developer adoption, and insofar a few hiccups here and there, it's promised extra security has been showing good results.
There are drawbacks to Clarity as well. Notoriously, Lisp has lousy fame among some in the computer science world (with haters saying it's an acronym for "Lost In a Sea of Parenthesis"), and it's undeniable that its syntax can put off beginners and advanced programmers alike. Also, within the constraints of the Stacks environment, it is unclear if one can benefit from Lisp's most significant selling point, as seen from a developer perspective, which is its meta capabilities.
But of more importance than its debatable syntax is that Clarity is deeply rooted in the blockchain VM implementation itself. Effectively, this means that changes to the programming language will inevitably result in a fork in the chain, requiring significant coordination among the community before moving things forward. In a longer time horizon, this benefits the Stacks ecosystem since it, by design, makes every change go through a more thoughtful process before they become effective, which should increase the quality of those changes. But in reality, there's a lot of uncertainty in the web3 space in general, and experimentation is essential to help communities understand the impact of their decisions in a world where pragmatism and network effects require that L2 projects be flexible and efficient.
With all this in mind, I'm proposing a new programming language in the Stacks ecosystem: Clarx.
Introducing Clarx
Clarx is an experiment to understand the impacts of our programming language of choice on the adoption and experience of developers working in Stacks. Its goal is to provide a feasible alternative to Clarity that allows developers to tackle the problem of writing a smart contract with different lenses and tools while maintaining the guarantees that make Clarity such a fundamental aspect of Stacks.
Clarx can be seen as a symbiotic programming language. It will always compile to human-readable, correct and cost-effective Clarity code. At its heart, Clarx will be:
Easy to learn: it will implement a concise yet expressive syntax inspired by programming languages like CoffeeScript, Ruby, Elm and Elixir. It will also feature a dev-friendly compiler.
Correct: Clarx will be statically typed but with type inference. Moreover, code written in Clarx will always compile to correct Clarity code. This means that although changing Clarx should be much easier than changing Clarity, there will still be a rigid process of writing, testing and reviewing the code written in Clarx.
Productive: Clarx will ensure developers can be very quick with it, both from a syntax and a tooling perspective. Tools will be built into the programming language.
Human-readable: The code output from the compiler is readable and understandable by any developer familiar with Clarity.
Cost-effective: The Clarx implementation also considers the effective gas price of any abstractions it allows, making sure it's also an economically viable alternative to Clarity.
Why a new language instead of ______________ that already exists?
The discussion of an alternative to Stacks is familiar, and there have been some discussions and even some hackathon projects tackling this issue. Smart Contract development is a unique domain. The Stacks ecosystem is even more particular than other L2 solutions because of Clarity and its design. Adopting an existing language for tackling the task of becoming an alternative to Clarity might bring a few challenges:
The compatible bit of the existing language might be so strict that it will require re-learning the language.
The existing tooling needs to be modified and then kept in sync.
The adapted language would have two dependencies instead of just one: its host language and the clarity VM.
Most standard ecosystem tools and libraries would be incompatible with its Clarity-targeted adaptation.
Common idioms would not be allowed, creating an implicit world of translations necessary to speak Clarity in the host language way, which could create even more confusion for developers joining our community.
With those risks in mind, although a more significant task, creating a new programming language from scratch could quickly be paid off by the freedom of choice it would give the programming language authors.
Proposal
The proposal here is to kickstart the development of the Clarx programming language. The project's scope would include some preliminary research, the production of a draft specification for the language and a proof-of-concept compiler capable of generating Clarity Smart Contracts for a few selected deployed contracts. The Stacks Foundation could nominate a few community members to provide feedback on the first specification draft. For the compiler, the language of choice would most likely be Rust. The selected Smart Contracts for the POC should have a good combination of simplicity and usefulness.
Roadmap
Phase 1 - Research
A bit more in-depth research on the topic of programming languages in general and blockchain programming languages specifically to try to answer the following questions:
What makes a programming language easier to learn?
What general aspects of programming language design should we consider for this project?
What are some common Clarity design patterns, and how could they be incorporated into the programming language design?
What are the critical elements in a programming language that help with developer productivity?
What known programming language design choices lead to more correct code?
Estimation: ~60 hours
Phase 2 - Specification Draft
In phase 2, we will draft what will become Clarx's spec. This draft will follow the Clarity Book structure but show how to address each given topic in Clarx instead of Clarity.
Estimation: ~80 hours
Phase 3 - Compiler PoC
In Phase 3, we will write (in Rust) the compiler PoC. The goal will be to compile a few examples of Clarx contracts to Clarity as a starting point to the language tooling.
Estimation: ~120 hours
Risks
Design Risks
Getting this programming language's design right is essential to ensure the project maximizes its chances of success. Although, as previously mentioned, changes are less costly with Clarx, the fundamental design of the language would be harder to change in such an early phase, and getting it wrong could cease the community's appetite for more experimentation in this area. For this reason, enough focus should be given to the project's preliminary phase.
Execution Risks
Clarx can't, in any circumstance, generate faulty Clarity code. This will require a well-established quality assurance process on the developer side, possibly pointing to the need for frequent compiler code audits by third parties.
Also, depending on the design choices for the language, the project could become too big for the grants program without receiving early community feedback. For this reason, there should be a very well-defined target from the first execution day.
Team Risks
The team (me) has never created a programming language. This could be a significant obstacle to getting things right first. To mitigate this risk, I'll dedicate a reasonable amount of time to preparing myself for the task while trying to engage as many experienced community members as possible while working on it. Among my ideas are publishing weekly updates to the Stacks forum and a newsletter for the programming language.
Focus Risks
Instead of improving current developer tools, we would focus on an alternative way of doing everything. This could represent a waste of resources in a critical moment for our community. There are many ways we could mitigate this risk. Still, inevitably, the hypothesis of a new language can only be excluded from the Stacks developer ecosystem if we give it a shot.
Other Risks
It is a moonshot.
Conclusion
The key idea here is to explore an alternative way of building smart contracts for the Stacks blockchain that could benefit developers currently working on Stacks while also becoming an attractor to new developers. The project is challenging, but if we engage with the right people in the right way, I'm confident I can lead it to success.
I'm happy to answer questions regarding this project wherever you may find me.
Postface
This idea was heavily inspired by the success of coffeescript and other alternative language projects in the javascript ecosystem, although on a different scale. The proliferation of javascript alternatives led to many of the validation of many of the ideas around what javascript could be. Ultimately the good ideas stayed and became part of the core javascript spec. This environment of experimentation was and still is extremely beneficial to the community of developers using javascript everyday, and I believe it could be emulated in Stacks.
Another similar example is Elixir, and it's role in popularizing Erlang.
References:
https://llthw.common-lisp.dev/
https://github.com/clarity-lang/reference/issues/63
JavaScript Subset as a Smart Contract Language · Trust-Machines · Discussion #323
https://www.youtube.com/watch?v=Kq5hmbjaBFk
Last updated