LLL: A Viable Alternative to Solidity?

Before Solidity, Ethereum smart contract developers used LLL (short for Lisp-Like Language). Being a somewhat ‘low-level-language’, LLL is often compared to Assembly language. However, it’s simple and minimalistic structure makes it quite readable when formatted properly (and its much simpler than common Lisp). Instead of JavaScript-like braces, LLL developers simply use parentheses for parsing (as Lisp does). And like Python, LLL developers employ indentation to indicate code blocks. So anyone viewing LLL will notice its very concise and straightforward, making it easy for developers to code with.

LLL’s Many Advantages

While writing code in LLL is fairly easy, LLL avails developers with other strengths as well:

• Unlike Solidity, LLL developers are able to directly access memory and storage. This means that LLL developers can effectively arrange contract data as they see fit.
• LLL also employs ALL Ethereum Virtual Machine (EVM) opcodes (operational codes like ADDRESS, STACK, ORIGIN, PUSH1)…but without the high-level entanglement found in Solidity. Its this power and economy of code that many developers appreciate.
• Again- brevity. Smart contracts written in LLL compile to smaIler binaries than Solidity contracts- up to 70% smaller (consensys.net).
• While critics view LLL as little more than assembly code with Lisp syntax, it “provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such a macros, and has the ability to include other source files as well” (syrinx.net).

These benefits accrue to LLL despite it being a low-level language. While LLL does not allow for stack management and jump management as Solidity does, many developers find that a welcome relief. Indeed, LLL continues to gain adherents simply because its Not Solidity. These fans appreciate the “different perspective and programming discipline (LLL provides) when compared to the ubiquitous Solidity language” (Github: LLL Introduction).

So Why Solidity?

Solidity retains serious security issues and is not easily accessible to the casual developer (being notably difficult to comprehend at times). For instance, its “stored procedures are not something that the average developer writes on a regular basis”. However, Solidity provides “the best interoperability with the Javascript APIs” (reddit). This alone is the primary reason that it is used over LLL and Serpent (a smart contract language that actually compiles down to LLL).

Not Entirely A Language Issue

Since few developers are keenly aware that Serpent (now revised as Viper) and LLL exist, many are choking down Solidity as the mainstay smart-contract language. It’s simply the best documented smart contract language out there (although hardly in an impressive way). And it also gets the most support.

Still, LLL should get a second look from smart contract developers. Several proponents are seeking to resuscitate its use (see Daniel Ellison’s article “The Rise of A Forgotten Language”). Other languages should be considered by smart contract developers as well. As one Reddit commentator 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 in order to translate language to EVM bytecode. It’s possible (even likely) that a code-agnostic platform like XTRABYTES platform may serve that role in the near future. It certainly appears to offer a brighter future for any developer interested in creating new and exciting DApps in the language of their choice.

Resources
The Github Repository for LLL;
LLL Compiler Documentation