Before Solidity, Ethereum smart contract developers used LLL (short for Lisp-Like Language). Being a ‘low-level-language’, LLL is often compared to assembly language. However, it’s quite readable when formatted properly (and simpler in structure than Common Lisp).
LLL’s Many Advantages
In addition to being easy to code, LLL provides developers with direct access to memory and storage. This allows LLL developers to effectively arrange data within a smart contract as they see fit.
LLL also employs Ethereum Virtual Machine (EVM) opcodes (operational codes like ADDRESS, STACK, ORIGIN, PUSH1)…but without the high-level entanglement found in Solidity. For instance, smart contracts written in LLL compile to smaller binaries than Solidity contracts (up to 70% smaller). (consensys.net). Hence, LLL code is viewed as both powerful and economical.
And although critics view LLL as nothing more than assembly code with Lisp syntax, the language “provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such macros, and has the ability to include other source files as well” (syrinx.net).
LLL continues to gain adherents merely as a viable alternative to Solidity. For instance, while LLL does not allow for stack management or jump management (as Solidity does), many developers find that absence a welcome relief. These fans appreciate the “different perspective and programming discipline (LLL provides) when compared to the ubiquitous Solidity language” (Github: LLL Introduction).
So Why Solidity?
Not Entirely A Language Issue
Few developers are keenly aware that LLL even exists, leaving Solidity as the sole option for creating smart-contracts. And as Solidity is fully documented and highly supported, developers can hardly be faulted for thinking otherwise.
Still, LLL should get a second look from smart contract developers. A movement to resuscitate LLL is already underway (see Daniel Ellison’s article “The Rise of A Forgotten Language”). Likewise, other languages should be considered by smart contract developers as well. As one Reddit user noted “The only requirement though is building a compiler that can translate the language to EVM bytecode. Anyone could make smart contracts in Java, Python, C, etc. as long as the appropriate compilers existed.”
If so, perhaps developers need a platform that is much more versatile. One that doesn’t require jumping through so many hoops to translate a programming language to EVM bytecode. A code-agnostic platform like that created by XTRABYTES may be the answer. It promises a bright future for any developer interested in creating new and exciting DApps in the language of their choice.